tag »

Even easier brute-force login protection for wordpress

Apr 262013

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.

When a request comes into the login page, check if there is a session setup for it.
If the session is valid, process the request.
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.

Kerberos ticket renewal on MacOS Mountain Lion

Apple, Network Security, Security

Jan 302013

The active directory integration in Mountain Lion is getting pretty good, certainly much better than the early 10.7 days. Several applications integrate quite well, offering kerberos single sign on, such as Safari, and the Microsoft Office apps. One thing I do not like about kerberos on MacOS is that when my TGT expired it would not auto-renew. That means Safari wouldn’t perform SSO, and some tools like Lync or Communicator would start prompting for passwords. The easiest way to deal with this is to open a terminal and type “kinit”. This would prompt for your password and will issue a new ticket.

As easy as it is, I don’t like it, so I went looking for a solution, and as luck would have it there is an easy solution. If you set this up, each time you authenticate to the screensaver, or unlock the keychain the OS will get a new ticket granting ticket, which is much better … one downside is that it will not renew the ticket if you are logged in and the ticket expires. But my screen lock timeout is short enough anyways, so it will reduce much of the pain.

Here’s how to do it … (it’s super simple!)

Open the “Keychain Access” application, and under the “Keychain Access” dropdown menu select “Ticket Viewer”.

Screen Shot 2013-01-30 at 12.59.09 PM

Once that opens, you should see some tickets … note the principle name (case matters, so it needs to match how your directory services are configured.) Click on Add, type your principle name, password, and uncheck the remember password box (that setting might cause you to lock your domain account when you change your password–depending on lockout policy.) Then click continue. It takes a few seconds to work, so be patient. Once it is added (all the other tickets will likely disappear) highlight the principle and click on the “Set as Default” button. Now when you unlock the screensaver (or the keychain) it will request a new TGT, so it’s less likely that you will have timeouts. I did find one bug … if the Ticket Viewer application is open and running when a new key is issued it will crash, and all your tickets will be deleted; so close the application before testing.

IPv6 on Comcast using OpenWRT

Miscellaneous

Jan 122013

I bought a new wireless router (TP-Link N750 TL-WDR4300) that had fantastic hardware specs. It was to replace what I had been using, an Airport extreme, that was having problems dealing with the number of DHCP leases on my network. I also didn’t like the lack of flexibility in firewalling, DHCP options, and on and on. Basically the Airport worked great, but sticks to Apple’s design philosophy: user’s don’t really know what they want, so we’ll tell them. One thing I really liked about the Airport, however, was that it worked great with IPv6.

The new TP-Link router didn’t support IPv6, crashed a lot, would randomly stop routing bridged traffic between the wired and wireless interfaces, and did a pretty good job of pissing me off. It’s OS was based on an older version of either OpenWRT or dd-wrt; and this was the source of my problems. Since it wasn’t really working I decided to go ahead and drop OpenWRT’s latest snapshot on the router, I figured what do I have to lose. (I am super happy with the results, what a great community project!)

I’m not going to cover how to install it, that’s well-enough documented at the OpenWRT site. I am going to give a couple of pointers to getting IPv6 working on Comcast’s network. It’s actually pretty easy once you install the right packages. There are different ways to get IPv6 working in OpenWRT, and this is the combination I got to work, I tried a lot of things. Other setups might work better or not at all, I don’t know–I stopped once it worked.

opkgs you will want: Wide DHCP Client, and the route advertisement daemon. (You don’t need wide-dhcp-server.)

opkg install wide-dhcpv6-client radvd

First a couple of gotchas that tripped me up.

