Recently, during a red team engagement with my colleague Maurizio, we came across a website that seemed very outdated. Quickly analyzing the HTML, we noticed something that brought a smile to our faces: a Java Applet.

First thought: the backend will definitely not work anymore… But what if it works!

First, we needed to run the applet. A possible solution would be to run it in an old browser in a VM, but we would leave this option as a last resort. Instead, we installed a version of OpenJDK 8 and used the appletviewer binary to run the applet. We preferred to use a not-very-recent version of OpenJDK to minimize compatibility issues with the old Java version probably used to compile the applet, and if I’m not mistaken, the appletviewer binary is no longer available in the latest Java versions.

Of course, making it work and routing the traffic through Burp Proxy took some time and required fixing various issues related to signatures, certificates, TLS ciphers, proxies, and so on. Without delving into the details of all the issues, this is a summary of how we managed to make things work in our scenario.

First, we created the following Java policy to disable the security manager in the applet (saved in file “java.policy”):

Hi there!

Today we will see how to add components to the Burp Suite interface that are useful for conveniently managing different scenarios. In detail, we will focus on how to create new tabs for processing HTTP requests and responses.

But as always, let’s start with a use case and explore some ways it can be handled. We are analyzing a mobile application that adds an encryption layer to the HTTP request and response bodies. The mobile application encrypts the body using AES before sending the request and decrypts the response body in the same way, as it is encrypted by the backend application. I mention mobile applications because this scenario is more common in the mobile world, but over the years, we have also seen web applications behaving in a similar manner, encrypting and decrypting in the browser using JavaScript libraries.

A simple Flask Python application that does this job is the following (encryption/decryption stuff taken obviously from StackOverflow – necessary Python packages: flask and pycryptodome):

Hi there!

In the last article of the series we learned how to develop the most commonly used type of Burp extensions during a penetration test, namely HttpHandler plugins (or HttpListener in the old APIs). These plugins allow us to inspect or modify all HTTP requests exiting from every tool in Burp Suite and all incoming responses. Today we will see how to do a similar thing when our target application uses WebSockets.

WebSocket is a stateful full-duplex protocol supported by modern browsers, usually employed in applications that need real-time updates. Until a few years ago, Burp Suite only partially supported WebSockets (I used OWASP Zap for WebSocket testing instead, as it supported them better). Then Burp Suite improved its support over this technology and now WebSockets are well integrated in the Proxy and Repeater tools.

Speaking of extensions, WebSocket support was introduced only with the Montoya API, which is another reason to choose them over the previous APIs, even though they don’t currently support Python and Ruby. Over the years, I’ve come across many applications that used WebSockets and for which I needed an extension (which was often already available publicly for the HTTP counterpart), and the lack of support for this technology was a sore point. Now, as we will see, we can finally inspect and modify WebSocket requests in a similar way to what we did for HTTP requests.

As always, we start from a test scenario that uses WebSocket. For the purpose, I made a few small changes in one of the examples of the Flask-SocketIO project (an integration of SocketIO for Flask). The app.py example of that project runs a simple chat server using SocketIO and it is perfect for our purposes, because it can use WebSocket for communications.

Hi there!

Today we will cover how to develop the type of extension most commonly used during a penetration test, namely HttpHandler plugins (or HttpListener in the old APIs). These plugins allow us to inspect or modify all HTTP requests exiting from every tool in Burp Suite and all incoming responses. It is possible to inspect and modify the traffic of specific tools in Burp Suite through other types of plugins as well, but these HttpHandler plugins provide access to all outgoing and incoming traffic.

With the new Montoya API, we can also inspect and modify WebSocket traffic, one of the features I have been eagerly awaiting for a long time (or better, the feature I have been waiting for the most). Before Montoya API we could write great plugin to handle encryption, signature, encodings, etc. in HTTP requests and responses and we had to keep our fingers crossed that the application didn’t use WebSockets. Otherwise, we could use Burp Suite only in standard scenarios and we had to switch to much more inconvenient tools in more complex ones.

Let’s consider the following example scenario: we have an application that adds a SHA256 hash of the body in an HTTP Header (usually things are a little more complex with for example a HMAC-SHA but let’s keep things simple). If we intercept a request and modify a parameter in the body without regenerating the hash, the request will be rejected by the backend. In the Proxy and Repeater, we can consider manually regenerating the SHA256 for each request we send, but this could significantly slow down the testing process and be quite annoying…

Hi there!

I have been thinking for a long time about releasing a course or lessons on developing extensions for Burp Suite (and to tell you the truth, I had already created a draft course with accompanying extensions some time ago), and what better opportunity than the release of a new API to start the project!

Burp Suite is an exceptional suite of tools that currently stands unparalleled in the world of web application penetration testing. In addition to the HTTP proxy, it provides fuzzing tools, an excellent automated scanner, a request repeater tool, and more. However, personally, the tool I find most remarkable since I started using Burp is undoubtedly the Extender.

