I’m going to walk you through finding bugs in the Damn Vulnerable Web App (DVWA) with HTTPfuzz, but you can apply this steps to any target as long as you have permission from the owner. HTTPfuzz is a flexible HTTP fuzzer written in Go. It can fuzz any part of a request: multipart file uploads, multipart form fields, text request bodies, directories, filenames and URL query parameters.

Attacking services without consent is illegal in most countries. You can follow along using Docker on your computer without risking your freedom. Be sure to stop the container when you’re done using it, and only bind it to localhost to prevent yourself from getting hacked.

Caveat Emptor

A fuzzer is a very clumsy tool. It can knock systems offline, lock user accounts, fill up databases and generally annoy our friends on the blue team. I’d recommend only running a fuzzer against a development instance of the app. It’s useful for finding bugs before the software goes to production. Don’t run a fuzzer on a shared application unless you’re sure your inputs won’t cause damage and you have permission from the operations team. It’s best to set a delay between requests if you’re running HTTPfuzz against a shared application, and be sure to check how many requests you’ll send before firing your lasers.

What is HTTPFuzz?

HTTPfuzz is a flexible CLI HTTP fuzzer written in Go. It supports fuzzing any part of a request body, including multipart file uploads, JSON fields, HTTP Headers and URL parameters. HTTPfuzz can be extended with Go plugins for better integration with your pentesting workflow.

Plugins

HTTPfuzz plugins are simply Go plugins that export a method named New that returns an implementation of HTTPfuzz’s Listener interface. Everything you need to know to write plugins is in the gist below.

A Listener receives a stream of Results from the fuzzer. A Result contains the HTTP response from the target, the corresponding request, the payload, payload location and the time the request took. Plugins can use this to save requests and responses to a database, check for vulnerabilities and anything else you can think of.

File Uploads

Many apps allow users to upload files for all kinds of reasons: photo galleries, documents, scanning cheques and much more. File uploads expose tons of attack surface. XSS, path injection, introducing malware into a network, remote code execution and so much more is available to you by bugs in file uploads. DVWA is no exception.

File upload in DVWA. Do you notice anything interesting about the filename?

Automatically Generated Files

The easiest way to check which file types are allowed is simply uploading different kinds of files and looking at the responses. If a website says it only accepts photos, try uploading a PHP file or an executable and see what happens. For example, JPEG photos always start with the bytes FF D8 FF. You can use a hex editor like Hex Fiend to see the byte patterns at the beginning of every file of the same time.

If the whitelisting is done correctly, it will check the first few bytes of the uploaded file against a list of expected file signatures. HTTPfuzz generates files by putting header bytes for the file type at the top of a byte array filled with random bytes. These generated files will probably not be valid, which is why you’d use user-supplied payloads once you’ve determined how restrictive the validation is.

We can combine this with a simple plugin that tells us when a file has been successfully uploaded to let us enumerate the allowed file types.

Build the plugin and send off the automatically generated file payloads. We’ll be able to see what’s allowed based on what is successfully uploaded.

Running this reveals that DVWA does not perform any filtering at all on uploaded files: it’s a free for all.

User-Supplied Payloads

Now that we know what kind of files are allowed, it’s time to see if any vulnerabilities can be exploited. We should see if we can exploit bugs in how DVWA handles filenames and types based on what we discovered with the automatically generated files. Since we know DVWA doesn’t perform any filtering, we should try for PHP code execution.

PHP Code Execution

One of the payloads was a PHP program that would display information about the server’s PHP environment. Since DVWA has a file inclusion vulnerability, we can execute our payload by passing the saved payload’s filename to the vulnerable “page” URL parameter.

Using the local file inclusion vulnerability to trigger our payload.

We could stop here since we owned the box, but I want to show you some more HTTPfuzz features.

Command Injection