Comcast only delegates a /64 prefix (standard ISP practice is a /60,) which means a few things that at first tricked me …
- You can’t subnet a /64, so at layer 3 you will talk to the upstream router using link local addresses.
- The br-lan interface will get the delegated address.
- The default config for wide dhcp6c assumes a /60 delegation, if you don’t change this you won’t get your lease.
By default the native IPv6 stack is configured to listen for route advertisements and send route solicitations. This conflicts with what dhcp6c is doing. I’m not sure, but it might be possible to use the native IPv6 settings in /etc/config/network but I’m not sure if it works as expected with the /64 delegation; I was seeing the wan interface get the address assignment and not the internal layer-3 interface we would use as the default gateway.
- If you are seeing strange behavior on your network this might be the cause … when I didn’t know better and had both native and dhcp6c enabled I would restart the network, or reboot the router and IPv6 would be working great. A few hours later it would stop working. I would also see that my clients had been assigned new network prefixes. But they had not disabled the old ones (marked as deprecated but still listening.) And I could’t route IPv6 anymore.

Here are some of my settings that got my OpenWRT routing IPv6 on Comcast (sorry, just config files I didn’t even install the web gui.)

Always “hover” before you click!? Wrong.

Wait, that was wrong.

Oct 282012

RETRACTION: So, sometimes I am wrong. This attack does work, but it’s irrelevant, and here’s why: if someone has control of the DOM the game is already over, there’s nothing the browser can do for you in that case. It doesn’t really matter that the hover-status can be spoofed at that point. I’ll leave the post up so you can marvel in my stupid, but to summarize–nothing to see here. (At least I’m not throwing banner ads at you.)

One of the things you hear frequently is to be aware of what you are clicking on when you surf. That you should “hover” over the link before clicking it to make sure it goes where you think it does. Hell, I’ve personally given this very advice to people who clicked on something stupid.

I guess I’m a liar. Because it isn’t true.

I actually put five minutes into thinking about this very advice today, because something didn’t sit right with me about that statement. It took all of a minute to throw some html and javascript together that gets past it. Maybe everyone already knows this, and somehow I was asleep on the day that it was being covered in the literally hundreds of papers, articles, howtos, books, and presentations I’ve attended, read, or skimmed. Your browser will show you what the link is when you hover over it. But that doesn’t mean that the link is the same by the time you have released your mouse click.

Honestly, I don’t know why this simple attack is allowed to work … browsers should not allow the href to be modified on a link with the onClick handler.

Want to see it in action? Here’s a link to the above code.

Comments are working, I am caching everything right now so if you comment it may take a while to show up.

Yet another neat $PS1 prompt for bash

Miscellaneous

Oct 262012

(With google returning more than a million hits for the search “bash PS1″, it may be a little presumptive that I have anything to add to the conversation, but this was an interesting exercise for me, so I’ll share it anyways. Besides this may actually be my most nitpicky *nix nerd post yet.)

Here’s my brand new . . . super-duper space-saving, non-forking, color-changing PS1 prompt (that doesn’t mess up readline!)

export PS1='[\[\e[$(((($?>0))*31))m\]\h:\W\[\e[00m\]]\$ '

I happened across a blog post (8 Useful and Interesting Bash Prompts) covering different PS1 prompts that people are using. I hadn’t thought of it before, but the first prompt “Show Happy face upon successful execution“ caught my attention because I write a lot of scripts, and of those many are used by other programs–so return codes are important, and not something I always remember to check. I hadn’t thought of it before, but I liked the idea!

Anyways, it got me thinking about how it works … a lot of the fancy PS1 formulas you see out there are running several commands (even if it isn’t obvious–generally if a bracket or tick is involved, there’s a subshell forking out.) When your system is grinding to a halt, every fork counts. So I don’t like the idea of running an additional shell script every time I press enter.

So, the example that Joshua Price provides, while really cool, adds extra forks every time you hit the return key. This is pretty easy to demonstrate using bash’s “set -x” command:

Each one of those “++” signs you see is a new process being created. I’m a bit of an efficiency freak, so I don’t like that.

Curiosity got the better of me, and I somehow decided that I would achieve the same end (return status indication within PS1) without a single forked process. So I went about modifying my (now previously) favorite PS1 prompt … the ultra-simple:

Older Entries