Renewal paper of my GIAC Web Application Penetration Tester certification:
Sniffing plaintext network traffic between apps and their backend APIs is an important step for pentesters to learn about how they interact. In this blog post, we’ll introduce a method to simplify getting our hands on plaintext messages sent between apps ran on our attacker-controlled devices and the API, and in case of HTTPS, shoveling these requests and responses into Burp for further analysis by combining existing tools and introducing a new plugin we developed. So our approach is less of a novel attack and more of an improvement on current techniques.
Of course, nowadays, most of these channels are secured using TLS, which provides encryption, integrity protection and authenticates one or both ends of the figurative tube. In many cases, the best method to overcome this limitation is man-in-the-middle (MITM), where a special program intercepts packets and acts as a server to the client and vice versa.
For well-written applications, this doesn’t work out-of-the-box, and it all depends on the circumstances, how many steps must be taken to weaken the security of the testing environment for this attack to work. It started with adding MITM CA certificates to OS stores, recent operating systems require more and more obscure confirmations and certificate pinning is gaining momentum. Latter can get to a point, where there’s a big cliff: either you can defeat it with automated tools like Objection or it becomes a daunting task, where you know that it’s doable but it’s frustratingly difficult to actually do it.
While we at Silent Signal are strong believers in human creativity when it comes to finding new, or unusual vulnerabilities, we’re also constantly looking for ways to transform our experience into automated tools that can reliably and efficiently detect already known bug classes. The discovery of CVE-2019-6976 – an uninitialized memory disclosure bug in a widely used imaging library – was a particularly interesting finding to me, as it represented a lesser known class of issues in the intersection of web application and memory safety bugs, so it seemed to be a nice topic for my next GWAPT Gold Paper.
The paper introduces several problems I’ve been facing while testing web applications, which converged in a common direction. Burp Suite is known by most and used by many professionals in this field, and while it’s extensible, writing such bits of software have a higher barrier of entry than the budgets of some project would allow for a one-off throwaway tool. Our solution, Piper is introduced through real-world examples to demonstrate its usage and the fact that it’s worth using it. I tried showing alternatives to each subset of the functionality to stimulate critical thinking in the minds of fellow penetration testers, since this tool is not a silver bullet either. By describing the landscape in a thorough manner, I hope everyone can learn to pick the best tool for the job, which might or might not be Piper.
The full Gold Paper can be downloaded from the website of SANS Institute:
The accompanying code is available on GitHub. For those who prefer video content, only have 2 minutes, or find the whole idea too abstract, we made a short demonstration of the basic features below. If you’re interested in deeper internals, there’s also a longer, 45-minutes talk about it.
With the advent of PSD2 APIs, we had the opportunity to test some of them upon request from our clients. Although internet-facing APIs were already a thing thanks to smartphone apps, it seems that regulatory requirements and 3-way setups (customer, bank, provider) led to some surprises. Here are some of the things we found.
Many tools are timeless: a quality screwdriver will work in ten years just as fine as yesterday. Reverse engineering tools, on the other hand need constant maintenance as the technology we try to inspect with them is a moving target. We’ll show you how just a simple exercise in Android reverse engineering resulted in three patches in an already up-to-date tool.
Some VPNs allow split tunneling, however, Cisco AnyConnect and many other solutions offer a way for network administrators to forbid this. When that happens, connecting to the VPN seals off the client from the rest of the LAN. As it turns out, breaking this seal is not that hard, which can be useful for special cases like performing pentests over a VPN designed for average users.
I had the pleasure to present my research about the IPC mechanisms of Kaspersky products at the IV. EuskalHack conference this weekend. My main motivation for this research was to further explore the attack surface hidden behind the self-defense mechanisms of endpoint security software, and I ended up with a local privilege escalation exploit that could be combined with an older self-defense bypass to make it work on default installations. I hope that the published information helps other curious people to dig even deeper and find more interesting pieces of code.
The presentation and some code examples are available on GitHub.
My local privilege-escalation exploit demo can be watched here:
The exploit code will be released at a later time on GitHub, so you can have some fun reconstructing it based on the slides ;)
There are many obfuscators for different languages, and some of those offer reversible options for easier field debugging. Eazfuscator.NET is one of these and with a bit of reverse engineering, whole files can be restored with the original symbols once you have the password.
During a recent engagement we encountered a quite common web application feature: profile image uploads. One of the tools we used for the tests was the UploadScanner Burp Suite extension, that reported no vulnerabilities. However, we noticed that the profile picture of our test user showed seemingly random pixels. This reminded us to the Yahoobleed bugs published by Chris Evans so we decided to investigate further.