BSidesDC 2014

-
Presenting at BSidesDC was an amazing experience. I feel so lucky that we have our very own local con, and I am extremely grateful to the organizing committee and other volunteers who make this event happen.

This is very similar to my DerbyCon talk, however it is 20 minutes longer which gave me time to walk through how to go from finding this vulnerability to exploiting it, including showing the audience how to create a POC SWF.  Also, I released SWF-Server, which will give you everything you need to create your own SWF to exploit this vulnerability.






Comments

Post a Comment

Popular posts from this blog

Exploiting Python Code Injection in Web Applications

-
Image
A web application vulnerable to Python code injection allows you to send Python code though the application to the Python interpreter on the target server. If you can execute python, you can likely call operating system commands. If you can run operating system commands, you can read/write files that you have access to, and potentially even launch a remote interactive shell (e.g., nc, Metasploit, Empire). The thing is, when I needed to exploit this on an external penetration test recently, I had a hard time finding information online about how to move from proof of concept (POC) to useful web application exploitation. Together with my colleague Charlie Worrell ( @decidedlygray ),  we were able to turn the Burp POC (sleep for 20 seconds) into a non interactive shell, which is what this post covers. Python code injection is a subset of server-side code injection, as this vulnerability can occur in many other languages (e.g., Perl and Ruby). In fact, for those of you who are CWE f...
Read more

Exploiting Server Side Request Forgery on a Node/Express Application (hosted on Amazon EC2)

-
Image
I recently came across a Server Side Request Forgery (SSRF) vulnerability within an application that I assessed.  The application was hosted on Amazon EC2 and was using Node.js, Express.js, and as I found out later, Needle.js. Discovery   Manual Discovery In the discovery phase, I noticed a function of the application that was taking a user specified URL and displaying the first paragraph from that URL into the page.  This application allowed a user to share a URL with their friends, and grabbing the first paragraph was a feature that would provide the friends with more context. The thing is, when looking at my Burp history, I could not find the request to the URL that I specified in my logs.  This should raise an eyebrow!   This means that the server is taking the URL I specified, making a request on my behalf, and then returning the result to me. That right there is SSRF .  Then, the only question was: What is the risk? Automated Discover...
Read more

Cloud penetration testing: Not your typical internal penetration test

-
Image
There seems to be a common path for experienced penetration testers who are thrown into the world of cloud penetration testing. I'm talking about internal (aka assumed breach) tests, where the goal is to demonstrate the impact of a compromised user with access to the cloud or a compromised application in the cloud.  The path usually starts with ignorance, is followed by total confusion and questioning everything you know about penetration testing, and ends with… well, it never ends. Why? Because the cloud providers and the cloud native technologies running in these clouds keep evolving at a remarkable rate. There's always more to learn and more attack paths waiting to be found. I hope walking through my own path and defining the stages of ignorance and awareness I encountered in a playful way might help others progress through the early stages more quickly than I did.  Level 1: This is just like any other Internal Penetration Test, right? You connect to your assumed breach sta...
Read more