Hacking and Cracking

Hacking and Cracking

Whatsapp 4G VIP SCAM - Technical Analysis

Posted: 06 Sep 2016 11:12 AM PDT

This is a short blog post describing about a recent hoax pertaining the WhatsApp 4.0 version. I would like to clearly highlight that there is no such application as 'Whatsapp 4G'. The version promises users  unrealistic features video calling, new whatsapp themes, delete sent messages from both sides etc

The following is how the message is being propagated:

Technical Analysis 

Upon visiting the link you would be taken to a page where you would be asked to invite 15 friends before you can download the version, upon clicking the invite button, it would use WhatsApp scheme (whatspp://) in order send messages to your friends, and hence you would be promoting a hoax on behalf of the scammers:

The entire business logic is based upon the following client side script -

Upon examining invite.js it was discovered that the code sets a cookie and checks if 15 invites have been sent on the client side: 

Once, the counter has reached up to 15 invites or above, you would be redirected to the download link:

From the above source code, if the value of c is greater or equal to '15', window.location.href would be set to "ur" variable which hosts the following download link -

The installation link seems to be dead, normally in such scams you would be asked to fill in surveys or installing *free apps* which would not be free as they might be shipped with Malware/adwares.

Update (Whatsapp Gold)

A new variation of Whatsapp 4G VIP scam has recently came into notice with name of "Whatsapp Gold", which basically works on the same principle as above. The only thing that has changed the interface design and name.

Hacking and Cracking

Hacking and Cracking

Breaking The Great Wall of Web - XSS WAF Evasion CheatSheet

Posted: 01 Sep 2016 03:07 AM PDT

I think it's mandatory to give back to Security community from where we learn cutting edge techniques and information. Therefore after months of effort i am presenting to you a new WhitePaper titled "Breaking Great Wall of Web" without any strings attached.


I would like to thank the Acunetix Team for helping with proof-reading of the document.


The WhitePaper not only contains sophisticated XSS vectors but it aims at also explaining the methodology behind bypassing a WAF.  The previous paper on this subject "Bypassing Modern WAF's XSS Filters - Cheat Sheet" was released 3 years back. A lot has changed and evolved during these years, especially with the advent of ECMA Script a new horizon for evasion/obfuscation have been opened. I have already discussed/demonstrated several techniques presented in this whitepaper in my recent Webcast hosted by Garage4hackers team namely "Bypassing Modern WAF's Exemplified At XSS".


 Input Validation flaws such as XSS are the most prevailing security threats affecting modern Web Applications. In order to mitigate these attacks Web Application Firewalls (WAF's) are used, which inspect HTTP requests for malicious transactions. Nevertheless, they can be easily bypassed due to the complexity of JavaScript in Modern browsers. In this paper we will discusses several techniques that can be used to circumvent WAF's exemplified at XSS.

This will paper talk about the concepts of WAF's in general, identifying and fingerprinting WAF's and various methodologies for constructing a bypass. The paper discusses well known techniques such as Brute Forcing, Regular expression reversing and browser bugs for bypassing WAF's.

Hacking and Cracking

Hacking and Cracking

Google Chrome, Firefox Address Bar Spoofing Vulnerability

Posted: 15 Aug 2016 11:29 PM PDT


Google security team themselves state that "We recognize that the address bar is the only reliable security indicator in modern browsers" and if the only reliable security indicator could be controlled by an attacker it could carry adverse affects, For instance potentially tricking users into supplying sensitive information to a malicious website due to the fact that it could easily lead the users to believe that they are visiting is legitimate website as the address bar points to the correct website.
In my paper "Bypassing Browser Security Policies For Fun And Profit" I have uncovered various Address Bar Spoofing techniques as well as bugs affecting modern browsers.  In this blog post I would discuss about yet another "Address Bar Spoofing" vulnerability affecting Google Chrome's Omnibox. Omnibox is a customized address bar api developed for better user experience such as search suggestions, URL prediction, instant search features so on and so forth.

Technical Details

Characters from languages are such as Arabic, Hebrew are displayed from RTL (Right To Left) order, due to mishandling of several unicode characters such as U+FE70, U+0622, U+0623 etc and how they are rendered combined with (first strong character) such as an IP address or alphabet could lead to a spoofed URL. It was noticed that by placing neutral characters such as "/", "اin filepath causes the URL to be flipped and displayed from Right To Left. However, in order for the URL to be spoofed the URL must begin with an IP address followed by neutral characters as omnibox considers IP address to be combination of punctuation and numbers and since LTR (Left To Right) direction is not properly enforced, this causes the entire URL to be treated and rendered from RTL (Right To Left). However, it doesn't have be an IP address, what matters is that  first strong character (generally, alphabetic character) in the URL must be an RTL character

Logical Order

The following is the logical order of characters in the memory.  Since, Omnibox removes"http://" and displays strings without "http://" prefix.ا/

Display Order

The following is the display order of characters after the browser removes the leading "http://", decodes the percent-escaped bytes, and applies the bidirectional algorithm.‭ا/

Steps To Reproduce

1) Visit the following link for the vulnerable browser -

2) You would notice that the URL has been flipped from Right to left and the browser displays while it displays the content from the IP address.

The IP address part can be easily hided specially on mobile browsers by selecting a long URL ( / in order to make the attack look more realistic. In order to make the attack more realistic unicode version of padlock can be used in order to demonstrate the presence of SSL.

Firefox Mobile Address Bar Spoofing CVE-2016-5267

Firefox was also prone to a similar vulnerability, however this did not require IP address to trigger, all it required was is arabic RTL characters, which in this case i provided arabic TLD (عربي.امارات) in order to trigger the vulnerability which resulted in

Proof of concept 


As you can see from the above screenshot that the page is hosted on عربي.امارات , however the address bar points to

Important Note

Variation of similar vulnerability has also been discovered in several other browsers that are still undergoing a fix there i am refraining from disclosing them. Details will be disclosed, once a fix has been landed. 


RFC 3987 § 4.1 states that "Bidirectional IRIs MUST be rendered in the same way as they would be if they were in a left-to-right embedding.", therefore setting paragraph direction to LTR fixes this issue. This is a known issue and has already been discussed in great detail here.


I am highly indebted to "Matt Giuca" from the Google Chrome team for his extensive help on this issue and "Tod Beardsley" for handling the disclosure.

Bug Bounty 

The total bounty rewarded for all bugs combined was 5000$.

Hacking and Cracking

Hacking and Cracking

Wordpress Mobile Detector Incorrect Fix Leads To Stored XSS

Posted: 13 Jun 2016 03:30 AM PDT

Recently, Wordpress Mobile Detector plugin was in news for the "Remote Code Execution" vulnerability that was found inside the resize.php file. The vulnerability allowed an external attacker to upload arbitrary files to the server as there was no validation being performed for the file-type that has to be retrieved from an external source.

Soon after the vulnerability became public, the plugin was taken down from wordpress directory until the issue was fixed. However, as per my analysis the fix is incomplete and leads to stored XSS. 

The Vulnerability

Let's discuss about the initial vulnerability first. The following PHP code takes input via src parameter (GET or POST) and checks for the existence of the file. If it exists, appropriate content-type header is set. 


if (isset($_REQUEST['src'])) { $path = dirname(__FILE__) . "/cache/" . basename($_REQUEST['src']);
file_put_contents($path, file_get_contents($_REQUEST['src']));


It then utilizes the file_get_contents function in order to fetch file contents from a URL and upload it to the webhost under cache directory.  Please note that, this is only possible if allow_url_fopen is enable upon the server which limits the effectiveness and impact of the exploit.  The problem with the above code is that the code does not perform any check for extensions that are allowed.  So, in case if an can fetch/execute PHP, ASPX code it results in a code execution.

The (incomplete) Fix

The following fix was implemented which defined a whitelist of all extensions that are acceptable (primarily images). The code checks if the requested file ends with the whitelisted extensions before they are fetched and uploaded. 

$acceptable_extensions = ['png','gif','jpg','jpeg','jif','jfif','svg'];
$info = pathinfo($_REQUEST['src']);
// Check file extension
file_put_contents($path, file_get_contents($_REQUEST['src']));


The problem with the above fix is that it whitelists "svg" extension. It is a widely known fact that svg images can execute JavaScript. 

Using SVG To Trigger Stored XSS

In order to demonstrate the finding, The following svg file would be hosted on a Remote Server. 


<?xml version="1.0" standalone="no"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" ""><svg onload="alert(1)" xmlns=""><defs><font id="x"><font-face font-family="y"/></font></defs></svg>

This image once requested via "src" parameter will be saved to cache directory:

Upon visiting the uploaded image:

Other Attack Possibilities

i) In case where path finishes with an allowed extensions there is an attack possibility -

ii) In older version of PHP, it is possible to append a nullbyte and tricking the server into uploading a malicious PHP file. Example -

