TweetDeck Hack: How a 19 year-old playing with hearts broke the Internet

1 How to get thousands of re-tweets in an instance

On 11 July 2014, at 5:59pm, Twitter announced:

We've temporarily taken TweetDeck services down to assess today's earlier security issue. 
We'll update when services are back up.

This message reported on the spamming of tweets from TweetDeck which had started several hours earlier. The hack was caused by a simple injection of some JavaScript with an automated click on the link. So the script basically went into the TweetDeck interface, which many users leave running in order to watch tweets arrive in real-time, and then cause the link to be clicked on, on a continual basis. It affected the @derGeruhn account with over 84,390 retweets in a short period of time (including on the BBC site):xssThe following shows one of the retweets:

_75461777_ccacd605-6c16-45d3-9758-58803f19ee03The script itself was run within TweetDeck, where the  at the end allowed JavaScript to be injected into Tweetdeck to cause a worm which retweet links. The script itself has three main actions. It first finds the top link, and then clicks on it, after this it marks it for a retweet, and then shows a message to the screen (XSS in Tweetdeck):

tweetThe following outlines how the hack works, and some of the issues related to it. To call it a “hack” is perhaps an overstatement, and it seems that the threat has been caused, like many of the orginal viruses and worms, but a mistake, where a script kiddie ran a bit of code within Tweetdeck, that eventually ended up doing more than just show a simple message to the screen.

It was start by a 19-year-old computer programmer named Firo in Austria who wanted to show a cute little heart. A worm then stread which came from a tweet of a “♥” symbol (&hearts) and associated code, which retweeted a link in Tweetdeck. The heart symbol caused the Tweetdeck’s software to inject inject JavaScript into the program, and was discovered by mistake. He then tried it a few times, and then tweet his triumph:

"Vulnerability discovered in TweetDeck. \ o /"

and informed Twitter, but it was too late, as others, including within Hacker Forums, had found it and started creating a mass TweetDeck hijacking ensued. We can see here that Firo was experimenting with hearts, and announced to the world what he had found:

firoOnce the vulnerability had been found, others moved forward and created the worm, but sending the code and automatically clicking on links to be retweeted (including the BBC who retweet to 10.1 million users):

<script class="xss">$('.xss').parents().eq(1).find('a').eq(1).click();
$('[data-action=retweet]').click();alert('XSS in Tweetdeck')</script>♥

Basically TweetDeck picked up the tweet, such as from the BBC, which sent it on to others, which then ran the script if they had TweetDeck open, and then retweet, and so it went on. In fact it was just like the old days with worms infecting systems, and generally hog them to the point that they became unuseable. In this case, Twitter stepped in, and switched of the retweeting of the messages.

2 Outline

Almost every day we see new threats with the security of applications. At one time our problem was with viruses and worms, where malicious code hide themselves on systems and aimed to trick the user into installing themselves on the host system, and then do damage. The world is changing though, were we are Manikin Loupemoving into the Cloud, and where code is run on Web servers, and where are data is stored within Cloud-based systems. In the past, software development teams would spend a great deal of time testing their programs for a range of activities, and often test them to destruction. The new code now runs on severs, and produces HTML and JavaScript, which has never been designed to be secure. Along with this the teams who are writing Web-based code often have little training in how to actually test their applications. With many native code programs, such as for Windows and Mac OS, we often see code which is extensively tested, but because of the horrible HTML and JavaScript code, there is often a lack to testing of the user interface and the associated middleware software.

It’s a well-known problem in testing, as testers who test their own programs often do not exercise them in a way that we make them break. This article outlines the key elements of designing computer software, and highlights the specific example of the Tweet Deck hack.

3 Examples

Before we look at the Tweet Desk Hack, let’s look at some simple examples. The following shows a practical session which involves XSS (Cross-site Scripting):

and here is a lab for Metasploitable.

3.1 Injection Attacks

botLet’s look at a few types of attacks. The first one is relatively easy, where the coder does not check the user input, and simply prints the entered text to the screen. For this a user enters:

<script>alert(‘Oops I have been compromised’);</script>

Which is then echoed to the page, and, of course, will run the scripts as a piece of Javascript, and display a message box with “Ooops I have been compromised“. See the demo for this.

3.2 Link modification

The hack for TweetDeck relates to link modification and automated event, where some JavaScript is injected Tweetdeck-Logoonto a link, and causes it to change the hypertext link, and then generate a click event. This breach injects a piece of script which will modify the operation of the objects which are created within the HTML. With JavaScript we can perform actions such as clicking on an object on the page. For example, the following runs a JavaScript, and then modifies the first hypertext link address for a new link:

<script>var link=document.getElementsByTagName("a"); link[0].href=""</script>

This modifies the first link to point to the BBC site, rather than the one defined in the code (see the demo for this).

3.3 Remote JavaScript injection

A common method of breaching a page, with unchecked user input is to inject malicious code from a remote site. For example:

<script src=""></script>

will inject some malicious code from a server at into the page, which can cause a whole range of problems, such as breaching the login requirements for a page (see the demo for this).

3.4 JavaScript Injection

One way that an intruder can hack the HTML code is to analyze the generated HTML code to see if some JavaScript can be injected into it. For example:

document.getElementById("idUsernameInput").innerHTML = "This password is for canary";
alert("Error: " + e.message);
}// end catch

An intruder can then injection by completing the JavaScript to give:

 document.getElementById("idUsernameInput").innerHTML = "This password is for ";
} catch (e) {} alert(0); try { a="
 alert("Error: " + e.message);
 }// end catch

The code to be injected is:

";} catch (e) {} alert(0); try { a="

This code cannot really be passed into a URL, so we use a URL encoder to hide the string with:


and the result becomes:

