Programming

How to Stop a Brute Force xmlrpc.php Attack on Bitnami WordPress

WordPress Inspiration (oxymoron).

I was trying to access my site the other day and noticed it took fucking forever for anything to load. I thought something was broken: server out of memory from a recurring CRON job, or maybe I had royally fucked over my WordPress ecosystem by accident. Who knows? It's WordPress after all...

Are you experiencing any of these symptoms? Then read on...

  • Perpetually waiting for a response from while your browser displays a white page?
  • When your website does manage to load, clicking any links could make the entire application stop responding..
  • Seeing an abnormally high AWS charge for a small instance? Blame Amazon for expensive cloud computing first...

Being the curious programmer here, I tried to look for the issue. PRO TIP: Always look at your Apache or NGINX logs. My god. Fuck this guy. Spamming my site with pointless brute-force password attempts on a file called xmlrpc.php. Eventually, you'll never succeed because the password is a million fucking digits long. Realistically, however, I'll probably be so pissed off at the AWS charge, that I would cancel the EC2 instance before giving into my blog's new commander.

Check out some of these logs from streaming the Apache logs:

$ tail -1000f /opt/bitnami/apache2/logs/access_log

185.188.204.7 - - [21/Nov/2017:08:07:19 +0000] "POST /xmlrpc.php HTTP/1.0" 200 370
185.188.204.7 - - [21/Nov/2017:08:07:18 +0000] "POST /xmlrpc.php HTTP/1.0" 200 370
185.188.204.7 - - [21/Nov/2017:08:07:17 +0000] "POST /xmlrpc.php HTTP/1.0" 200 370
185.188.204.7 - - [21/Nov/2017:08:07:20 +0000] "POST /xmlrpc.php HTTP/1.0" 200 370
185.188.204.7 - - [21/Nov/2017:08:07:18 +0000] "POST /xmlrpc.php HTTP/1.0" 200 370
185.188.204.7 - - [21/Nov/2017:08:07:19 +0000] "POST /xmlrpc.php HTTP/1.0" 200 370
185.188.204.7 - - [21/Nov/2017:08:07:21 +0000] "POST /xmlrpc.php HTTP/1.0" 200 370
185.188.204.7 - - [21/Nov/2017:08:07:19 +0000] "POST /xmlrpc.php HTTP/1.0" 200 370
185.188.204.7 - - [21/Nov/2017:08:07:20 +0000] "POST /xmlrpc.php HTTP/1.0" 200 370
185.188.204.7 - - [21/Nov/2017:08:07:22 +0000] "POST /xmlrpc.php HTTP/1.0" 200 370

Great, my server is being spammed by a Russian bot every few milliseconds. WordPress, why the hell are these requests succeeding from an external source? At least this explains why my site has been unresponsive - someone else is using its resources.

Let's block his ass. The best way to do this is on the intermediary Apache server. We're going to write an Apache policy to prevent access to the xmlrpc.php file.

One thing to note before we continue here is that Bitnami automatically disables .htaccess files by default for performance reasons. So to write any Apache configurations at all, we'll have to edit the customized .conf file under:

$ vi /opt/bitnami/apps/wordpress/conf/htaccess.conf

// Now add these lines at the end of the file, please learn VIM to complete the edit

<FilesMatch "xmlrpc.php">
  Order Deny,Allow
  Deny from all
  Allow from 192.0.64.0/18
  Satisfy All
  ErrorDocument 403 http://127.0.0.1/
</FilesMatch>

Once we have edited the htaccess.conf file, we are going to restart the Apache server for the changes to take place:

$ sudo /opt/bitnami/ctlscript.sh restart apache

We can verify this works by trying to access the file via GET or POST on the file, http://dasun.us/xmlrpc.php, it should redirect. The policy above effectively redirects all external users to their localhost, while allowing traffic internally from WordPress. This allows certain plugins, such as JetPack, to correctly function. Let's look at the access logs now:

185.188.204.7 - - [21/Nov/2017:08:41:24 +0000] "POST /xmlrpc.php HTTP/1.0" 302 201
185.188.204.7 - - [21/Nov/2017:08:41:24 +0000] "POST /xmlrpc.php HTTP/1.0" 302 201
185.188.204.7 - - [21/Nov/2017:08:41:25 +0000] "POST /xmlrpc.php HTTP/1.0" 302 201
185.188.204.7 - - [21/Nov/2017:08:41:29 +0000] "POST /xmlrpc.php HTTP/1.0" 302 201
185.188.204.7 - - [21/Nov/2017:08:41:31 +0000] "POST /xmlrpc.php HTTP/1.0" 302 201
185.188.204.7 - - [21/Nov/2017:08:41:31 +0000] "POST /xmlrpc.php HTTP/1.0" 302 201
185.188.204.7 - - [21/Nov/2017:08:41:31 +0000] "POST /xmlrpc.php HTTP/1.0" 302 201

Ahhh success, and a breath of go annoy someone else now. The 302 is a redirection status which means they are now trying to access their own localhost rather than wasting resources on your WordPress website. Cheers, hope this helps!

Standard
Programming, Thoughts

Let's add a backdoor to one of the world's most secure devices

Apple's Letter

We are, yet again, at another pivotal piece of Internet legislature. Recently, a federal judge in Riverside, California ordered Apple to assist the government in unlocking and decrypting the iPhone 5C, used by Syed Rizwan Farook, responsible for the San Bernardino shootings in December.

These shootings were one of the worst acts of domestic terrorism in 2015. My thoughts go out to all of those affected. These attacks are despicable and those responsible for the attacks must be help accountable for their actions. Apple has already complied with all valid subpoenas and search warrants, even going as far to make Apple engineers available for advising the FBI.

The FBI fucked up. They compromised their entry to the sized iPhone 5C by changing the Apple ID and password associated with the phone by someone in the county health department, per the FBI's request.

Given that the iCloud auto-backup solution failed and all other feasible recovery solutions are now inviable, the FBI and the Department of Justice asked a judge to order Apple to re-write the firmware just for their unlocking purposes. This proposed new firmware would allow the FBI to remove the automatic wipe feature, allowing them to brute force the password.

I've been reading a lot of misinformed comments on the Internet and thought I'd give my computer science perspective of the situation:

1. Many Internet souls are arguing that Apple is operating based purely off its business model, and that they are using it's security features to maintain its company and brand marketability.

Let me make it very clear that Apple is NOT operating under its best marketing and business interests (surprisingly). This is about Apple's customers and their basic freedoms. Creating a backdoor is not only unlawful, but it puts the vast majority of law abiding citizens and their personal information at risk.

2. Many uninformed Internet warriors are wondering why Apple just doesn't comply with the FBI, given that it's only one user's iPhone and that that user is one of the San Bernardino shooters.

The issue isn't as black and white as it seems. The situation is not a hardware hack, rather it is a software hack. It is easy to think that the backdoor would only be applied to the single iPhone. However, this backdoor vulnerability could be applied to every iOS device in existence. That's over 1 billion devices.

I hope Apple takes this case all the way up to the Supreme Court. This backdoor, if created, could be abused by Apple's internal employees, hackers, even foreign governments if it ended up in the wrong hands. History has shown us that as soon as something is leaked, it becomes available on The Pirate Bay an hour later.

We cannot sacrifice our basic freedoms in the name of terrorism. As soon as we encourage this type of misbehavior, it gives our government unlimited access to all of our private devices. This is how oppressive regimes operate. Let democracy stand.

Standard