You can mark targets in text request bodies with the delimiter character. By default, it’s “`”. The command injection challenge sends an IP address via POST request to a vulnerable ping function. You can often find vulnerabilities like this on routers and online vulnerability scanners. Consider the following request:

We’re trying to execute code on the DVWA. We’ll try the Unix and Windows command injection payloads from the command-injection-payload-list and examine the results in an intercepting proxy to see if any of these give us a clue how to exploit the vulnerability.

Brute Force

HTTPfuzz makes it easy to brute force your way into valid accounts. The DVWA has a brute force challenge that accepts the username and password as GET parameters. Consider the HTTP request below.

First, we’ll need a wordlist with common passwords. I’ll use rockyou.txt for this demonstration. We’ll also need to differentiate between successful and unsuccessful login responses. An easy way to do this is to submit an invalid password and observe the response.

The message “Username and/or password incorrect.” always appears when login fails.

Trying to send a bad password gives an error message. That’s good enough for us. We can create a HTTPfuzz plugin that returns the payload used when that error message isn’t in the page. That payload should be the password.

Build the plugin and pass it to HTTPfuzz to see if admin’s password is in rockyou.txt. Since the password is in rockyou.txt, the plugin will print it so we can solve this challenge.

Running this attack shows that the admin’s password is indeed in rockyou.txt. This attack may seem contrived, but many appliances and programs have known default passwords. The Mirai botnet) spread by brute forcing known default router passwords via telnet.

Get httpfuzz

You can check out httpfuzz on GitHub. It’s written in Go and GPLv3 licensed. It runs on Windows, Linux and macOS. It’s a versatile HTTP testing tool that can perform many attacks, like dirbuster style directory brute force attacks and HTTP header fuzzing.

What is Judas?

Judas is a pluggable reverse proxy for red team phishing engagements based on Go’s httputil.ReverseProxy. Simply point it at the target website, give it a domain for the SSL certificate and you’re on your way. Judas makes a byte-for-byte copy of the original requests and responses making it impossible to tell the difference between a phishing site and the original without checking the URL bar. Victims will be able to log into the target and use it like they normally do.

Judas cloning targetpractice.network on localhost:9000.

(I own targetpractice.network, don’t use Judas on websites you don’t have permission to attack).

This is made possible by supplying functions for the ReverseProxy struct that rewrite requests and responses on the fly. ReverseProxy is versatile: you can use it to build Web Application Firewalls, patch vulnerabilities in services you can’t update and much more. It’s worth adding to your toolkit no matter which team you’re on.

Stealth Goodies

Judas comes with some features to help us hide from the target server and victims. We want to stay hidden from the blue team as long as possible to increase our chances of compromising a high value account.

Automatic Let’s Encrypt

We’ve spent the last few years conditioning people to trust that padlock in their URL bar. Thanks to Let’s Encrypt, we can get free SSL certificates automatically. Simply tell Judas your phishing site’s domain and it’ll do the rest.

Proxy Support

Judas is able to use a HTTP or SOCKS5 proxy. You can hide requests from your target using a proxy, log them in case a client wants to see what exactly you took, get an IP address close to the target and much more. You can do multiple of these at once with proxychains.

HTTP Request Header Rewriting

Judas automatically rewrites HTTP request headers before sending them to the target website. It replaces the our phishing site in the Referer and Origin headers with an appropriate value and removes the user agent if the user didn’t send one to prevent Go’s default User Agent from showing up in logs and giving us away.

HTTP Response Header Rewriting

Judas automatically rewrites HTTP responses before they come back to the client. It removes any Content-Security Policy and anti-XSS headers on the response to prevent them from catching the phishing proxy and sending it to a report-URI (sorry blue team). It also rewrites the Location header to stop redirects with the full URL from sending the victim back to the original site.

Plugins

Real life is complicated. Maybe you need to phish a lot of people, or maybe you want to do something on behalf of a phished user because they have 2-Factor authentication enabled. Judas lets you use Go plugins to:

• Modify requests after they’ve been sent by the victim to enable attacks like replacing an admin’s request with a request to create a user for us
• Modify responses before they’re received by the victim so we can hide the results of attacks or hit victims with an exploit kit.
• Process request — response HTTP exchanges from victims in real time to programmatically extract sensitive information or store them in Azure CosmosDB to look at later.

RequestTransformers

A RequestTransformer is a function in a Go plugin named “RequestTransformer” that modifies an http.Request from a victim in place before it’s sent to the target. It should be fast so users don’t get suspicious or turned off by delays. You can use them to hijack legitimate requests. For example, a RequestTransformer could replace an admin users’s request with one that creates a user for us to gain access to protected systems.

ResponseTransformers

A ResponseTransformer is a function in a Go plugin named “ResponseTransformer” that modifies an http.Response from a target in place before it’s received by the victim. You can use them to hide what you’ve done from a target, or hit victims with an exploit kit.

Listeners

A listener runs in its own goroutine and receives request — response HTTP exchanges from victims in real time to allow us to extract sensitive information. The plugin loader looks for a function called “New” that returns a Judas Listener in a Go plugin.

Using Plugins

Once you’ve made a plugin, compile it and load it using command line arguments. Multiple plugins can be loaded be separating the plugin file paths with colons (“:”). There’s an example plugin with all 3 operations implemented on Judas's Github page.

Get Judas on Github

Judas’s source code is on Github. It’s MIT licensed, so feel free to modify it, fork it or whatever you see fit to do with it. Just don’t use it for crime. I’m not responsible for anything illegal you do with Judas, and I will laugh at you when cybercrime authorities in your country break your door down. Use your skills to make the world a better place instead of spreading misery.

Before we start, you need to know that great reward comes with great risk. Don’t do this with money you’re not willing to lose.

Sunrise in St. Elizabeth, Jamaica. One of the best places in the world to spend your trading profits.

Getting API Keys

The first thing you’ll need is a TD Ameritrade account. You don’t need to be a US citizen to get an account, and the process is pretty easy. If you’re in Jamaica, you’ll have to send TD Ameritrade signed copies of the documents they give you via Fedex or DHL. After you’ve signed up for TD Ameritrade, head over to their developer website and sign up for a developer account. Create an app and specify it. TD’s developer website will not accept a Callback URL that doesn’t begin with https, even if it’s localhost. You can test applications locally by removing the “https” with “http” in the URL bar after the redirect, or serving localhost over TLS.

The app Callback URL must begin with https://

Once you’ve created your app, its client ID will be available to you in the dashboard. It seems you can only create one app per developer account.

The OAuth2 Client ID is available as the Consumer Key in the dashboard.

You can use this client ID in any OAuth2 client library to interact with TD Ameritrade’s API. If you use Go, I’ve written a TD Ameritrade client library that handles authentication and interaction with the TD Ameritrade REST API, and if you use Python, Alex Golec wrote a python wrapper.

API Documentation

TD Ameritrade’s documentation is available on its developer website, but it is not as comprehensive as you may be used to from companies like Apple and Google. There are several surprises in their API that I’m going to tell you about to make your life easier.

Client ID Surprise

You have to append @AMER.OAUTHAP to your OAuth2 client ID, or it will return an error. This is only documented on their Authentication FAQ and Getting Started Guide in the example URLs.

The dreaded “This may be due to a technical error, or the client application may be an attempt to fraudulently access your account.” error

PaperMoney Doesn’t Work

TD Ameritrade has a world class demo trading platform, PaperMoney. It has real time data when you have a funded account with TD Ameritrade. It’s the best demo trading platform I’ve ever used. It’s also not available via the API. It’s not clear when, if ever, TD Ameritrade will make demo accounts available via the API. It’s best to test your strategy with the data using a backtesting library, but make sure that your orders would actually fill given the state of the liquidity in the order book at the time before going live.

Real Time Updates

TD Ameritrade provides free real time market data over a websockets API. Alex Golec’s python wrapper allows you to process the market data in real time using Python’s async feature.

Risk Management

The most important skill when trading is risk management. This is even more vital when running an automated trading bot, since computers can lose lots of money very quickly. You’ll need to defend against hackers and trading losses.

The bigger a loss, the harder it is to recover. Image from fusioninvesting.com

Avoiding Margin Calls

• Don’t run your trading bot on your main investment TD account. Create a new account and fund that with a smaller amount of money to trade on.
• Ensure your bot has trade size and daily loss limits specified in dollars (not percentages) to prevent bugs from causing you to blow up your account. You can make these configurable so they can grow with your account.
• If you’re trading options, futures or other leveraged securities, be sure to take the total risk into account when designing your limits. A leveraged position can be very volatile.
• Monitor your account balance using TD Ameritrade’s apps. This will protect you from bugs in your code telling you you’re making millions when you’re really on your way to a margin call.
• Run the bot in demo mode by default and create a switch to place live trades to stop yourself from accidentally running with real money when you think it’s paper money. For maximum assurance, have the bot require an explicit command to begin placing trades.
• Ensure there is an easy external killswitch that will stop all trades immediately in case of runaway losses. My bot runs on an Azure VPS, and can be killed quickly by simply shutting the VPS off from the Azure Portal. This lets me kill the bot even if my VPN is down, or the program isn’t responding to kill signals from the OS.

Hosting and Security

Your trading bot will have access to your money. Although you cannot withdraw money via the API, hackers can steal from you in other ways, like having you sell all your holdings and purchase some low liquidity, worthless securities that they hold at a higher price, like the VIAcoin pump on Binance.

• Do not give your bot server a public IP address. Use a VPN or a gateway like Cloudflare Access to access your server. If you’re self-hosting a VPN, ensure the VPN and VPN server OS are always updated to the latest versions.
• Use firewall rules to limit access to only the ports used by your bot, and only allow it to send traffic to TD Ameritrade and your OS’s update servers. If possible, limit traffic at the network level, like Azure’s Network Security Groups or AWS’s Security Groups instead of relying on a host-based firewall. Do not use unencrypted network protocols to control the bot. I’d recommend using HTTPS with TLSv1.2 or TLSv1.3.
• Only install the bot and software necessary for it to run. I like Go because it can produce a single static binary that runs on a minimal Linux distro or Windows Server install.
• Keep the OWASP Top 10 in mind when building the bot. Use modern software development frameworks that help mitigate against bugs like XSS and CSRF. Be sure to write automated tests for your code, especially your trading strategies and limits and ensure code can only be merged into your master branch after all its tests pass. Be sure to leverage static analysis to catch bugs where possible, and I’d recommend using a statically typed programming language so the compiler and type system can help you write accurate code.
• Ensure you update your library dependencies regularly. Vulnerabilities in dependencies can compromise your bot and cost you money.
• Ensure your bot server is monitored. Track your logs and system performance using an external log monitoring system, and set alarms for strange events, like new processes, or attempts to send network traffic to non-approved sources.
• Use a cloud provider like Microsoft Azure or Amazon AWS. They can likely provide better uptime and security than you can on hardware you operate. Your mileage may vary. Start with the smallest VPS and scale up as needed.
• Use a dedicated device to access your trading bot. Install as little third party software as possible. Ideally, you’d only install a browser and the VPN client. Use TD Ameritrade’s website to monitor your performance.

My Setup

I run my bot on an Ubuntu 20.04 VPS on Microsoft Azure in a private subnet only accessible on port 443 via VPN using Azure Network Security Groups. The bot web UI is only available via HTTPS, and the server is only able to send traffic to TD Ameritrade’s API server and the OS update servers.

The server has a managed identity that it uses to access other services within the Azure account. Secrets like TLS certificates are stored in Azure Key Vault. I monitor my server logs and performance with Azure Application Insights, and I monitor traffic to and from the server’s subnet with Azure Traffic Analytics.

The bot is a single binary built in Go. It exposes a web UI on port 443 over HTTPS only (I don’t need automatic HTTP -> HTTPS redirects) and does not use many non-stdlib libraries to reduce attack surface and dependencies to keep current. It is the only non-default program running on the VPS.

Trading Strategy

This is the hard part. Your bot is useless unless it’s executing trades based on a profitable strategy. I’m not going to tell you how to come up with this part. Read about technical analysis and fundamental analysis. You can use external data, like news feeds and social media to influence your trading strategy. It’s best to automate a profitable trading strategy that already works for you manually. Read posts on /r/algotrading for inspiration.

Trade on TD Ameritrade with Go

If you made it this far, you’re probably really interested in algorithmic trading. I created go-tdameritrade, a fork of Zachary Rice’s go-tdameritrade to make it easier to write trading bots. It’s free and open source. Use this library at your own risk. Automated trading can cause you to lose money very quickly.

SSHing into an Ubuntu 20.04 Thinkpad on my home network via the VPN.

Wireguard was designed with mobile devices in mind. It uses battery-friendly cryptography and the protocol can handle endpoints that change IP address seamlessly. It is ideal for exposing local development servers on my laptop to my iPhone, but deploying configuration to a device is a manual and time-consuming process.

WireguardHTTPS is a Wireguard access server written in Go that allows users to log in with Azure AD and manage access to the Wireguard VPN.

WireguardHTTPS generates configuration and creates QR codes for easy deployment to mobile devices.

WireguardHTTPS is intentionally very simple. It only allows users to add devices to the VPN, regenerate device credentials and remove devices from the VPN. WireguardHTTPS does not store private keys: once a device has been created, future attempts to download its credentials will revoke the device’s access to the VPN and generate new credentials.

WireguardHTTPS only allows regenerating credentials and deleting a device.

Devices are automatically assigned IP addresses in the subnet specified when setting up WireguardHTTPS. When a device is deleted, its IP address is released for reuse by a future device.

Architecture

WireguardHTTPS is made of 3 components to limit privileges required by the internet-facing HTTPS API while allowing it to control the higher privileged Wireguard interface and protect users from common web attacks like XSS, Clickjacking, and CSRF.

A root gRPC daemon, wgrpcd, controls the Wireguard interface. Wgrpcd manages devices directly on the Wireguard interface using wgctrl and responds to gRPC messages from other processes. It is not aware of IP address allocation, DNS or Azure AD users. It simply validates input received from its gRPC API and manipulates peers on the Wireguard interface.

A low privileged user runs WireguardHTTPS, a REST API that provides authentication, IP address allocation, device DNS settings, and device management. It is exposed directly to the internet without a reverse proxy. WireguardHTTPS allocates IP addresses in its database from a subnet provided by the user at setup. WireguardHTTPS assigns devices IP addresses from this pool, and a device’s IP address is released when it is deleted. It uses wgrpcd’s gRPC API to perform the desired operations on the Wireguard interface. PostgreSQL transactions ensure Wireguard interface and database are kept in sync to avoid IP address conflicts and stale data. WireguardHTTPS does not store any identifying information from users apart from their authentication provider ID, and can easily be modified to support other OpenID providers like AWS Cognito.

WireguardHTTPS is meant to serve its UI: wgreact, a ReactJS single-page app. It uses Gin’s static file server middleware to serve the final Javascript application generated by webpack with a restrictive Content Security Policy, anti-framing headers, anti-XSS headers, and a limited set of TLSv1.2 and TLSv1.3 cipher suites. It is a single page and allows users to add, view, rekey, and remove their devices.

Use Cases

• Expose services in private networks to connected devices, even if they’re behind a NAT or in a private VPC. You can host an instance of Gitlab on a computer at home to create a private source code repository and much more.

• Move unencrypted traffic from untrusted networks to cloud networks to protect against man in the middle attacks.

• Use a static IP address from any network, even on a cell phone.

Source Code

This entire setup is open source. You can see the source code for wgrpcd, WireguardHTTPS and wgreact on Github. WireguardHTTPS is still under development and has not yet been audited. I don’t recommend using this software for anything important. “WireGuard” and the “WireGuard” logo are registered trademarks of Jason A. Donenfeld.” You can download Wireguard at https://www.wireguard.com/

Getting stock prices from Alpha Vantage with Postman

Postman allows you to write chai.js tests in Javascript that will run after each response and let you make assertions about the response body. These tests can also be run headlessly with Newman and added to your build pipeline, but I’ll talk more about that later.

The Postman test Sandbox contains several useful libraries, functions and objects for testing. A list of them can be found on the Postman Sandbox reference page.

Contract Tests

Contract tests allow you to verify that API request and response schemas have not changed. This is especially useful when working on a mobile application with a large team with separate mobile and API developers.

First you must generate a JSON schema for the response bodies. If you don’t want to do this by hand, you can use an online generator, like the one at jsonschema.net. For this demonstration, I’ll be running tests that verify that Alpha Vantage’s Stock Quote API contract has not changed.

It is convenient to store schemas, base URLs and other common variables using Postman’s environment variables and parse the JSON in each test, to allow multiple tests to reuse the same schema. Postman’s Sandbox comes with tv4, a JavaScript schema validation library, that handles all the heavy lifting. All that is required of you is to call the tv4.validateResult function.

Testing that Alpha Vantage’s stock quote API contract has not changed.

The function will return an object with a valid property that will be true if the object matches the schema.

In addition to the schema, it is useful to check that response codes and content types are all as expected. Since Postman does not return much detail about failures, it is best to only put one assertion per test, to pinpoint exactly where the error has occurred.

You can test this sample in Postman with the collection.

Security Tests

Postman tests can also be used to perform automated security tests.

Combined with an automated build pipeline, security tests that fail when a vulnerability is present will prevent vulnerabilities from being re-introduced at a later date by developers.

Since jail is real, I’ll be demonstrating this suite using Google Gruyere’s sandbox.

Sometimes real world exploit scenarios in web applications involve multiple steps. Many vulnerabilities require authentication tobe exploited. Thankfully, Postman makes this easy using its collections test runner.

In Google Gruyere, there is an authenticated stored XSS vulnerability where a user can submit JavaScript code in a snippet and have it executed by anyone who views their instance’s home page.

First, we need to log in and get the authentication cookie.

Logging in to Google Gruyere using Postman and setting the cookie in the environment.

Postman allows you to set environment variables by using the pm.environment.set function. This is very useful for test cases that are dependent on the responses of previous requests, such as authentication headers and account numbers. Thanks to this, tests can be more dynamic and cut down on the use of hardcoded data.

Since this application uses cookies, we set the cookie into the environment variable “cookie”.

Environment variables are surrounded by 2 curly brackets.

Cookies can be managed by setting the Cookie header to the “cookie” Postman environment variable. Doing this on each request will automatically include the correct value.

Submitting XSS payload.

Next, we submit the request with the payload. The input should be validated in this case to ensure it doesn’t contain dangerous HTML payloads while still allowing harmless HTML through.

This test will fail if the XSS vulnerability is still present.

Finally, we test that the unencoded JavaScript payload that triggers the vulnerability has been sanitized. Once the developers have fixed these bugs, this test suite will pass.

The Postman test runner running through the exploit chain.

Writing security tests using Postman allows for a test suite that will pass when vulnerabilities are fixed. It is important to note that a passing test suite does not mean that the vulnerability has been patched fully, so manual testing with other vectors is still necessary. Creating a test case to reproduce the additional vector will help the developers create more secure software.

If you want to play with this collection, you can download it here and the environment here.

Newman and your Pipeline

To really see the benefits of automated Postman tests, it’s best to add them as a build step using your Continuous Integration build pipeline software. Newman allows you to run Postman test collections whenever code is pushed to your repository.

First, export both your environment and collection as JSON files. Then, simply tell Newman where your environment and collection are and run it.

Adding that command to your build pipeline will let Newman run your tests every build, and prevent regressions.

Try It Out

TargetPractice has vulnerable servers that you can hack to your heart’s content. Test real tools and exploits that work on live targets without going to jail. It’s not a crime if it’s TargetPractice.

No, not like that

How it works

The cloak and dagger attack takes advantage of two Android permissions:

1. SYSTEM_ALERT_WINDOW (The Cloak)
2. BIND_ACCESSIBILITY_SERVICE (The Dagger)

The Cloak

SYSTEM_ALERT_WINDOW is used to draw over other Android apps. If an app installed from the Play Store requests this permission in its AndroidManifest.xml file, it will automatically be granted by the system. This forms the first building block of the cloak part of the exploit. Many apps use this permission for legitimate purposes, like Google Maps.

Google Maps uses SYSTEM_ALERT_WINDOW to display directions when its in the background

Malicious apps, however, can take advantage of this feature to cover a user’s UI and trick them into clicking activities below the overlay. In the cloak and dagger attack, the user is tricked into enabling the malware’s accessibility service.

For security reasons, Android only shows the coordinates of taps made inside an overlay to an overlay’s OnTouchListener. Any taps outside the overlay will return the coordinates (0, 0). While this hides the exact coordinates of touches outside the malicious app’s overlay, the app can cover the entire screen except the areas they want the user to click. Since Android returns (0, 0) for touches outside the screen, a malicious OnTouchListener can cover the screen and adjust the overlays to disguise the next stage of the attack once the user has clicked on the desired area.

The cloak portion of the attack. The entire screen is covered except the areas that trick the victim into enabling the accessibility service.

The demonstration uses translucent overlays, but a real attack would use an opaque distraction.

The Dagger

Once the victim has enabled our accessibility service, we have de-facto control over the device. Android sends the service’s onAccessibilityEvent method) information after most user activity, including keystrokes, lock screen key presses, URLs and much more.

The dagger capturing a user’s lock screen PIN

The accessibility service is also able to send touch events to other apps, allowing it to take control of the device. At this point, we don’t even need root. The cloak fun also doesn’t have to stop with tricking the user into enabling the accessibility service. Since the accessibility service gets notified of a victim’s every move, malware can use overlays to hijack a victim’s banking apps and hide evidence of itself in the accessibility settings menu.

Demo

A proof of concept is on Github. You’ll have to manually enable the “Draw Over Other Apps” permission since you’ll be sideloading this app. The attack has been tested on the following devices:

• Nexus 5X Nougat
• Nexus 5X Marshmallow
• Nexus 4 Lollipop

It’s best to use an emulator of one of those images. You’ll have to adjust the overlay sizes in the Stage subclasses to match the screen size of any other device you want to get it working on.

Level Up Your Hacking Skills

TargetPractice has vulnerable servers that you can hack to your heart’s content. Test real tools and exploits that work on live targets without going to prison. It’s not a crime if it’s TargetPractice.

Suddenly, the app stops working. Nothing shows in Burp and no HTTPS requests work. The developers have implemented SSL pinning and your phony certificate has been detected. Fortunately, SSL pinning can be disabled if you’re willing to get your hands dirty.

Decompiling the App

First, you need to decompile the app. Apktool works great for this, and it’s available on all platforms. Follow the install instructions and then decompile the APK.

This command will produce a directory with the AndroidManifest.xml, resource files and Smali bytecode.

Removing the pin

Next, you’ll need to remove the pinned certificate from the application. It’s easiest to use grep to look for “CertificatePinner”.

This will return a list of files in the app that use SSL pinning with OkHttp. It will bring up instances in third party libraries that may need to be disabled as well. Look through to see where the app is pinning its certificate. Once you find it, open the file in your favourite text editor. According to OkHttp’s CertificatePinner documentation, certificate hashes are added using the CertificatePinner.Builder’s add method. We need to look for the Smali bytecode that corresponds with the method call and remove it to neuter the SSL pinning.

Removing the two lines above will get rid of a pinned certificate. You’ll have to repeat this for every certificate hash the app pins.

Rebuilding the APK

After you’ve removed the SSL pinning, rebuild the APK using apktool. You’ll have to zipalign the APK and resign it with your signing key to get Android to accept it.

If you don’t have a signing key, you can generate one using keytool.

Finally, install the APK on the target device. If the previous version is already installed, you’ll have to uninstall it so Android doesn’t detect the different signatures.

After doing this, you should be able to intercept requests from the app.

Happy hacking!