document.getElementById("idUsernameInput").innerHTML = "This password is for ";} catch (e) {
alert(0); try { "canary"; ";
 alert("Error: " + e.message);
 }// end catch

A pop-up message then appears with the newly injected code (see the demo for this).

3.5 XSS (Cross-site Scripting)

Many Web sites use LAMP – Linux, Apache, MySQL and PHP. This often uses PHP code to send SQL requests to a MySQL database. A typical call to a database is:

SELECT * FROM accounts WHERE username=’$admin’ AND password=’$pass’

And where the users enters “admin” and “password” gives:

SELECT * FROM accounts WHERE username=’admin’ AND password=’password‘

Then an intruder could change this to:

SELECT * FROM accounts WHERE username=’admin’ AND password=’’ OR 1=1 – ‘

Which will always return a true for the match. To achieve this enter the following as a password:

‘ OR 1=1 --

And convert this to a URL string:


When this is injected into the URL request for the page, it will show all the usernames and passwords on the database.

4 Tweet Deck Hack

The TweetDeck has is about a simple as it gets, as we will see

<script class="xss">$('.xss').parents().eq(1).find('a').eq(1).click();
$('[data-action=retweet]').click();alert('XSS in Tweetdeck')</script>♥

The Tweet Desk Hack is about as simple as you get, and it is similar to Section 3.2, where we modify the <a> tag (which does a hypertext link) and then does a click event on it. Pweh! That was hard work! So all that happens it modify a link on the Tweet Deck page, and get it to keep clicking, and retweeting … such bad practice!

5 Key factors in system design

A software bug is either non-intentional or intentional. With an intentional bug, the developer has added in a backdoor into the code which, when exercised, will allow a remote party into the code. One company that was accused of this is Crypto AG who, it is report, that colluded with Bundesnachrichtendienst (BND) and National Security Agency (NSA), to read the encrypted traffic on the machines with the backdoor. For non-intentional we can classify as:

  • Switched OnValidation flaws. The code fails to check for valid input data. This is often a major problem with Web-based code, where the code has not been tested for the complete range of user inputs. An intruder can often probe and analyse responses, and then craft an input which breaches the operation of the code. As we will see, in the Tweet Desk Hack, the input injects some JavaScript into a link, and then does not automated click on the link. The link thus becomes a robot clicking link, and can be used to spam other users, and even bring down systems with a Denial of Service attack.
  • Domain flaws. This is where data leaks from one program to another.
  • Serialisation flaws. This is where data changes while being passed from one program to another.
  • Identification/Authentication flaws. This is where there is a lack of identification for processes or users.
  • Boundary condition flaws. This is where resource access is not checked, and can thus allow an external hacker to use up resources.
  • Logic flaws. This is where the logic of the program, such the way it implements loops of decisions causes the program to act incorrectly.

bugSome of the key factors to the design of software are:

  • Never trust user input. All user input check be checked before it is used. This includes checking for correct number/string format, including valid characters.
  • Principle of least privilege. Processes and scripts should run with the least privilege possible, to minimize damage.
  • User secure defaults. Sometimes developers encounter security problems in running and applications. It is important that these are fully tested before reducing the security.
  • Authenticate at the front-end. In terms of resources, it is often better to authentication at the front-end rather than the back-end.
  • Never trust external systems. External systems should always be seen as a potential risk, and should never be fully trusted.
  • Reduce surface area. This should minimize the information that can be accessed from outside, and to handle errors in a graceful way.
  • Never rely on obfuscated code. Obfuscation of code just makes it more difficult to determine its operation. If an intruder wants to “crack” a program, then normally can, so other methods of securing the code should be employed.
  • Defence-in-depth. Checkpoints should be added for authentication and authorization at software interfaces, and interfaces within modules.
  • If it’s not used … disable it! Any services which can be accessed can be compromised, thus, if they are not needed, they should be disabled.
  • System is only as secure as the weakest link. The overall security of a system is only as strong as its weakest link.

One of the threats that is often fairly easy for the user to breach is where the user input is not checked, and the following section sees how we can inject some JavaScript code into the page.

6 Why don’t we teach security in coding?

Academia have been teaching code since the 1950s, from FORTRAN and COBAL to modern languages such as C# and Java. Unfortunately the way we have taught them has now really changed, where we teach our students to code around a procedural and/or objective oriented approach. Academics thus spend much of their time teaching students who to design and specify a program, and then how to write it, and finally validate it. The validation process is often running the program with some normal data, then with some boundary conditions, and that it. If student is smart, they will make sure they do not trust the user input, so values are entered as strings, and then checked and converted into the correct format. So a sloppy piece of code is:

namespace ConsoleApplication1
    class Program
        static void Main(string[] args)
            int age;
            Console.WriteLine("What is your age?");
            Console.WriteLine("Your age is " + age);

which works fine when we enter an integer:

What is your age? 
Your age is 32

but when we enter “a” we get an exception of:

Input string was not in a correct format.

Having examined many student programs, we one thing is often missing is the checking and the catching of exceptions with try … catch (Exception) {} code. A better way is to actually check the characters entered in terms of whether the value is valid, such as for an integer. So if the value is negative, or greater than 110, or has letters, or has an invalid character, then tell the user, and ask them for the correct format.

A good example of this when a user is entering their IP address. In this case we can use a regular expression to look for four values with up to three digits, with a ‘.’ in-between:

 namespace ConsoleApplication1
    class Program
        static void Main(string[] args)
            Console.WriteLine("Enter an IP address:");
            string ip = Console.ReadLine();
            Match match = Regex.Match(ip, @"\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}");
            if (match.Success)
                Console.WriteLine("IP is "+match.Value);
            else Console.WriteLine("Invalid");

The result is then:

Enter an IP address:
IP is
Enter an IP address:

Regular expressions are thus a wonder method in checking user input, to make sure that it matches the requirements, and provides a gate for code, where the program does not enter regions of the code, unless the input has been validated.


Our software is moving to the Web, where much of the code does not run as a Windows or Mac program. The code that often runs of Web servers is often quite messy, and there’s a general lack of testing. Software development teams must thus learn the methods of securing their code, especially in checking data input at the gate, and never to trust user input. For some reason, we often don’t teach security to software developers, especially in an understanding of how to handle exceptions in user input or from external systems, and how we encrypt data. The lack of understanding often lead to passwords and user credentials not be stored in a secure way. This, for the future needs to change! For many programs now, the coding is becoming easier, as we link to trusted services, but the testing and validation becomes difficult. Often as much time is spent testing, validating and evaluating a program, and its module, as it can to design, specify and implement it. Our teaching thus needs to change. Luckily, in this case, there was no real damage, but there is nothing to stop a future attempt full spamming the Internet, and bringing the whole infrastructure down. Also, we are looking at the tip of the iceberg here, the real threats relates to the lossage of user credials, which has more serious damage for both companies and users.

One thought on “TweetDeck Hack: How a 19 year-old playing with hearts broke the Internet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s