The Extender offers a set of APIs that allow for convenient and effective extension of every tool offered by Burp Suite. It provides full control to the penetration tester over all outgoing requests and incoming responses, enabling enhanced customization and flexibility. Thanks to it, over time, third-party plugins have been developed that can support frameworks and protocols, handle complex situations, identify issues, integrate Burp Suite with external tools, and, more generally, make the life of a penetration tester easier by maximizing effectiveness and results.

Disclaimer: as many other security researchers approaching IoT, I have a background in computer science and I started to work on these subjects with little knowledge about electronics and often with a “YOLO” approach (blame it on an old colleague of mine ). So, it is definitely possible that many of the things you will read here can be inaccurate or can be done in a much better way, especially with more knowledge in the field. Sorry about that. I take advantage of this disclaimer to add a thing: pay particular attention when you put your hands on electronics, especially when you deal with cheap Chinese devices powered by 220V! Some capacitors can cause serious damages even if the device is not plugged into the electric socket!

Today we will have a look at the ports we discovered in the first article of this blog series in our initial analysis with the device powered off. The ports we discovered were the following:

Hi,

Last year (I know, I’m “a little” late with this article ) I tested a couple of applications that employed the Protocol Buffers data format (aka “Protobuf”) to serialize data transmitted using the HTTP protocol. Protobuf serializes data in binary format, not the ideal situation from a penetration tester’s perspective. So, as usual, I first searched for a Burp Suite extension able to deserialize/serialize Protobuf messages, in order to be able to inspect and tamper requests and responses in a more comfortable way.

In the BApp Store there is an extension named protobuf-decoder created for this purpose. I installed and tried it. Unfortunately, this extension has a lot of bugs and many functionalities are only partially implemented, which seems to indicate that something went wrong probably in the code added in the last releases. Furthermore, it is not clear who the maintainer is, because the PortSwigger’s fork of the extension is 37 commits ahead of the forked repository of a potential owner/maintainer (that is in turn a fork of another repository).

By the way, my target applications were quite complex and I really needed to overcome the Protobuf inspection/tampering problem. So I fixed many bugs in the extension and implemented some new features that I needed. The code is in my protobuf-decoder fork. I will not open a pull request because my code was developed quickly for a specific need, and some of the changes I made were tested only during a couple of engagements and may not work in every situation (and probably the extension has no maintainer at the moment anyway). My advice is to use my version if possible, because the one currently in the store has too many bugs to be reliable.

Hi,

I recently had the chance to assess the security of many applications with a back-end written in the Kotlin language. Unfortunately, at the moment Semgrep‘s support for the Kotlin is still in “Beta” and there are not many public rules for this language. So, I decided to write a bunch of them on my own, mainly to look for potential SQL Injections. These rules were written with limited time, they are non-exhaustive, and can definitely be optimized. However, they are field-tested and have proven to do their job quite well.

Disclaimer: as many other security researchers approaching IoT, I have a background in computer science and I started to work on these subjects with little knowledge about electronics and often with a “YOLO” approach (blame it on an old colleague of mine ). So, it is definitely possible that many of the things you will read here can be inaccurate or can be done in a much better way, especially with more knowledge in the field. Sorry about that. I take advantage of this disclaimer to add a thing: pay particular attention when you put your hands on electronics, especially when you deal with cheap Chinese devices powered by 220V! Some capacitors can cause serious damages even if the device is not plugged into the electric socket!

In the previous articles (A journey into IoT – Unknown Chinese alarm – Part 1 – Discover components and ports and A journey into IoT – Unknown Chinese alarm – Part 2 – Firmware dump and analysis) we analyzed many aspects of our unknown device. It’s time to have a look at the communications with the sensors (motion sensor and door sensor) and the remote controls.

At the moment we don’t have any information on how they communicate with the smart hub, nor on the frequency they may use. During the first step of our analysis we identified a chip that may be responsible for the communications with the sensors, but we could not find the datasheet. So, we need to understand how it works by reverse engineering radio signals. Users with a little experience in radio hacking will notice that our use case is quite simple and common. By the way, in order to follow the tutorial style of this series of articles and to show the entire reverse engineering process, we will approach it step-by-step as a totally unknown signal, like we do for more complex use cases. A good introductory paper on this topic is the thesis of my colleague Maurizio, from which I took a lot of useful information for this article and that can be downloaded from his GitHub repository.

Hi!

According to the official documentation, Semgrep is a lightweight, open-source, static analysis tool for finding bugs and enforcing code standards. It supports many different languages and can find bug variants with patterns that look like source code. Together with the tool, a collection of pre-written rules is provided.

Semgrep is a simple yet powerful tool. It can be considered as the grep Unix tool on steroids, because it understands the syntax of the analyzed language (but it offers many more functionalities and it evolves continuously). Support for many languages is mature, but for others like PHP it is still experimental. Many rules are created by the community and the resulting rulesets are more complete for some languages than for others.

At the time of this writing, public rules available for the PHP language are only a few, and some of them make use of taint tracking. Speaking for example of SQL Injection, there are only tainted rules that during an assessment I was involved in could not find much.