It had to happen, didn’t it? I’ve fired up Pidgin with the microblog-purple plugin, only to get an “invalid certificate” error for twitter. I’ve quickly became nervous, since a quick digging indicated that I was getting the wrong IP address for the domain twitter.com.

My first thought was: “I’ve been compromised”. After quickly verifying my hosts file and my DNS entry, all seemed fine on the surface. My second thought was: “my DNS server was compromised”, so I’ve done the same lookup using OpenDNS and the new Google DNS, both coming up with different (but wrong) answers. Finally I’ve checked out a couple of other HTTPS sites and they seemed fine. So I took a deep breath and (putting my faith in NoScript and RequestPolicy) visited twitter.com to find the following page:

Quick analysis:

• This seems to be a “good old” defacement
• A very likely scenario is that they somehow compromised the DNS registrar account (phising, dumb password reset, etc) and changed it to point to an other IP.
• Currently I’m seeing a couple of different IPs out there for the twitter.com domain:
  • My DNS server (and OpenDNS) returns 66.147.242.88
  • Google DNS returns 74.217.128.160
• The correct address seems to be 168.143.171.84, so if you put the following line in your host file, thing should start working again (you might need to do an ipconfig /flushdns if you’re on Windows):

  168.143.171.84 twitter.com

• The above is a hackish solution, and I would recommend using it only in life-and-death situations :-p. It is the best to let Twitter handle the incident and make sure that everything is cleaned up.
• It is unclear when exactly the defacement happened, but it must have been in the last 10 hours or so. It might have been specifically targeted so that it is late in the day in the USA so that the reaction is delayed.
• According to Google Translate (Babelfish doesn’t know Arabic unfortunately) the text below the picture says:

  Ok, so I’m a big ignorant idiot. The official language of Iran is Persian (also known as Farsi or Parsi), not Arabic. Thank you to Anonymous for pointing it out. According to this article the text in the picture says:

  This site has been hacked by the Iranian Cyber Army (on the flag)

  and

  The USA thinks they control and manage internet access, but they don’t. We control and manage the internet with our power, so do not try to incite the Iranian people (under the picture)

  Some people also seem to have screenshots with English texts on them.

• The rogue server doesn’t seem to respond to any Twitter API requests, so it doesn’t seem to be that they were going after usernames and passwords (which they very well might have done, considering the number of users who click trough SSL certificate warnings), but just to be on the safe side, change your password and don’t use the same password on all the sites!

Update: As of now all seems to be back to normal and all the DNS servers return the correct IP address. I’m waiting for an explanation in Twitter (mostly because I’m interested in how it happened :-)).

Update: Twitter acknowledges the hack on their blog and say that they will provide more information as it becomes available (however they erroneously affirm that the API were working correctly – they weren’t, since they used the same DNS record to contact Twitter – in fact this is how I’ve became aware of the hack).

Bonus: what sources can you use to investigate such incidents?

• First of all, be suspicious of SSL certificate errors! I know that they (sadly) are quite common these days, but be vigilant!
• Check that the problem is not at your end. Check that you have the correct DNS server (there are a couple of malware families out there which set a custom DNS server for the machine to control the users browsing destinations). Check that the given hostname is not present in your hosts file (again, there are a couple of malware families using this method to misdirect users)
• Check what the IP address should be, by using domaintools for example (and looking at the server stats page)
• Try looking up the DNS name using several DNS servers (this might not work if your network filters DNS queries):

  # nslookup
  > set type=ANY
  > twitter.com
  ...
  > server 8.8.8.8
  > twitter.com
  ...
  > server 208.67.222.222
  > twitter.com
  ...

• An other option is to use the vURL service to fetch the suspicious webpage from different location and compare the results with what you are seeing.

Using these methods you can quickly ascertain with pretty good accuracy where the fault lies and take appropriate action. Have a safe holiday everybody!

Update:

