The other day, I set up Burp Infiltrator. During its setup, I ran into an issue or two, hence this blog post. So you don’t have to run into the same ones. But before we dive in, let’s have a look at what Burp Infiltrator actually is.
The Burp Infiltrator is part of Burp Suite. It allows instruction of the applications, so that that during a pentest, you can detect if the input landed in potentially unsafe API calls. Massively simplified - that’s it. And it’s awesome!
None of what is written in this post is mind-boggling, but since the community using the Infiltrator seems way smaller than the one using the rest of Burp, I decided to put it up anyway.
Spring Boot is a Java framework that I get to see a lot lately. Applications with Spring Boot can be configured to be completely stand-alone. Those apps have a bash script prepended to the actual jar, inside the jar file. So the actual app file is a bash script and a jar file. And there are some more specialties attached to it. More about the deployment can be found in the official documentation.
$ head springboot-app.jar #!/bin/bash # # . ____ _ __ _ _ # /\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \ # ( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \ # \\/ ___)| |_)| | | | | || (_| | ) ) ) ) # ' |____| .__|_| |_|_| |_\__, | / / / / # =========|_|==============|___/=/_/_/_/ # :: Spring Boot Startup Script :: #
If you just apply the Infiltrator on the jar, it will kill the script part. So save first, instruct afterwards.
Some background info on this:
- It seems like
exit 0is a good string to search for right now. Might have to be adapted, if Spring Boot changes the start script
- Of course the Burp Infiltrator must be adapted to your own needs
- A current limitation of Burp Infiltrator: One can’t directly infiltrate a jar, It must be located inside a folder
- If you try to jar the file with compression, it will complain about double compressed jars at startup
- If you try to jar the file without compression, it will complain about missing
- It works fine with no compression and zip
- My umask by default doesn’t include execution rights, thus the
The official Infiltrator documentation states:
If the bytecode is already located on the target application server, ensure that the application is not currently running, as this may prevent the bytecode on disk from being modified.
Most applications I pentest run inside docker. Also most of the time, the application is part of the docker image itself and not on a mounted volume. Since the docker is launched directly from the build pipeline. I have two options, to either instruct the jar during build time as e.g. gradle task, or directly on the host of the running containerized app. For my case, it currently simpler to do the latter. But this could change with more usage of Burp Enterprise. What seems to work quite well is the following:
docker container ps # find your relevant process docker container cp container-name:/path/to/app.jar dst/on/localhost # infiltrate the jar docker container stop container-name docker container cp infiltrated-app.jar container-name:/path/to/app.jar docker container restart container-name
Note: Older versions of docker will need:
docker ps docker cp docker start docker restart
While this is all of course not particularly new or generic, I hope it helps for those that are trying to combine Burp Infiltrator with dockerized apps and/or Spring Boot apps. Please let me know if you found better ways to deal with either of those.
Angular2 is one of those frameworks you’ll come across if you review recently developed applications. Various potential security issues found in the first version of Angular are being addressed by the new framework. So if you don’t completely abuse it, the baseline is decent. There are a few minor issues that can be quite easily spotted when reviewing an application, and I decided to note them here.
Who doesn’t like XSS delivered for free by the underlying framework? How to spot this with a code review and also how to avoid the Java Server Faces ViewState blocking your testing is part of the article. While this is probably not new and definitely isn’t complete, I decided nonetheless to put some of this information together in one place anyway.
«Hacking Open Source Software for Fun and Non-Profit» is the title of blog post by fellow security researcher @addelindh. Testing Open Source Software (OSS) is something that has been on my to-do list for a while, because I am convinced that a certain amount of time should be dedicated to it. The reason for this is simple: I firmly believe in giving back to a community that I rely on on a daily basis. This blog post is about an ongoing audit of the Ampache media streaming server, the vulnerabilities found and lessons learned.
Attacks on SSO protocols are an active field of research and finding good sources can be a bit of a nuisance. I recently invested time into research, resulting in the following collection of links, papers and tools. The list has been curated and filtered to only show links I consider to be noteworthy or particularly helpful. It is not and not intended to be comprehensive.
The following posts I wrote during my time at scip AG.