Wednesday, October 04, 2017

Case Study: Frys Electronics Web Portal - How Exactly *Not To Design* Password Change Component !

NOTE: The issue highlighted in this post is for educational purposes only.

Last weekend some electronic gadgets were ordered from the Fry’s electronic store at (,w=CHECKOUT=1). An account was created and after interacting with the web application for 10 minutes, a number of security issues were identified in the Fry's online portal due to insecure design and coding practices. The idea behind this post is to educate application developers on how to design secure components. It is just something I came across and decided to share.

In this post, the insecure design of "Password Change Component" has been presented. The user should take the highlighted issue in consideration while accessing the online web portal.

Insecure Design - Password Change Component

It has been noticed that the "Password Change Component" used by Fry's online portal is designed insecurely. A secure design practice involves that application component should ask for the “old password” from the user before the new password is supplied and verified accordingly. This is required by the application to perform additional password verification to determine whether the HTTP request is issued by the legitimate user or not. If the “old password” is required and validated, it enhances the design and robustness of the system. Further, the component does not even enforce complex password requirements. For examples:- (1) the last used password can be reset again as new password, (2) minimum password length enforced is 6 characters. Many other variables in the password complexity requirements are not met either.

The issue does not end here. The flaw highlighted above is a basic design fallacy. Let's see how multiple vulnerabilities can be chained together.

Cross-site Request Forgery - Password Change Component

The password change component (mod_exist_password.php) is vulnerable to Cross-site Request Forgery (CSRF) attack. Let's look into a number of design checks:
  1. The application does not implement origin verification checks either via unique tokens or "Origin" header. As a result, HTTP POST requests are accepted by application without any token verification and validation.
  2. The password change component does not explicitly enforce the verification of “old password”.
  3. The application does not even perform a basic "HTTP Referer" verification check on the server side.

It means the attacker can easily author a CSRF exploit to change the password on the fly which ultimately results in the account hijacking.

Let's validate this.

The HTTP POST request is taken from the CSRF exploit drafted as a Proof-of-Concept (PoC). It can be deciphered that the HTTP POST request does not carry any token as a part of request header or the body header. In addition, the ‘Referer” header is also removed from the HTTP request.  General, “Referer” validation on the server side is treated as a defense against CSRF attack. In this case, no "Referer" validation is performed either.

POST /wf HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:54.0) Gecko/20100101 Firefox/54.0
Accept: text/html,application/xhtml xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Content-Type: application/x-www-form-urlencoded
Content-Length: 169
Cookie: ID_KOT=987123654; J1_USER_ID=[Removed]; BTgroup=B; FSERVERID=s107
Connection: close
Upgrade-Insecure-Requests: 1


HTTP/1.1 200 OK
Date: [Truncated]
Server: Apache
X-Powered-By: Servlet 2.5; JBoss-5.0/JBossWeb-2.1
Cache-Control: max-age=0
Expires: [Truncated]
Vary: Accept-Encoding
Connection: close
Content-Type: text/html;charset=ISO-8859-1
Via: 1.1 sjc1-10
Content-Length: 13877

By simply sending the HTTP POST request to the server via a CSRF exploit when the user is logged-in the session, the attacker can change the end-user password.


Frys was contacted via Twitter and via LinkedIn as no direct security contact information was available. No response was received so the details have been released.

Saturday, March 07, 2015

TCPExtract (or TCPxtract) Installation Discrepancies on Mac - Step-by-Step !

TCPExtract (or TCPxtract) is used for extracting specific set of files from the PCAPs by looking into TCP sessions. During object extraction or file analysis in the network traffic, this tool is used. Installation of this tool on the Mac is tricky and several issues need to be debugged before it installs appropriately. I spent sometime on this tool during installation and  thought to share the complete solution. The step by step approach installation steps are discussed below:

My Mac is configured with brew (you can repeat the same steps with ports also).