• Read about the subject on the TrendMicro Countermeasures Blog.
• Some more links to information and the source of the defaced webpage at Hacker News.
• SANS posted about in issue in the diary.
• I’ve update the translations, thanks to Anonymous
• Twitter posted an update about the issue. It doesn’t many more details, it does however give a timeframe for the problem: between 21:46 and 23:00 PST . There are some rumors out there that somehow (phising?) the correct password to the DNS management interface was obtained and it was used to modify the records. Twitter still has the original blogpost up saying that API’s were not affected, but this is not true! If you’ve used a third party Twitter client and you’ve clicked trough the certificate warning (or maybe it doesn’t use TLS at all), your password might have been compromised. Currently there is no evidence that the rogue server was logging passwords, but until the time some forensics is done on it, there is no sure way to tell if this was the case (since it is trivial to configure a webserver such that it responds with a 404 error, while still logging the details of the request).
• Arbor Networks posted a related article.
• Sucuri has also posted about the issue. They have a nice little network monitoring / alerting system. You can also use them as a third-party information source.
• ISS X-Force (part of IBM) has also a nice writeup about the incident.
• Brian Krebs has an informative writeup on the SecurityFix blog about the issue which quotes Dyn’s (the host for the Twitter DNS) CTO as saying: “Someone logged in who purported to be a legitimate user of their [DNS] platform account and started making changes”, further strengthening the probability that a Twitter employee’s email account was broken into via some mechanism.
• There is also a lot of confusion out there, as it always is the case with (security) news. I’ve heard someone saying that “why did the DNS host allow the redirection of Twitter to a host in Iran?” – just to clarify: even though the hack was claimed by the “Iranian Cyber Army” (which might not mean anything! it could be your nerdy neighbor), the server it was redirected to was in the US.

Picture taken from pugetsoundphotowalks’ photostream with permission.

Picture taken from Joachim’s photostream with permission.

1. Write your (Perl) script and make it output something like this:

   
   <testsuite tests="0" name="summary" failures="0"><system-out>
   foo bar
   </system-out></testsuite>

2. Make your script run during the build. This can be done directly using exec or in an ant subtask using the exec task. One thing to keep in mind is that CC stops at the first failure – this can be important if you want to run your script even during failures (because it collects statistics about the failures for example)
3. Check that the output is present in the XML resulting from the XML log.
4. Hack the XSL such that the contents are displayed in the result HTML email for example:

   
   <table align="center" cellpadding="2" cellspacing="0" border="0" class="header" width="98%"><tr><td>
     <pre><xsl:value-of select="/cruisecontrol/testsuite[@name='summary']/system-out" /></pre>
   </td></tr></table>
   

That’s it folks! Hope that somebody finds it useful.

Picture taken chippenziedeutch’s photostream with permission.

The method: use Yahoo! Pipes to fetch the HTML page for each entry. The setup can be seen below:

The feed used in the example is the old feed from the Truested Source blog (since they’ve been bought by McAfee, they publish a new feed with the complete posts ;-)). The first operator (the Loop) fetches each page specified in the link for the element. Two remarks:

• site owners can prohibit Yahoo Pipes from fetching pages using robots.txt
• pages are not fetched at each evaluation of the pipe, rather at each change of the source feed (for those who are worried about a pipe DDoS-ing the site)

Set the “Cut content from” and “to” so that what you obtain the HTML part you want. “Split using delimiter” must be set to something, preferably something which doesn’t occur in the text. I just used some random MD5.

The second loop tries to protect against XSS-ing yourself :-). I discovered this by accident, because the feed contained the following post: A Little Filtering Can Halt Some XSS Attacks. The problem is that the inserted HTML content gets double decoded, resulting in execution of the script, even if it was encoded properly for the HTML page. The method used in the above example is rather lame, hower there is a good news: Google Reader disallows Javascript so you are not at risk, even without this transformation.

Enjoy your full feeds.

Update: Originally I came up with the idea while reading the article Build a Web Page Monitor with Google Docs and Track Changes Automatically, however the Yahoo Pipes solution is much cleaner, task oriented solution (but the Google Docs one is still worth checking out for other possible usecases).

Update: two alternative solutions (which are easier to use than creating a custom pipe for every feed) – via taint.org:

• fivefilters.org
• echodittolabs.org

