Outline
XSS -- The SAMY Worm
Buffer Overflow Exploits -- The Morris Worm
History of SSL/TLS -- from 1994 - 2012
Throughout history countless security exploits and vulnerabilities have affected Internet users. In this video I will go over some of the most notable ones that had a major impact on online safety.r
2005 -- The Year Cross-Site Scripting Took Down MySpace
By 2005 people started using web browsers to communicate with each other. MySpace was the first social media platform to be used across the planet. By this time web browsers rendered Javascript, an interpreted programming language developed by Brandon Eich at Netscape back in 1995 as well.
The SAMY Worm: Hack MySpace To Make New Friends
A clever MySpace user wanted to grow his friend list. Gee, that guy, must have been suffering from low popularity. This user noticed he could type in valid Javascript code.
The creator of the SAMY Worm--is a very proud man. While researching for this video I noticed Samy Karker, the creator of the SAMY worm, posted an HTML article explaining how he did the attack in detail.
When we take a look at what Samy did we notice Samy had to get past a bunch of defensive coding techniques MySpace enforced in an attempt to prevent any unwanted behavior. Samy had to construct weird code and text to avoid the escape encoding and randomized hashing that MySpace performs to ensure all requests were authentic. Sadly, it was not enough to stop Samy.
And here is the complete SAMY worm:
I am not stretching the truth here--he himself says he did this to get girls to like him. I mean just look at what he said were his thoughts as the worm spread earlier in the day:
Whenever a victim visited Samy's MySpace profile page the SAMY worm would be added to the victim's own profile page. And that means anyone who viewed the victim's profile would also ad SAMY's worm to their own profile. As Samy documents on his own website it took less than 24 hours for MySpace users to send strongly-worded messages to Samy for spamming their MySpace profile with this:
By October 4, 2005, Samy had 1,005,831 friend requests in only 20 hours. The next day the MySpace updated their site to render the worm ineffective. In 2006, Samy Karker was raided by the United States Secret Service and Electronic Crimes Task Force. Samy agreed to a felony charge on Janaury 31, 2007. He was only sentenced to three years of probation, 90 days of community service, and as much as $100,000,000 in restitution.
To learn more about the Samy worm feel free to see the official Youtube video where Samy himself proudly discusses the exploit:
After news of the SAMY worm hit the public, organizations made more serious attempts to defend against Cross Site Scripting--now being recognized as a serious threat to online safety. By 2015, only 47% of websites were estimated to be vulnerable to an exploit by the SAMY worm according to a study by WhiteHat Security.
Well Samy, as one person put it--you definitely guts pulling that one--as hairy of a decision that was:
Well, there is some good news to this. At least Samy's real girlfriend called Samy up and said he was her hero.
1988 -- The first Widespread Internet Exploit
Back in 1988 web browsers did not yet exist. People relied on a text-based application called a command line terminal to connect to other machines. Several university students used these terminals to communicate with other machines. UNIX was built in C and thus the majority of the applications people used were also written in C. As I explained in a previous video a common problem with languages such as C is they suffer from an issue called a buffer overflow vulnerability. A buffer overflow takes place when a machine appends data to an array beyond the array's allocated region.
Back then the Internet was known as the ARPANET and it was more of a science experiment that university students participated in. A computer science graduate student at Cornell, Robert Morris, wanted to record a survey of the number of people on the Internet at that time.To do this, Robert Morris decided to write a computer virus. This virus, now known as the Morris worm, would exploit a buffer overflow vulnerability in the ``fingerd` UNIX command--a command line application to display information about the users on a UNIX machine.
To help the virus spread, Morris took advantage of a buffer overflow in the `fingerd.c` program. Take a look at the highlighted line of code from `fingerd.c`. Do you see something wrong with it?
For those of you educated in secure coding in C you will immediately notice the `gets()` standard library function in C will scan the contents of a line of text and copy its contents to the `line` buffer. However, the `gets()` function will copy all the characters from a line of code regardless of size. In the `fingerd.c` program that Robert Morris used the `line` buffer only had a buffer capacity of `512` bytes. That means if a person supplied a line from STDIN longer than 512 bytes `gets()` would continue to copy the line's contents past the 512th byte in the `line` buffer!
To protect his identity, Morris first hacked into his own computer from MIT remotely from his machine at Cornell. Once launched, Morris's worm spread across 6000 machines in less than 24 hours. The worm congested computer networks, which were not as capable of handling client requests as they are today. A student from UC Berkeley complained machines were slowing to a crawl from the worm's influence. Other machines from universities affected by the Morris worm included but were not limited to Harvard, Stanford, Princeton, Johns Hopkins, and even NASA!
What is most amazing about the Morris Worm is that it was only designed to work on a very specific version of UNIX, UNIX 4.3BSD-Tahoe. This restriction clearly did not stop the virus from harming far more machines than Morris anticipated.
Emails took days to be delivered. Some institutions wiped their computer storage drives clean in an attempt to remove it. Others attempted to reverse engineer the virus in an attempt to learn how the worm worked. In grand total, the Morris worm caused millions of dollars in damage. Universities, government institutions, and even the US military panicked in desperate attempts to eradicate the virus.
Robert Morris watched ARPANET crumble thanks to the virus he wrote. He first asked a friend to release an anonymous message explaining how to remove it. Ironically, few people could receive the message--because again--email took days to be delivered, remember?
A friend of Robert Morris's contacted the The New York Times about the attack. This friend accidentially revealed Robert Morris's identity.
Now the FBI was on his tail. In 1986, the Computer Fraud and Abuse Act was passed--preventing a person from gaining unauthorized access to another's machine. Robert Morris was charged in 1989. In 1990, Morris was found guilty of violating this Act and was the first person in documented history to be convicted of violating it.
To combat such attacks in the future, the United States Department of Defense launched the Computer Emergency Response Team--now a subdivision of Carnegie Mellon Institute. To this day, CERT offers secure coding guidelines that are respected in the tech industry.
The Morris worm was not the last virus of its kind. Soon several worms that exploited software bugs erupted. To this day 70% of vulnerabilities reported are memory bugs--so this is not an irrelevant problem at all!
1994 -- Secure Sockets Layer / Transport Layer Security is Invented
By 1994 the Internet evolved closer to what we see today. People were using computers to use a web browser to visit websites. Once people around the world did this in mass number businesses started investing in website application technology to sell merchandise online.
Netscape decided to develop Secure Sockets Layer--the first version of Transport Layer Security--to encrypt electronic commerce on the Internet. It proved to be one of the most important security innovations for the Internet.
The first version of Secure Sockets Layer was invented in 1994 CE. Many serious flaws have been discovered throughout SSL and TLS's history since cryptographic engineering is very difficult to do properly. In fact, the SSL v1.0 made in 1994 CE was discovered to have major flaws. It was discovered to have no data integrity checks. Since SSL v1 used RC4, a primitive stream cipher, this helped attackers forge predictable ciphertext. Netscape tried to combat this with Cyclic Redudancy Checksums--but that was also found to have flaws too! To avoid further embarrassment Netscape decided not to release SSL v1 to the public to avoid scrutiny.
In March 1995 Netscape finally published Secure Sockets Layer version 2. In October that same year Microsoft was one of the earliest public adopters of the new protocol. To complete Netscape's SSL Microsoft published the Private Communication Technology. It was meant to resolve SSL v2's security flaws. Unfortunately for Microsoft it never gained traction outside of Microsoft products.
Microsoft's Private Communication Technology was doomed to fail either way because by November 1995 major security flaws were discovered in SSL v2. An embarassed Netscape rushes to develop SSLv3. In 1996, the Internet Engineering Task Force standardizes SSL for use on the Internet. The IETF's specification is almost identical to SSL v3 but in a meeting with NetScape and Microsoft both agree to allow IETF to take over the standardization of SSL, now renamed Transport Layer Security, with the publication of RFC 2246.
Sadly it didn't take long for people to hack through the TLS system. When issuing TLS certificates, an organization known as a Certificate Authority is meant to first verify if the requester of a TLS Certificate is the true owner of the DNS domain requesting the TLS certificate. Well, in January 2001 someone called Verisign--who owns two of the Internet's DNS root servers--missued a TLS certificate to an attacker. This hacker claimed to be from Microsoft. And so, for $400, Verisign issued a valid TLS certificate to this attacker.
The next major vulnerability in TLS was discovered in May 2008. A researcher known as Luciano Bello discovers a major bug in how the GNU/Debian Linux operating system generates TLS certificates. To generate TLS certificates, machines must use a Cryptographically Secure Random Number Generator to generate the private key necessary to sign TLS Certificates. The error was a careless mistake. Only a single line of code was commented out! That alone reduced the entropy of private key generation down to 16 bits of entropy. In modern cryptography 128 bits are recommended! To make matters worse Debian is a very popular GNU/Linux distribution in the world of cloud computing. So many people were affected by this careless error.
There is a sad lesson to be learned from this story--even open source projects suffer from lack of careful source code review. Just because a source code is open source it does not mean people will check to ensure the code's implementation follows secure coding guidelines.
Before I mention the next wave of TLS vulnerabilities--I will highlight an important event that took place in August 2008. TLS v1.2 was the first TLS to offer Authenticated Encryption with Associated Data--which not only encrypted data but also verified the sender's identity--a concept known as authenticity. AEADs removed the need for block and stream ciphers--but no one really cared. Besides TLS v1.2 did not prevent the attacks I am about to talk about next from taking place despite this.
Later in December 19, 2008 that same year yet another hacker, Mike Zussman, managed to trick a Certificate Authority, Startcom, into issuing him valid TLS certificates for PayPal and Verisign.--two domains he had no authority over. Luckily, Startcom had a blacklist of popular websites. So Mike's attempts were flagged and his requests denied within minutes. Even then, Mike discussed the attack at DEFCON 17. What's even funnier about this attack is that only a few days later Startcom discovered fraudulent TLS certificates issued by CertStar--a partner of the Comodo TLS Certificate authority. The CTO of Startcom, Eddy Nig, issued a fraudulent TLS certificate both for mozilla.org and startcom.org. News of this hit the press and amidst the commotion Comodo conducted an investigation to revoke certificates whose authenticity could not be verified.
To be honest Comodo's efforts to revoke TLS Certificates seem pointless. By Feburary 2012, Google decided to stop allowing Chrome users check if TLS Certificates were revoked since most browsers, nor users, cared to check anyway. A future related vulnerability was discovered in December 2012 when Chrome's HTTP Public Key Pinning detected that TurkTrust, another Certificate Authority, misissued TLS certificates for 15 months. To be honest misissued TLS certificates will continue to be a problem across the Internet until organizations increase adoption of the official mitigation--Domain Name Systems Security Extensions.
But the attacks against TLSv1.2 only gets better from here. In December 2008 three attacks against TLS v1.2 take place!!!. A group of researchers led by Alex Sotirov use an MD5 collision to perform what is known as a collision attack against MD5. A collision attack against a hash algorithm such as MD5 takes place when an attacker discovers an input that maps to the same hash output as that required in a verifiable document such as TLS certificate. Since the discovered input maps to the same hash--verifiers of a fake TLS certificate featuring this discovered input can be tricked into thinking that the forged TLS certificate is authentic. Sotirov's attack abusing MD5 is strong enough to generate a valid TLS certificate for any website that relies on MD5.
In May 2012, the most devastating attack against TLS v1.2 arguably took place based on this observation. Remember the attack against MD5 led by Sotirov back in December 2008. Well, although that was published, no one took serious action until the attack I am about to tell you took place. In May 2012, researchers discovered the FLAME virus--a virus whose method of spreading across networks was suspiciously similar to the STUXNET virus. It is thought that some government sponsored the invention of this virus. The virus abused MD5 collisions to trick Microsoft's TLS Certificate Authority to issuing valid Microsoft TLS certificates. The FLAME Virus, now authorized to send Windows updates--installed itself on victim's machines. No one knows how long FLAME was quietly installing itself on machines--yet researchers think it has been five years.
Later in August 2009, Moxie Marlinspike, the former CEO of Signal Messaging, publishes the SSL Strip Attack. In this attack a Man-In-the-Middle Attacker forcibly downgrades a victim's TLS connection down to plaintext HTTP--allowing the attacker to view all communication. Shortly after Moxie presented this attack at DEFCON. In May 2010 Google launches HTTP Strict Transport Layer Security Preloading--a browser feature that ensures a browser is aware if a website supports TLS before launching an HTTP connection with it--making the SSL Stripping Attack impossible.
TLS's History of Vulnerabilities: A Conclusion
I have briefly summarized the vulnerabilities affecting SSL/TLS from its inception in 1995 to 2012. So far TLS vulnerabilities have arisen from failure to validate the owner of a domain (mis-issued TLS certificates).
Comments