SethSec

TL;DR: Using login CSRF + multi-stage CSRF, you can create a one click exploit that would silently log a user into their vulnerable, Comcast provided modem/router with default credentials (if they have not been changed) and then enable remote management (or anything else). I'll show how I did this with my previously vulnerable modem/router, and then give a more generic POC that you can try out on bWAPP, an intentionally vulnerable web application. Unnecessary Background This story starts about a year ago when my colleagues convinced me to stop being lazy and switch to a DOCSIS 3.0 modem so that I could actually get the speeds I am paying for.  I filled out the Comcast XFinity form and had them send me a new modem.  New toy -- Yay! So basically right after I had the new device working, I decided it was time to mess around.  Turns out the modem is an  Arris TG862G , a modem that is designed to be re-branded by many ISPs and distributed to their customers. Unfortunately, as is c

Before too much time passes, I want to write about a point I covered in my presentation that is not widely covered on the web -- or maybe not even covered at all. The main point is that even if you have a very specific list of domains that you trust, you may still be vulnerable to CWE-942 , if one of the domains that you trust is available for purchase. To illustrate this point in my talk, I used the crossdomain.xml file at www.sears.com: What I found in my research is that there are plenty of crossdomain.xml files that trust sites that are available for purchase.   As far as I know, every single security assessment tool out there would pass right over these sites, missing the fact that a vulnerable configuration could be in place. In the case of www.sears.com, they are trusting the domain: searstestsite.com. For the purpose of demonstrating the vulnerability, I purchased this domain. This means that I can now host a malicious SWF at www.searstestsite.com, a domain that I o

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. Download the project here: https://github.com/sethsec/crossdomain-exploitation-framework

Abstract: Security misconfiguration is #5 on the OWASP 2013 Top 10. This talk shows how the misconfiguration of one file can compromise the security of an entire web application. In the talk, youll be introduced to the crossdomain.xml file.  This file determines how third party Flash Objects (SWFs) hosted on other domains can interact with your domain. Unfortunately, this file requires manual configuration on the part of the administrator, and as we all know, when manual configuration is required, mistakes happen.Sometimes, administrators give up and whitelist the entire internet in order to "make it work". This is essentially like adding an "accept all" rule on your firewall or setting your password to <blank>.  We will review how to identify the vulnerability, how to abuse it, and how to write your own SWFs that exploit the flaw. Examples of public sites that until recently contained this vulnerability will be provided, including a few from the Alexa

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

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 sent, but