• the main page
• a link to each individual entry – this was needed because the navigation system was based on javascript :-(, and HTTrack – although amazingly it was able to find all the links, it wasn’t able to modify the JS such that the navigation works.
• If you want to download all the pages at one, grab them here (the extension is .JAR, but in fact it is just a ZIP file – as all JAR files are ZIP files)

The idea of the post was to take your unused PS/2 ports and use them as a power source to charge your mobile phone, which would otherwise support charging through USB. The idea is cool, however there is a possibility for you to fry your motherboard (or part thereof).

From the source of all wisdom Wikipedia: USB can supply 500mA or 100mA of power, however PS/2 can supply only 100mA. If your try to power a device which needs more power, there is the possibility that you will fry your motherboard! Also, 100mA is the upper limit for PS/2 and I really don’t like pushing equipment to its limits, but maybe that’s just me.

Now I would like to subscribe via RSS to the posts (since this is my preferred way of consumption), but faced the following problem: unless I accessed the feed from Firefox, I only got the posts which were in the public area (not very interesting). This was true both for desktop based and web based readers, and I suspected the cause was that these clients were not logged in when they were fetching the feed.

So I did a little hack: I got the value for my PHP session ID (also, my session is set never to expire, which is not very secure, but convenient). You can do this by viewing the cookies associated with the given site and getting the value from the PHPSESSID cookie (it should look like something like: “d41d8cd98f00b204e9800998ecf8427e” – without the quotes).

Now take the RSS feed URL and append the session id to it like this:

http://example.com/index.php?type=rss;action=.xml;PHPSESSID=d41d8cd98f00b204e9800998ecf8427e

This will fetch the feed with your credentials. Some caveats: if you are using an online reader (like Bloglines), this means effectively trusting them with your session. Also, this may or may not work depending on PHP settings and the given SMF version (I didn’t look at the source code for the forum to confirm that it would always work). If your session expires, this method will stop working.

Warning! Don’t attempt this at home unless you have at least some experience with electricity! Also, applying this hack directly on consumer electronics will most probably void the warranty!

The problem: having a 2.1 (yes, I know, lame, real people use at least 5.1 :-)) speaker system with an incredibly bright blue LED on the front and the turn-off switch on the back of the sub-woofer! The solution: installing a secondary switch to cut-off the power. What we need:

• Tools
• A switch rated for 220V (or 110V if you live on that part of the ocean) which is cable mountable. Usually these switches are rated for low amperage (ie what is the maximum power that they can cut-off safely), like small lamps, but the speaker system is also of quite low power consumption.
• A piece of electrical wire. Again, use cable rated for the right amount of Watts. In the pictures you will see a cable composed out of 3 wires. Technically it would have been sufficient to use a 2-wire cable, however this was what I had handy.
• An electrical plug
• Isolating tape

The plan:

The plan is to mount the switch on one of the wires, thus making it possible to turn on-off the speaker from a distance (a small distance, but at least you don’t have to crawl on you knees to find the switch). In the version shown below the points A and B will be very close together (in fact they will both be in the plug). As I mentioned before, I had a three-wire cable handy, so there was one wire left unused, marked in the plan with a dash-dotted line.

Step 1. Cut off the original plug and clean the wires on a short distance (~5mm). I apologize for the poor quality of the pictures, but I had no "real" camera at hand.

Step 2. Take a piece of cable long enough for this purpose. Mount on one end the switch. To make it more "aesthetically pleasing" (and practical) you could mount the cable on one end. In this case I left the green-yellow wire unused (which is commonly used for grounding, so that it’s easier to remember). A tip: at first cut off the outer isolation on a shorter part of the cable, mount the cable in the switch and finally cut off enough of the outer insulation that the switch can be mounted together again.

Step 3. Mount the other end of the cable together with the wire from the speaker in the plug. You should mount it the following way: one of the wires from the speaker goes directly to the current. The other one is fixed together with one of the wires from the cable (remember, I didn’t use the green-yellow one, so that doesn’t count). Finally the other wire from the cable is connected to the other contact. The contact between the the two intermediate wires should be thoroughly isolated.

Finally mount the plug together and use insulating tape to fix the remaining wires. You can now turn on-off the speaker (or anything else) from your chair without needing to crawl under you desk. You also being green, because the speakers (and other electrical equipments) draw power while idle and even while in standby!