1. you need to install libnet : brew install libnet.
2. you need to install libnids : brew install libnids
3. you need to install pynids : wget --no-check-certificate
4. Download tcpxtract from source forge:
  • extract the tcpxtract files into a folder using - tar zxvf tcpxtract.tar.xz
  • ./configure
  • Before doing make (try one of the steps)
    • cd /usr/lib  and sudo ln -s libl.a libfl.a (Flex issue, need to link the libraries -
    • add ldl flag after object files : gcc -D_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -g -O2   -o tcpxtract  tcpxtract.o sessionlist.o util.o confy.o confl.o conf.o search.o extract.o  -lpcap -lfl
  • make
  • sudo make install
How it goes:

$ ./tcpxtract -f ~/malware_pcaps_repository/botnet_cc_pcaps/Keylogger_Limlspy.A.pcap -o dump/
Found file of type "html" in session [ ->], exporting to dump/00000001.html
Found file of type "png" in session [ ->], exporting to dump/00000002.png
Found file of type "html" in session [ ->], exporting to dump/00000003.html
Found file of type "png" in session [ ->], exporting to dump/00000004.png

You can also check extending TCPExtract in Python:

2. Another solution :

Sunday, February 16, 2014

Intel XSS and Google Chrome XSS Auditor Bypass : Application Design Matters! Its True !

Last time, I talked about the role of application design in impacting the state of client-side XSS filters. You can read that blog post here: However, concentrating on that hypothesis, another case study came to my notice. I notified a Cross-site Scripting (XSS) bug in the Intel retailer website. The Intel security team removed the vulnerable web page from the its Internet facing environment. Responsible disclosure is the way to go.

What's the learning lesson here? Occurrences of XSS vulnerabilities are not new but the interesting part is how the vulnerable application impacts the browser defined security components such as XSS filters. In this case study, Google Chrome XSS auditor (enabled by default) again fails to perform the desired work for what is designed for.

The idea here is not to show that there is an XSS bug in Intel website rather to show execution of XSS payloads depends on the application design and there is always an unexpected behavior. Even sophisticated client-side XSS filters can be bypassed easily. I do not have time to investigate what caused the XSS payload to bypass Chrome's XSS auditor. I will notify the Google Chrome team so that they can take a look into it.

Proof-of-Concept: I used the very simple payload : JavaScript:alert(document.cookie) in "URL" parameter for the vulnerable redirect.asp webpage.

Injected XSS Payload !

The payload gets embedded as a hyperlink in the webpage. Amazingly, the XSS auditor accepted to render that payload. So, the XSS injection worked successfully and resulted in cookie extraction.

Successful XSS Injection !
Keep on trying !

Tuesday, January 07, 2014

Code Nuances (or Bypassing XSS Filters) : Case Study

It is always fun to play around with deployed security mechanisms that are used for subverting application layer attacks. It is much more interesting to target applications enabled with protections (or that throw code nuances)  rather attacking protection-free applications. A simple case study of is presented below.

Acknowledgement: I would like to thank Gavin from Hexillion Group ( for patching this issue within few hours.

Case Study: Recently working on a domain dossier (http:/// website for my ongoing research, I came across with interesting scenario where I have to bypass some glitches in the code (or filter) to execute the XSS code. I wanted to perform link injection with payload :
"/>&<a href=""> Injecting SWF Payload </a>
Error due to Injection !

The error I encountered was: "has multiple items separated by spaces, but only one input is allowed at a time. Domain Dossier will continue with"

The error clearly indicates that the input has to be provided as one value. It means the injection payload has to be pushed as one value. I tried a number of payloads with different meta characters which resulted in same responses until I found the XSS payload that bypassed everything in this scenario.  I played around with the white spaces and tried to remove them with certain characters that allowed me to execute the JavaScript (one can find more payloads but depending on the time, I was satisfied with that because the bypass was done already). Overall it was a game play for 10 minutes.

Original : "/><a href=""> Injecting SWF Payload </a>
Bypass: "/><a//href="">Injecting_SWF_Payload</a>
Bypass: "/><a/href="">Injecting_SWF_Payload</a>
Note: I used "/", "//" and "_" characters to treat the payload as one value and pushed it. As a result injection occurs as follows:

Successful Rendering of XSS Payload !
 The supplied payload resulted in successful XSS injection in the target application.

Successful Execution of Payload !

What do we learn from this?
During past years, I feel its more important to understand how exactly the attack is executed (analyzing the underlying components) . As per my experience, one attack vector might not work in all target environments, so we have to build a new one every time. In a number of earlier scenarios, I have seen that if we tamper the whitespaces between HTML attributes and tags, the code fails to render properly in the application. But, in this case study, we are required to embed additional characters in the payload for passing the payload as one value to the application.


(1) Understand the error and develop appropriate combinations to overcome nuances (or bypass XSS filters).
(2) Design XSS payload as per target environment.

Enjoy !

Wednesday, January 01, 2014

Reported Jenkins Vulnerability Patched by BlackBerry !

A couple of months ago, I discussed about the existence of configuration flaws in deployment of  Jenkins software management application. The details are presented here: Jenkins Configuration Issues. Based on the same benchmark, I reported a few vulnerabilities to BlackBerry in its infrastructure. Recently, I found that they added my name to the responsible disclosure list here: BlackBerry Responsible Disclosure List!.which is fine as long as the team eradicates the vulnerability.

Nowadays, I do not perform aggressive vulnerability hunting (due to my ongoing job) but, when I have time, I dissect components of widely used software and try to find flaws in them. I am more interested in the cases where companies understand the problem and ready to patch it. I am not at all inclined towards finding generic issues in websites which nobody cares about. I always believe that it is important to understand the cons associated with that existing vulnerability when it is reported. It is also crucial to determine how the attacker can chain together a set of bugs to have greater impact. If we don't understand the nitty-gritty details of the vulnerability, there is high chances that the vulnerability will resurface again. 

In this case of BlackBerry, unnecessary exposure of Jenkins component in production environment could resulted in  problematic scenarios. Exposed components of Jenkins were vulnerable to  flaws such as Injections, XSS, etc. So, the belief is: "Expose Less and Be Secure !"

Note: I am going to reveal Frame Injection vulnerability to Jenkins team so that the issue can be patched. No details for now.

Enjoy !

Sunday, December 29, 2013

Web Application Design Does Matter - Google Chrome XSS Auditor Bypass : Version <= 32.0.1700.41 m Aura !

Update (6th March 2014) : The post is also discussed on Stack Overflow here:, for additional discussion by the users.

Update: The bug has been reported to Google Chrome team already. The details can be found here: The team was not able to recreate the issue in the test environment. I validated this issue on the Command and Control (C&C) panel of a botnet :) and I was not in a state to reveal the details of that panel. Anyways the bug is in Wont Fix state and Google Chrome is still vulnerable to these types of XSS bypasses.

Recently, I encountered an XSS auditor bypass in Google Chrome ( &lt;= 32.0.1700.41 m Aura) while working on my research.

Google Chrome Latest Version Tested !
Although, the XSS auditor in Google Chrome is a client-side XSS filter that eradicates the reflective XSS attacks right away. One point that should be taken into consideration that, sometimes the design of the web application also impacts the working of XSS auditor leading to creating such scenarios which are not expected. Anyways, let's analyze a bypass in latest (and earlier) versions of Google Chrome browser. The web page URL looks like as follows: which generates the form as follows:

For Injection, we crafted the URL as follows:" onmouseover="JavaScript:alert(document.location)" name="?m=login . 
In this injection, we have not injected in "m" parameter rather we have played with the URI structure. The idea is to tweak the form layout rather the value accepted by the "m" parameter. If you place your injection in "m" parameter, it gets nullified by the XSS Auditor. Let's see how the injection occurs:

As a result, Google Chrome XSS auditor is bypassed.

Inference: Few ideas that should be taken into consideration:

1. The design of web applications impact the XSS auditor.
2. Instead of always targeting the HTTP parameters, play around with the URI structure also.

Note: Internet Explorer blocked this vector.

Additional Readings: Check out the inside details of Google Chrome XSS Auditor:
Enjoy !

Sunday, August 25, 2013

CCTV Cameras : An Interview for Fact or Fictional Show : Revision 3!

Recently, I did an interesting interview with Veronica from Fact or Fictional show on the Internet. We discussed about the issues and technology behind CCTV cameras. 

Do not forget to watch the movie on this topic-- "Closed Circuit" ! starring Eric Bana and Rebecca Hall.

Protect Your Software Development Web Interfaces - Information Lumps: A Case Study of Jenkins !

Automation of software development practices through applications has become the defacto standard in the security industry. Organizations are using support applications to reduce the workload in building and updating software.  The basic idea behind this post is to check how security is structured for software management applications such as Jenkins in a real time scenarios and what we need to look into while performing security assessments. Before discussing further, let's talk about Jenkins. According to the software website: "Jenkins is an application that monitors executions of repeated jobs, such as building a software project or jobs run by cron.". For more details, you can read here:

From software development perspective, Jenkins provides an integrated system which developers can use to manage software changes made to specific projects. It has been noticed that, although organizations use this software, but misconfigured interfaces (not running inside firewall and improper access rights) could have substantial impact. From security perspective, exposure of an integrated system that manages software development model could become a sensitive risk. To prove this fact, a case study of Jenkins application is discussed in which it is shown that how misconfigured and exposed interfaces could result in potential security glitches. 

These tests are conducted in an open environment. It has been found that several of the big companies use Jenkins and with no surprises the interfaces are exposed and running with improper authentication. In addition to this, there are numbers of Jenkins systems that are Internet facing and expose plethora of information to the attackers (remote users). A misconfigured Jenkins server results in disclosure of critical information that can be used in different set of attacks. A number of misconfiguration issues are presented below that result in information disclosure: 

Note: Based on this security issues, a few vulnerabilities have been reported to industry leaders (organizations) which have recognized the issue. I will release the details once the issue is patched.

Developers Information: Exposed Jenkins interface reveals information about the developers participating in the software projects. It is possible to extract userids of the registered accounts with associated names. This is a substantial point of gaining information about the users of a specific organization. An example of the exposed user details is shown below:

Exposed Developers Information !

Software Builds Information and Source Codes: It is possible to gain information about the software builds without any authentication (misconfigured scenarios).  Information about the changes in the software over a passage of time reveals information about the development flow of the components. Jenkins application does not ask for any explicit permission from the administrators to validate the user before accessing the ongoing software builds.  An example is shown below:

Exposed Software Build and Version numbers !
In certain scenarios, it is also possible to download the source code from the Jenkins without any authentication. Although for making changes to the code, you require credentials but the fun part is you can download code without them. Take a look at the example shown below:

Source Code Files !
Server-side Information Disclosure in Environment Variables: Access to environment variables also provides plethora of information. Example presented below shows the significant information about the configure MySQL (JDBC) database server. The attacker can easily glean username and password of the database (SONAR_JDBC_USERNAME & SONAR_JDBC_PASSWORD) including the internal IP address with port number on which JDBC service is running. 

Revealed Environment Information !

Exposure of Application Secret Data: During analysis, it has been found that a number of server side scripts have hard coded critical information such as secret-keys and credentials which can be exposed when console-output operations are performed. The underlined example shows how a secret key is extracted by accessing the console-output.  In this example, the curl command uses a secret key to connect to a specific domain for fetching JSON data through GET request. Once this information is exposed, the attacker can directly perform queries with the target domain. 

Revealed Secret Key !

Cron Jobs Execution: It is also possible to start the cron jobs which reveal plethora of information due to the usage of debugging calls. The majority of the time cron jobs produce a heck lot of output showing the success of running software. The example shown below presents the creation of database by a specific cron job in one of the vulnerable Jenkins configuration. It reveals how the table of OAUTH tokens is created and index is generated. 

Information Leakage through Cron Jobs !

Information Disclosure in Debug Errors: During a quick check in certain Jenkins configurations, it has been noticed that the Jenkins server does not handle the requests to restricted resources in a secure manner. The attacker can perform additional steps to request access to restricted resources to generated debug errors as shown below: 

Information Disclosure in DEBUG Errors !
Some of the standard requests specific to Jenkins are shown below:
Explicit CSRF Protection: It is always a good practice to analyze the design of the application from security standards. Some security standards should be deployed in the application by default. For example: - Jenkins provides a global security option in which protection against CSRF attacks have to be explicitly checked. If this option is not checked, the Jenkins application fails to deploy the protection globally. During our analysis, it has been noticed a number of Jenkins systems are running without CSRF protection which makes them vulnerable to critical web attacks.

Explicit Security Configuration !
SSH Endpoint Disclosure: Jenkins implements a SSH random port feature in which the software randomize the port selection for running SSH service. Typically, when a client sends a GET request, Jenkins replies back with "X-SSH-Endpoint" HTTP header which leverages the information in the form of host: port. It means SSH service is listening on following host with given port number. If the system is already exposed on the Internet, the attacker can easily glean information about the port number on which SSH server is listening. A real time example of a server running Jenkins is shown below:

SSH Endpoint Disclosure !

This information discussed in this post only provides a glimpse of security risks associated with the poorly administered software managing applications. These applications can provide a potential beef for the attackers to gain substantial amount of information about the organization and server side environment which facilitates the additional attacks.

For replicating the issues, trigger Google dork as: intitle: "Dashboard [Jenkins]" for getting a list of Jenkins server available on the Internet.

Impacts: As shown above, the misconfigured software management applications can have severe impacts as discussed below:
  • Information about developers can be used to conduct Phishing attacks including social engineering trickery to launch targeted attacks.
  •  A common mistake for not enabling the CSRF protection exposes the Jenkins environment to number of critical web vulnerabilities such as Cross-site File uploading.
  • In appropriate error handling discloses information about the different stack traces and internal components of the software.
  • Unrestricted cron jobs will result in successful running of different builds of the software. As shown above, information disclosed in the console output results in leakage of sensitive data such as secret keys. The attacker can use the secret keys to attack target servers.
  • Disclosure of software build information provides an attacker with a complete knowledge of the updates and modification that have taken place in the software. This information is beneficial for hunting security vulnerabilities or design analysis.

  •  For software development and management interfaces, restrict the access completely. It is highly recommended that the server should be configured with complete authentication. It means no functionality of the application should be allowed to be accessed without authentication or in a default state.
  • Simply removing the HTTP links from interfaces is not a robust way to restrict access. The links can be fuzzed easily to gain access to hidden functionality. Deploy security features using a global configuration.
  • Standard security protection mechanism should be enabled by default without asking any preferences from the users or administrators.
  • Administrator should verify the new account creation in software like Jenkins before an access is granted to the registered user.

Configure Well and Be Secure!

Sunday, August 04, 2013

BlackHat USA Arsenal 2013 : Sparty - A FrontPage and SharePoint Security Auditing Tool

Last week, I released the first version of Sparty tool at BlackHat USA Arsenal 2013. The tool helps the penetration testers to check standard security flaws in the deployment of FrontPage and SharePoint web software. The tool is an outcome of the security issues that have been found on the wide deployments of these web software.

I had an interesting discussion with Tom Gallagher from Microsoft who worked on the FrontPage and SharePoint security and related developments. I got very good feedback which I will incorporate in the next feature.  Gursev also provided some impressive points which I will work on.

Sparty is hosted here :

Enjoy and feel free to provide any feedback.

Wednesday, July 17, 2013

Internal IP Address Disclosure over HTTP Protocol Channel : Information Revealing Headers !

The disclosure of internal IP addresses to remote users reveals a substantial layout of the organizational network. It is highly advised that the web servers should not disclose internal IP addresses in the HTTP response headers. In a real time scenarios, this is not the case. The majority of web servers, load balancing devices and web applications disclose this information. This post simply discusses the different ways through which internal IP addresses are revealed over HTTP protocol.

You can read more about HTTP 1.1 specifications and working here:

1. Location Response-Header Field:  This response header is basically used for redirecting the HTTP request to a new location. It results in 201 response code when resource is dynamically created during the request. The 3xx (redirection 301, 302, 303, 304, 305, 306, 307) response value shows that location is predetermined by the web server and is the preferred one.

2. Content-Location: Similarly, Content-Location response header also discloses the internal IP address. This header presents a location of the resource when it is accessible on a separate URI in addition to the HTTP request. There is a potential issue in IIS web servers which reveal internal IP address in Content-Location header while redirecting the browser. More details can be read here:

There is a difference between in the usage of Location and Content-Location HTTP response headers. For reference, you can read this blog entry:

3. Via Header Field: This HTTP response is header is distributed by gateways and proxies present between the client (user agents - browsers) and the web server. The basic functionality of Via header field is to track message forwarding, avoid loops during processing and identifying protocol capabilities. Generally, this header reveals the internal IP address of the configured gateway or proxy as shown below:

 4. X-Cache Header: This response header is thrown by transparent proxies deployed as an intermediate agent between the client and server. The idea is to simply reduce the direct load on the website by placing a copy in the cache and responding with the same when HTTP request is initiated by the client. There are other functionalities associated with transparent proxies also. The internal IP address can be revealed in two scenarios as discussed below:

4.1 X-Cache Miss: When the transparent proxy does not have a local copy of the website or web pages requested by the client.

4.2 X- Cache Hit:  When the transparent proxy has a local copy of the website or requested web pages.

You can read more about the X-Cache headers here:

5. Set-Cookie Header:  A number of load balancing devices use Set-Cookie for setting custom content as a part of communication channel to activate the session with the backend web server. The internal IP address can also be disclosed as a part of Set-Cookie parameter. A simple example is the BIG IP devices which basically reveal the internal IP address in binary encoded form.  Be default, it is the functionality of BIG IP devices to handle HTTP connection pooling based on IP addresses. In the screenshot shown below, the pool parameter holds the value of internal IP address

In my earlier presentations (couple of years ago), I talked about extracting the IP address from the BIG IP http_pool Set-Cookie parameter. The concept is shown below.

These are the some of the HTTP headers over which internal IP is exposed. While deployment, one should verify and validate that these headers should not expose unnecessary information.

Note: If anyone has additional information regarding Internal IP address disclosure over HTTP channel, let me know and I will update this entry. The idea is to collect all the metrics.


Monday, May 20, 2013

Contrarisk Security Podcast Series: A Talk on Socioware!

I recently did a podcast on the Socioware with Steve from Contrarisk.

"Microsoft recently warned about Man in the Browser (MitB) malware exploiting Facebook sessions. When a user is infected – often by drive-by downloads on infected or malicious sites – the malware uses authenticated sessions on Facebook to post messages, ‘like’ pages and get up to general mischief."

Listen to the podcast here: