Here’s a little write-up on how hacker (annoymous)was able to delete any unverified account in facebook. By unverified, I mean those accounts who didnot yet verify their email address linked to facebook.
All (or most) of my bugs have been authentication related to many vendors, this was no different. It was found in 2014 by one great hacker (one of my friend). i am reposting that blog again.
Here is how hacker did it:
The sign up function lets you create a new Facebook account but the response was different when the email was verified vs. when the email for the account was unverified. If you use a Facebook account that already has an account in Facebook (with its email unverified), the response you get is :
When clicked on the “Insert the confirmation code instead” it lets you enter 5-digit number only code.
Lets generate a dictionary from 00000 to 99999.
for i inrange(0,99999):
Now, straightforward stuff! I fired up Burp Suite, “Swiss army knife” for me.
Notice something peculiar in the last request? Yep, the response length changes to show that you’ve made the correct guess. (AJAX response in burp response says that).
There was no rate limit on the number of requests you could make.
Some math work : possible password = 100,000 If number of requests = 100/sec. Time taken to figure out the code (worst case scenario) = 15 minutes
I could permanently delete any unverified Facebook accounts within 15 minutes. You would try to recover using “password recover” feature but all your friends, PM’s would be gone. You would have to create entirely new account.
All I had to do was squander my bandwidth and keep brute forcing (and sit back and relax).
How did I find out if an account was unverified?
Well, one way was to sign up using that email and see the response (if you are asked to enter confirmation code or not).
For a large number of emails, the other way was to enumerate facebook users first, to find out if the email had a facebook account and then use “Change email address field” to sort out which accounts have facebook associated with it and are still unverified.
A thick client, also known as Fat Client is a client in client–server architecture or network and typically provides rich functionality, independent of the server. In these types of applications, the major processing is done at the client side and involves only aperiodic connection to the server.
Thick Client vs Thin Client applications:
The thick clients are heavy applications which normally involve the installation of application on the client side (user computer). These application take up memory and run completely on the computers resources. This means that the security of the application is dependent on the local computer.
Thick clients are often not well-suited for public environments. To maintain a thick client, IT needs to maintain all systems for software deployment and upgrades, rather than just maintaining the applications on the server. Additionally, thick clients often require specific applications, again posing more work and limitations for deployment.
Typical examples of thick clients are G-Talk, Yahoo Messenger, Microsoft Outlook,online trading portals,etc…
The thin client applications are web-based application which can be accessed on the internet using a browser. These types of applications do not require any installation of software on the client side. The complete processing is carried out on the server. Also, these are light weight and do not occupy any space on the client side (user computer). In addition,thin client apps can be accessed by any computer or mobile device that has internet access, making them very portable. With that said, thin client apps are only as fast and reliable as the user’s internet connection and the server’s bandwidth.
Examples of thin client application are web-sites like google.com or yahoo.com.
The thick client applications are made of two types:
Two tier thick client application:
The two tier thick client application consists of the user computer and the server. In this type, the application is installed on the client side, which directly communicates with the database on the server. These usually involve legacy applications. (E.g. – The VB.NET application directly communicating with the database using Open Database Connectivity)
Three tier thick client application:
These kinds of thick client applications involve three tiers, wherein the client talks to the application server, which in turn talks to the database. The communication in these applications is carried out using HTTP/HTTPS. Examples of these applications involve G-Talk or Yahoo Messenger.
Security Assessment of Thick client applications:
Application security assessments of thin client applications are comparatively easier than thick client application, as these are web based applications which can be intercepted easily and major processing takes place at the server side.
Since the thick client applications include both local and server side processing, it requires a different approach for security assessment.
The table below distinguishes the vulnerabilities faced by a web based and a thick client application:
Web based vulnerabilities
Thick Client based vulnerabilities
Improper error handling
Cross Site Scripting
Not applicable – browser based vulnerability
Not applicable – browser based vulnerability
Denial of Service
Broken access control
Refer towww.owasp.org for more details on the vulnerabilities listed above.
List of tools that can used intercepting thick client applications:
Echo Mirage is a network proxy tool that uses DLL injection and function hooking techniques to intercept the traffic transmitted and received by the local applications. Traffic can be intercepted in real-time or manipulated with regular expressions and a number of action directives.
Echo Mirage can be run in two different modes:
By launching an executable from Echo Mirage
Injecting into a currently running process
By launching an executable from Echo Mirage
In this option, the path of the application is provided into the Echo Mirage tool and it launches the selected application. The data sent and received by the application is intercepted by Echo Mirage.
The screenshot below shows the Gtalk traffic intercepted by the Echo Mirage tool.
Injecting into a currently running process:
In this, the Echo Mirage tool injects into the process by hooking into the socket calls.
Select the thick client application from the list of running processes, and inject Echo Mirage using the “inject into a running process” option from the tool.
Echo Mirage can also be useful in capturing data from JAVAApplets. For capturing data from a JAVA applet, inject Echo Mirage into the process “java.exe”.
BURP Proxy invisible proxy mode:
BURPProxy is an intercepting proxy server for security testing of web applications.
The BURP proxy tool can be used in invisible proxy mode to intercept the request from non-proxy-aware thick client applications (HTTP/HTTPS traffic only).
Mallory is a proxy tool that can intercept TCP and UDP traffic and can be used to capture network traffic or thick client applications using both HTTP(S) and non-HTTP(S) traffic.
In manycases, the above mentioned tools like Echo Mirage get hanged due to heavy network traffic and become difficult to test. Mallory comes to the rescue in such cases.
The ideal setup for Mallory is to have a “LAN” or “Victim” network that Mallory acts as the gateway for. This can be configured within a virtual machine environment using only network interfaces. The victim virtual machine then configures the Mallory machine as the gateway by manually setting its gateway. The gateway machine will have at least one WAN interface that grants Internet access. The victim network then uses the Mallory gateway to route traffic.
It allows for intercepting the traffic for thick client applications. ITR serves as a TCP tunnel between the client and the server. By instructing the client to open its connection to the ITR instead of the server, the entire connection is shifted to work through the ITR, without the client or the server noticing a difference.
In the following sections, we will discuss the critical vulnerabilities faced by thick client application.
Sensitive data storage on files and registries:
During the installation and execution of thick client applications, these apps tend to write/modify sensitive details in the files and registries. The sensitive data stored by these apps usually include username, passwords, database credentials, license details, cryptographic keys, and configuration details like IP address, port, etc…
The attacker can get access to these sensitive details and might compromise the application. In order to assess the application for sensitive data storage, we need to analyze the files and registries used by the application. Using a sysinternal tool called “Process Monitor”, we can identify the files and registries used by a particular thick client application.
Process Monitor is an advanced monitoring tool for Windows that shows real-time file system, registry and process/thread activity. This tool by default starts monitoring all processes. By setting up proper filters, it can be set to only capture the data related to a particular process.
Set the Process Monitor tool to intercept the registry activity as shown below:
Analyze the registries accessed by the application to check for sensitive details like keys, encrypted passwords, etc…
Set the Process Monitor tool to intercept the file access activity, as shown below:
Analyze the files accessed by the application to check for sensitive details like configuration details, log writing, caching files in folders, etc…
Listed below are a few sample exploits that a thick client application may face:
Sample Exploits 1:
A thick client tool (licensed version of a tool)after license registration on ‘A’ machine stores the license validation key and expiry date in encrypted format as a value in the registry. Whenever the tool is opened, a function in the tool validates against this registry value and provides access to the GUI of the tool.
Exploit: An attacker may export the registry key from ‘A’ machine and import this registry key into the ‘B’ machine to use the professional tool thereby bypassing the license registration process.
Sample Exploit 2:
During installation, a two tier thick client application stores a configuration file locally on the machine containing the database IP, port, username and password locally.
Exploit: An attacker might get access to this configuration file containing the database connectivity details. He might then directly connect to and compromise the database.
Sample Exploit 3:
A thick client application writing/storing application logs containing sensitive details like user accounts, trading details, last login date and time, etc… on the user machine.
Exploit: An attacker can get access to this machine and steal the user specific details written on to the log files.
We are all aware about capturing requests and tampering the parameters for the testing of vulnerabilities in web based applications. In the case of thick clients, major processing/validations are carried at the client side. As a result both the request as well as response modifications play a key role in testing the thick client for vulnerabilities.
Sample Exploit 1:
Consider a thick client applications that displays the GUI(modules/sub-modules) based on the response parameters received from the server after authentication.
For example,when an Admin logs in, the response sent by the application is as follows:
Exploit: In this case, the attacker or the lower privileged user will intercept the response and modify the User and Account_No parameter to that of the Admin and get access to the administrator module.
Sample Exploit 2:
As we discussed above,the major validations are carried out at the client side, a faulty implementation of authentication process has been observed in various two tier apps and is described below.
When a user enters the user name and password in the application, the application sends a SQL query to the database containing the username to retrieve the user credentials.
The SQL query is as follows:
The response received from the database is as follows:
It can be observed that only the username is sent to the database, and the database sends the valid password back in the response. This password is compared locally at the client side with the password entered by the user on the login page.
Exploit: The attacker can enter a correct username (say Cust1) and a wrong password on the login page. The application will send a SQL query to the database with the username entered, and retrieve the correct password. The attacker will then intercept the response, and steal the hashed password(Cust1 in this case).
Memory Analysis using WinHex Tool:
All applications, be it web based or thick client applications, temporarily store data into the memory (Random Access Memory) for further processing. An application might store sensitive data like user credentials or encryption keys into the memory and store them until they get written by other data. An attacker may run a memory reading tool like WinHex in the machine to analyze the entire memory content used by the application.
The screenshot below shows the memory dump of Google Talk application.
Other vulnerabilities that can be tested for in thick client apps are as follows: