My colleague brought my attention to a really interesting ‘feature’ of browsers. Namely that XHTML namespaces in an XML document will be rendered as XHTML instead of XML. That means that if you can some way control an XML that will be rendered by the target’s browser, then you can insert HTML and of course JavaScript code. So this feature widens an XML injection to an endless attack vector.
Continue reading
In the ocean of web application development frameworks there are a quite a few which tries to create rich web application in the same way as traditional desktop-based applications. One of them is the open-source Echo Web Framework from NextApp. It is a Java based system which is kind of practical because everybody has at least one Java developer friend. The Echo applications can be deployed in most of the Java web containers. But the most important difference is that instead of creating for instance a .jsp file to create a view the developer write only things like window.add(button);. That means that for the developer should not care about the fact that his application will be accessed with a web browser. In some way it is really cool that you can just say the words and everything happens automagically but for me it is always a bit weird when I don’t have control over something, but that’s just my taste. And the magic in this case is done by JavaScript. Before going into details I must say that I don’t have full understanding of the Echo Framework and how one should use it properly, I understood it only to be able to do a pentest and to attack it properly. In this post I write about the Echo2 framework and my experiences from the penetration tester’s point of view.
Continue reading
First of all I must say that there are web applications which get output escaping right. I had a confrontation recently with one. I could store malicious attack strings in the database that were shown on the UI, still I couldn’t evade the output escaping even though I tried really hard. At the end I had to accept that the JavaScript generated UI was too good.
Continue reading
You could have read about a new interesting attack vector. It got the cool name of the Denail-of-Money attack. The first published case (which was actually an accident) was happened with an Associate Professor at Leonard N. Stern School of Business of New York University called Panos Ipeirotis.
His story in nutshell is that he made himself a more then $1700 Amazon AWS bill in a couple of hours. The root cause of the problem was that he shared 250 GB images in an S3 bucket. He used the thumbnails of these images in a Google spreadsheet. As it turned out Google in this case doesn’t cache content because it is considered private. Instead of caching Google simply downloaded all the 250GB every hour which costed a huge amount of money(although at the end Amazon refunded it).
Continue reading
During my first pentest reports it happened a few times that I suddenly realised that I hadn’t saved some data which would have been good to include in the report. Usually this costs you only time to reproduce the problem and gather that data again, but sometimes it’s not possible. Either you are not allowed to access the target system anymore or in case of a test environment it might not be even running anymore. In this case you need to accept that your report will be worse as it could have been. To avoid these situations I tried to summarize for myself what is needed to a report and how all relevant data should be stored for a finding. Bear in mind that usually every penetration tester has their own way to keep their data so this here is just my way(or the highway..).
It happens time to time that I need to do penetration test on a production system because the costumer doesn’t have any test environment. That is always a bad start. The explanation is usually that the target system is not a separate application or appliance but it is tightly integrated in the company’s infrastructure. Nevertheless it is very unfortunate from the penetration tester’s point of view. This brings the following limitations in the pentest:
For example in a production system it is difficult to decide whether clicking on a submit button will immediately order something for €1000, send out 10000 e-mails or first pop up a confirmation window which might be vulnerable to Cross Site Scripting.
Continue reading
© 2024 Æther Security Lab
Theme by Anders Noren — Up ↑