SethSec

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...

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...

This CVE covers a vulnerability found in the Ubiquiti Networks AirVision application.  For more background on this particular vulnerability, check out this post: Exploiting misconfigured crossdomain.xml files In fact, I wrote that first crossdomain.xml blog post after finding this AirVision vulnerability back in February.  If you already read that post, you should recognize the vulnerable form I use for the POC here (adding an administrator), is the same one I used earlier. Here is a cleaned up version of what I sent to Ubiquiti back in February: AirVision Controller v2.1.3 - Overly Permissive default crossdomain.xml CWE-264: http://cwe.mitre.org/data/definitions/264.html Misuse Case If the victim user is authenticated with their AirVision Controller, and they visit a malicious site, the owner of the malicious site can make changes to, and read data from, the AirVision Controller. The malicious site can even add a new administrative user accou...

Ubiquiti - UniFi Controller - Admin/root password hash sent via syslog CWE-310: http://cwe.mitre.org/data/definitions/310.html Misuse case: An attacker who has access to network traffic between the UniFi controller and the configured syslog server, can retrieve the password hash and use it to access all managed access points, and potentially the UniFi controller as well.   Details:   If remote logging is enabled on the UniFi controller, the controller sends syslog messages to the configured syslog server. Contained within the syslog messages is the admin password hash that is used by both the UniFi controller, and all managed Access Points. In the screenshot below, the auth key and the encrypted password are highlighted in yellow. The password is encrypted using the legacy crypt(1) utility, which uses Traditional DES [128/128 BS SSE2], and can be recovered using John the Ripper: Note: The salt (and hash) changes each time the message is s...