iii) In case if Display_errors is set to true in php.ini file. The file_get_contents() function can be utilized for . A similar issue was discovered by me in the year 2013. You can refer to the following blog post -  phpThumb Server Side Request Forgery

iv) In case where path finishes with an allowed extensions there is an attack possibility - 

v) Even allowing external users to fetch and upload images can external images might introduce issues such as someone can host porn images and tarnish companies reputation, someone can deliberately upload a copyrighted image and sue the company, since there is no limit to the number of images one can upload, one can still attempt to exhaust server resources by uploading tons of images. 

Suggested Fix For Vendor 

i) The suggested fix is removing the "svg" extension from whitelist

$acceptable_extensions = ['png','gif','jpg','jpeg','jif','jfif''];

ii) File names should be re-written after they are uploaded, so that their location may not be guessed. along with directory listing should also be disabled. 

Suggested Fix For Webmasters

iii) Server administrators should modify the .htaccess file to only support allowed extensions. and prevent accessing other files.

iv) Content-Type-Options: nosniff header to prevent exploiting the site using SWF file with .jpg extension for example -

v) Content-Disposition header should be utilized.

Thanks for Soroush Dallili from NCC group and Daniel Sid from Sucuri for tipping off. 

Hacking and Cracking

Hacking and Cracking

Acunetix Website Hack And Lessons Learnt

Posted: 05 Jun 2016 01:57 AM PDT

Last night, Website of Acunetix(A Wellknown Automated Web Application Scanner) was hacked by Croatian hackers. From that point of this onward the website has been taken offline and acunetix team are reviewing the root cause for the hack. Currently the homepage is displaying a "403 Forbidden error", it might be due to the fact that either the attacker has deleted all he files or developers have deliberately taken it down in order to review the files for any possible backdoor that might had been injected.

Courtesy -

Lessons Learnt 

Up till now the cause of the hack remains unknown as Acunetix is yet to acknowledge it. However, The hack gives us the following important generic lessons:

i) Defense is more difficult than offense. For defense you have to find and close 100 doors which an attacker can use to get into the Server, For offense the attacker has to find one single way to get in.

ii) WebApplications now days have became extremely complex with new features being added on daily basis. It's almost impossible to achieve complexity and Security at the same time.

iii) Automated Scanners and Web Application Firewalls won't necessarily protect your Webapplications. As both of them do not understand Business Logic of the Application. Defense in depth principle should be followed where Security should be ensured at all layers. You can refer my article  "Secure Application Development And Modern Defenses"

iv) Security is not a one time job, it's an ongoing process, no specific requirement has to be met for 100% security.

One of the arguments that People would use is "How can their Tool ensure our Webapplication's Security, when they cannot protect themselves from getting hacked?", the answer is absolutely nothing can ensure 100% security,We have seem many Security products failing to ensure their own security, one of the examples can be found here (Imperva SecureSphere Web Application Firewall MX 9.5.6 - Blind SQL Injection), here ( So Who Hacked EC-Council Three Times This Week?) and here (Tavis Ormandy finds vulnerabilities in Sophos Anti-Virus products) and it's perfectly normal.

The problem comes when these product owner instead of acknowledging and responding to the breach wishes to remain silent and thereby loosing it's credibility even further in the eyes of customers and well as infosec community.  It is the right of  the customers to know whether their data was compromised in the breach and if yes up to what extent and if passwords were compromised, how were they storing the passwords.

With that being said, i would like to highlight the fact that they will not necessarily go out of the business after this hack. Eccouncil has been hacked multiple times and they are still in the business.