Elvis Wiki - User contributions [en]

Stuxnet

2024-12-18T19:32:17Z

DHomberg:

== Summary ==

Stuxnet was the first known cyber weapon to be developed and utilized in an act of strategic sabotage (attacking SCADA systems). This led to a paradigm shift from the CIA triad (Confidentiality, Integrity, Authenticity/Availability), which focuses on data security, to physical system safety. Stuxnet's origin remains unclear, although there are numerous theories about who might have been responsible for the attack. It contains complex code, targeting a specific setup. A total of seven vulnerabilities were found (four of them zero-day attacks) for propagating, hiding, taking over and executing. Further, it used two (stolen) signed certificates to make Windows believe its .dll files were legit. Unlike other worms or trojans it is quite huge and implements several programming languages. Interestingly, it also has an “expiry date” where it would stop working. If not for coincidence, it might have never been discovered.

== Description ==

=== Targeted software and hardware setup ===

* Operating system: 32-bit Windows Operating System (2k, XP, 2003, Vista, Server 2008, 7, Server 2008 R2)
* PLC programming software: Siemens STEP7
* Hardware: S7-315-2/S7-417 programmable logic controllers with specific PROFIBUS VFD

=== Overview ===

* Over 500KBytes of code in several languages (mostly C and C++)
* Seven different ways to propagate, hide and replicate – four of them zero day exploits
* Two stolen certificates (RealTek Semiconductor and JMicron Technology) to appear legitimate
* Dropper / Worm (propagating by itself), Rootkit (by hiding itself and taking over the centrifuge controllers), Command&Control (by reporting to two servers outside and acquiring updates), SQL Injection, Man-in-the-Middle (by presenting “recorded” data to the monitors of the vaults while attacking), Process Injection
* Detailed knowledge about the targets was necessary to develop this malware
* Two different attack patterns – gas pressure and spin speed – which had very specific conditions and were not meant to destroy immediately but rather delay the uranium enrichment
* Development of Stuxnet (according to various sources) required a team of five to ten programmers working full-time for at least six months

=== Four zero-day attacks ===

Zero-day attacks target vulnerabilities that have not yet been found and therefore also not been patched, giving attackers huge advantages. Finding these vulnerabilities and developing working exploits costs a lot of time, money and human resources.

==== Replication ====

* Shortcut "LNK" Files Automatic File Execution vulnerability (CVE-2010-2568<ref name="CVE_LNK"/>, MS10-046<ref name="MS_LNK"/>): Bypassing disabled auto-run allowing auto-execution

* Print Spooler Service Impersonation vulnerability (CVE-2010-2729<ref name="CVE_PrintSpooler"/>, MS10-061<ref name="MS_PrintSpooler"/>): Installing .exe to %System% Folder that loads .dll file

==== Privilege escalation ====

* Task Scheduler Escalation of Privilege vulnerability (CVE-2010-3888<ref name="CVE_Task"/>): Starting the .dll as a new process with administrator rights (Windows Vista / Windows 7 / Windows Server R2)

* Local Privilege Escalation vulnerability (CVE-2010-2743<ref name="CVE_PrivEsc"/>, MS10-073<ref name="MS_PrivEsc"/>): Starting the .dll as a new process within csrss.exe (Windows XP / Windows 2000)

== Story of Stuxnet ==

=== Historical background ===

In April 2006 Iran announced they have successfully enriched uranium, refusing to give in to international demands to close its nuclear program.
From February to November 2007 about 3000 new centrifuges were installed in Natanz, a uranium enrichment plant. In the same year the US Congress released $400 million for covert operations called "Olympic Games" against Iran´s nuclear program as Israel felt threatened by it due to their proximity to Iran. After Israel threatened physical violence, the US knew they had to find a solution.

In 2008, Israel requested assistance from the US for an airstrike on Natanz. However, US leaders were concerned that this action could escalate into a larger conflict. Given the political climate at the time, the US did not want to engage in another war. This is why they thought about sabotaging Iran with them knowing it.

Throughout 2009 the number of centrifuges at Natanz was increased to 8700. On at least one occasion, President Ahmadinejad proudly led a tour through the facility, providing videos and images of control rooms and centrifuges to the world.

Early 2010 the IAEA (International Atomic Energy Agency) inspectors that periodically visited Natanz, noticed a huge number of centrifuges being replaced.
Later that year, Stuxnet was discovered and with it the cause for the failing centrifuges.

Centrifuges were important for the development of nuclear weapons because they can spin at a rapid speed to separate different isotopes of uranium.

=== Discovery ===

The first person to encounter what was later known as Stuxnet was Sergey Ulason at VirusBlokAda, Belarus in June 2010. One of their customers in Iran contacted them because their computer kept crashing.

Ulason and his colleagues discovered several interesting factors about the malware they were presented with, including the replication methods, the ability to hide in other processes and the usage of stolen certificates to legitimize to antivirus programs and Windows security.

They contacted Microsoft and RealTek to inform them about their discovery. As neither of the companies reacted, they finally posted their findings online, but it took a blog article by Brian Krebs on KrebsOnSecurity.com to gain attention.

Symantec started their own research on Stuxnet as it was to be then named. Also, Ralph Langner, a German cybersecurity specialist and expert on industrial control systems, turned his attention on Stuxnet. He found clues that it targeted a specific environment and only two Siemens PLC models.

By the time Stuxnet was discovered, the scientists had to replace over 1.000 centrifuges and the cascades were only working at 45-65 percent. By September 2010, the researchers found out that about 100.000 computers worldwide had been infected. From these machines, over 60 percent were located in Iran, which gave researchers a good idea about the original target.

=== Infection statistics ===

After the discovery of Stuxnet, Symantec set up a System on July 20, 2010 to monitor traffic to the command and control servers. The hereby collected data allowed to observe rates of infections and the location of infected computers. Only traffic from computers which are able to connect to the C&C servers can be collected. While the data has shown approximately 100.000 infected hosts, 40.000 unique external IP addresses from over 155 countries could be observed. Approximately 60% of infected hosts were located in Iran:

{| class="wikitable"
|-
! Country
! Share of infected computers
|-
| Iran
| 58.31%
|-
| Indonesia
| 17.83%
|-
| India
| 9.96%
|-
| Azerbaijan
| 3.40%
|-
| Pakistan
| 1.40%
|-
| Malaysia
| 1.16%
|-
| USA
| 0.89%
|-
| Uzbekistan
| 0.71%
|-
| Russia
| 0.61%
|-
| Great Britain
| 0.57%
|-
| Others
| 5.15%
|}

The accumulation of infections indicate that Iran was the initial target of the attack as well as the country where infections were originally seeded. The data further supports the classification of Stuxnet as a targeted attack.

=== Origins ===

Both evidence and motive indicate that the US and Israel were involved in the attack, as they have the financial means and human resources. Additionally, both countries maintain research facilities that could have been used to test the malware on the same setup as found in Natanz.
Other sources even mention China and Russia. However, neither of these states admitted any involvement. Even Iran denies that the closure of Natanz happened as a consequence of a cyberattack.

== Propagation ==

Stuxnet can spread in a variety of ways, as shown in the Figure "Stuxnet Propagation". Stuxnet spreads by infecting removable drives and copying itself over the network using a variety of means, including two Zero-Day exploits. Stuxnet also spreads by copying itself into Step 7 projects, using a technique that causes Stuxnet to run automatically when the project is opened. This section introduces the distribution routines via the network, removable drive and the Step-7 projects.

[[File: Stuxnet_propagation.png|400px|thumb|right|Stuxnet Propagation]]

=== Propagation via removable media ===

The real goal of Stuxnet are the computers that control the centrifuges. These are referred to as PLCs (Programmable Logic Controllers) and are special computers that are used to control electronic devices or systems, such as industrial systems. The PLCs are connected to computers which control and monitor these PLCs, and usually neither are connected to the Internet. Hence, Stuxnet needed another vector to reach these computers. One way was to propagate through USB flash drives. The different versions of Stuxnet use different ways for this: newer versions use a Windows-LNK vulnerability and older versions use a vulnerability in the autorun.inf file, both of which are examined in more detail below.

==== LNK vulnerability (CVE-2010-2568) ====

Stuxnet registers a code on an infected Windows computer that copies Stuxnet to the drive when a USB drive is inserted. Interestingly, an existing copy of Stuxnet on the external drive will be removed if that drive has already infected three computers. In addition to the Stuxnet DLL and a loader for this DLL, the malware creates four .lnk files on the removable drive. These are used to run the loader when a user is viewing the drive.

To make sure that Stuxnet would reach its target, the attackers made sure to infect every version of Windows operating systems released after Windows 2000. An infected flash drive contained six malicious shortcut files. The first four files related to the different versions of operating systems. The .LNK files executed on Windows 7, the second one on Windows Vista and the last two executed on Windows XP, Windows server 2003 and Windows 2000.

==== Autorun.inf ====

An autorun.inf file is a file that causes Windows to automatically run a file on removable media when the media is inserted into the computer. Older versions of Stuxnet place an autorun.inf file on flash drives that are inserted into an infected computer. However, instead of using a separate file, it inserts the code for itself directly into the autorun file, along with valid commands to infect the computer with that code. Windows ignores the Stuxnet data portion because it ignores invalid commands in an autorun.inf file.

=== Propagation over the network ===

Stuxnet can use shared Windows folders to spread over a local network. It places a dropper file on any shares on remote computers and schedules a task to run. According to ESET, the task will be scheduled for the next day, while according to Symantec it should run two minutes after the file is shared.

==== Zero-Day-Exploit in print-spooler MS10-061<ref name="MS_PrintSpooler"/> ====

This zero-day exploit was unique in that it had been discovered prior to its use by the creators of Stuxnet. Information along with source code had been published in a Polish security magazine in April 2009. However, the information about this vulnerability never reached Microsoft, which made it possible for Stuxnet creators to use it to spread the virus within a network. It has later been patched by Microsoft. It was also the only zero-day found in the first version of Stuxnet.

This zero-day made any system which had shared print rights in a network vulnerable. It allowed a remote user to copy files into the Windows %SYSTEM% directory, to which users have no access. There were two phases to this exploit. It first went through the injection phase, where a dropper and the files “winsta.exe” and “sysnullevent.mof” are copied into the directory. It did that by improperly impersonating a client who sent the two files to be printed to files in the directory.

The execution phase then triggered these two files. A dropper is a malicious program that is designed to spread malware to other computers. In the execution phase, the sysnullevent.mof file was used. This was a Managed Object Format or MOF for short, and it is used to create or register providers or events. This file also ran the winst.exe file, which would result in the infection of the system.

==== SMB vulnerability MS08-067 <ref name=MS_SMB/> ====

If a remote computer has this vulnerability, Stuxnet can send a bad path over SMB (a protocol for sharing files and other resources between computers), allowing arbitrary code to be run on the remote computer.
This vulnerability allowed Stuxnet to execute code on a remote host if an affected system received a specially crafted RPC (Remote Procedure Call) request. On Microsoft Windows 2000, Windows XP and Windows Server 2000, Stuxnet could exploit this vulnerability without authentication and run arbitrary code. For Stuxnet it was possible to use this vulnerability in the crafting of a wormable exploit.

==== Peer-to-peer communication ====

Stuxnet also use a simple peer-to-peer (P2P) communication protocol to update infected hosts within a local network. It installs a RPC server and client on newly infected hosts. The RPC server listens for connections, allowing previously infected hosts to connect and check for updates. If necessary, the server can then send the latest version of Stuxnet to the requesting client.

==== WinCC database servers ====

Stuxnet scans the network for WinCC database servers. If it finds one, it uses a hard-coded password to establish a connection. Once connected, Stuxnet infects the server using a modified SQL query. <ref name=WinCC/>

==== Network shares ====

Stuxnet attempts to infect all accessible shared network resources by leveraging the local user's credentials or employing the Windows Management Instrumentation (WMI). If successful, it copies itself to the resource and executes through a scheduled network job.

=== Propagation via Step 7 projects ===

Via Step7 projects, Stuxnet infects industrial control projects from Siemens SIMATIC Step7 that are opened on an infected computer. This is done by modifying DLLs (Windows Dynamic Link Library; a library with commonly used objects: code, data and resources) and an .exe file in the WinCC Simatic Manager so that they can also execute Stuxnet code. Stuxnet inserts the additional code into Step7 project directories.

== Infection Process ==

To evade detection, Stuxnet injects its DLL file into trusted processes such as lsass.exe, winlogon.exe, or svchost.exe. It adapts its choice based on installed antivirus software to minimize risk of detection. Stuxnet then uses the two previously mentioned zero-day exploits for privilege escalation to gain administrator rights. It proceeds with the main installation, installing two driver files: a load point driver to relaunch Stuxnet after system reboots and a rootkit driver to conceal Stuxnet binaries. These drivers are signed with stolen certificates to appear legitimate. Stuxnet also injects into Windows services.exe for infecting removable drives and into Step7 processes for infecting Step7 projects. After installation, Stuxnet connects to a remote command and control (C&C) server for backdoor access and distribution of updates. If the targeted ICS software is found, it proceeds with its specific operations; otherwise, it continues propagating until it infects a suitable host.

== Similar attacks ==

=== Duqu ===
In October 2011, Hungarian researchers discovered Duqu, which exhibited remarkable similarities to Stuxnet in terms of design, mechanisms, and internal structure. This led them to believe that the developers of Stuxnet might have been involved in creating Duqu. However, unlike Stuxnet, Duqu was not designed to manipulate physical processes in an industrial setting, but it was designed for the collection of data in cyber espionage. Duqu exploited a zero-day vulnerability in emails with a MS Word document. A parsing error in the kernel TrueType Font allowed the installation of Duqu.

=== Flame ===

The Flame attack, discovered in May 2012, was used for cyber espionage, similar to Duqu. After Flame was discovered in Europe, later also found in the United Arab Emirates as well as in Iran, the supposed main target of Stuxnet. Flame deploys mechanisms very similar to Stuxnet, though it is larger and does not target a specific industry. It also uses two zero-day exploits.

=== Triton ===

Triton was discovered in Saudi Arabia in 2017. Like Stuxnet, it was designed to target ICSs, in this case the control system of a petrochemical plant, endangering its safety. Luckily, it was discovered before it caused physical harm. It was also speculated that Triton was developed to modify safety systems to enable future attacks.

== References ==

* Kim Zetter. Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon. Broadway Books, 2015.
* Ben Buchanan. The Hacker and the State. Harvard University Press, 2020
* Nicolas Falliere, Liam O Murchu, and Eric Chien. W32. Stuxnet dossier. White paper, Symantec Corp., Security Response, 5(6):29, 2011.
* D.E. Sanger. Confront and Conceal: Obama’s Secret Wars and Surprising Use of American Power. Crown, 2012.
* T. M. Chen and S. Abu-Nimeh. Lessons from stuxnet. Computer, 44(4):91-93, 2011
* Aleksandr Matrosov, Eugene Rodionov, David Harley, Juraj Malcho. [https://web-assets.esetstatic.com/wls/2012/11/Stuxnet_Under_the_Microscope.pdf Stuxnet Under the Microscope. Paper, ESET, 2010] accessed 02.03.2024.
* Boldizsár Bencsáth, Gábor Pék, Levente Buttyán, and Márk Félegyházi.The Cousins of Stuxnet: Duqu, Flame, and Gauss. Future Internet, 4(4):971–1003, November 2012.
* Sumayah Al-Rabiaah. The “Stuxnet” Virus of 2010 As an Example of A “APT” and Its “Recent” Variances. In 2018 21st Saudi Computer Society National Computer Conference (NCC), pages 1–5, Riyadh, IEEE, April 2018.
* Martin Giles. [https://www.technologyreview.com/2019/03/05/103328/cybersecurity-critical-infrastructure-triton-malware/ Triton is the world’s most murderous malware, and it’s spreading. MIT Technology Review, March 2019] accessed 04.03.2024.

<references>

<ref name="CVE_LNK">NIST. [https://nvd.nist.gov/vuln/detail/CVE-2010-2568 CVE-2010-2568] accessed 04.03.2024.</ref>

<ref name="MS_LNK">Microsoft. [https://learn.microsoft.com/en-us/security-updates/SecurityBulletins/2010/ms10-046 Microsoft Security Bulletin MS10-046 - Critical] accessed 03.03.2024.</ref>

<ref name="CVE_PrintSpooler">NIST. [https://nvd.nist.gov/vuln/detail/CVE-2010-2729 CVE-2010-2729] accessed 03.03.2024.</ref>

<ref name="MS_PrintSpooler">Microsoft, [https://learn.microsoft.com/en-us/security-updates/securitybulletins/2010/ms10-061 Microsoft Security Bulletin MS10-061 - Critical] accessed 04.03.2024.</ref>

<ref name="CVE_Task">NIST. [https://nvd.nist.gov/vuln/detail/CVE-2010-3888 CVE-2010-3888] accessed 03.03.2024.</ref>

<ref name="CVE_PrivEsc">NIST. [https://nvd.nist.gov/vuln/detail/CVE-2010-2743 CVE-2010-2743] accessed 03.03.2024.</ref>

<ref name="MS_PrivEsc">Microsoft. [https://learn.microsoft.com/en-us/security-updates/securitybulletins/2010/ms10-073 Microsoft Security Bulletin MS10-073 - Important] accessed 03.03.2024.</ref>

<ref name=MS_SMB>Microsoft. [https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2008/ms08-067 Microsoft Security Bulletin MS08-067 - Critical] accessed 02.03.2024.</ref>

<ref name="WinCC">NIST. [https://nvd.nist.gov/vuln/detail/CVE-2010-2772 CVE-2010-2772] accessed 04.03.2024.</ref>

</references>

[[Category:Documentation]]

Stuxnet

2024-12-18T19:29:26Z

DHomberg: /* Story of Stuxnet */

== Summary ==

Stuxnet was the first known cyber weapon to be developed and utilized in an act of strategic sabotage (attacking SCADA systems). This led to a paradigm shift from the CIA triad (Confidentiality, Integrity, Authenticity/Availability), which focuses on data security, to physical system safety. Stuxnet's origin remains unclear, although there are numerous theories about who might have been responsible for the attack. It contains complex code, targeting a specific setup. A total of seven vulnerabilities were found (four of them zero-day attacks) for propagating, hiding, taking over and executing. Further, it used two (stolen) signed certificates to make Windows believe its .dll files were legit. Unlike other worms or trojans it is quite huge and implements several programming languages. Interestingly, it also has an “expiry date” where it would stop working. If not for coincidence, it might have never been discovered.

== Description ==

=== Targeted software and hardware setup ===

* Operating system: 32-bit Windows Operating System (2k, XP, 2003, Vista, Server 2008, 7, Server 2008 R2)
* PLC programming software: Siemens STEP7
* Hardware: S7-315-2/S7-417 programmable logic controllers with specific PROFIBUS VFD

=== Overview ===

* Over 500KBytes of code in several languages (mostly C and C++)
* Seven different ways to propagate, hide and replicate – four of them zero day exploits
* Two stolen certificates (RealTek Semiconductor and JMicron Technology) to appear legitimate
* Dropper / Worm (propagating by itself), Rootkit (by hiding itself and taking over the centrifuge controllers), Command&Control (by reporting to two servers outside and acquiring updates), SQL Injection, Man-in-the-Middle (by presenting “recorded” data to the monitors of the vaults while attacking), Process Injection
* Detailed knowledge about the targets was necessary to develop this malware
* Two different attack patterns – gas pressure and spin speed – which had very specific conditions and were not meant to destroy immediately but rather delay the uranium enrichment
* Development of Stuxnet (according to various sources) required a team of five to ten programmers working full-time for at least six months

=== Four zero-day attacks ===

Zero-day attacks target vulnerabilities that have not yet been found and therefore also not been patched, giving attackers huge advantages. Finding these vulnerabilities and developing working exploits costs a lot of time, money and human resources.

==== Replication ====

* Shortcut "LNK" Files Automatic File Execution vulnerability (CVE-2010-2568<ref name="CVE_LNK"/>, MS10-046<ref name="MS_LNK"/>): Bypassing disabled auto-run allowing auto-execution

* Print Spooler Service Impersonation vulnerability (CVE-2010-2729<ref name="CVE_PrintSpooler"/>, MS10-061<ref name="MS_PrintSpooler"/>): Installing .exe to %System% Folder that loads .dll file

==== Privilege escalation ====

* Task Scheduler Escalation of Privilege vulnerability (CVE-2010-3888<ref name="CVE_Task"/>): Starting the .dll as a new process with administrator rights (Windows Vista / Windows 7 / Windows Server R2)

* Local Privilege Escalation vulnerability (CVE-2010-2743<ref name="CVE_PrivEsc"/>, MS10-073<ref name="MS_PrivEsc"/>): Starting the .dll as a new process within csrss.exe (Windows XP / Windows 2000)

== Story of Stuxnet ==

=== Historical background ===

In April 2006 Iran announced they have successfully enriched uranium, refusing to give in to international demands to close its nuclear program.
From February to November 2007 about 3000 new centrifuges were installed in Natanz, a uranium enrichment plant. In the same year the US Congress released $400 million for covert operations called "Olympic Games" against Iran´s nuclear program as Israel felt threatened by it due to their proximity to Iran. After Israel threatened physical violence, the US knew they had to find a solution.

In 2008, Israel requested assistance from the US for an airstrike on Natanz. However, US leaders were concerned that this action could escalate into a larger conflict. Given the political climate at the time, the US did not want to engage in another war. This is why they thought about sabotaging Iran with them knowing it.

Throughout 2009 the number of centrifuges at Natanz was increased to 8700. On at least one occasion, President Ahmadinejad proudly led a tour through the facility, providing videos and images of control rooms and centrifuges to the world.

Early 2010 the IAEA (International Atomic Energy Agency) inspectors that periodically visited Natanz, noticed a huge number of centrifuges being replaced.
Later that year, Stuxnet was discovered and with it the cause for the failing centrifuges.

Centrifuges were important for the development of nuclear weapons because they can spin at a rapid speed to separate different isotopes of uranium.

=== Discovery ===

The first person to encounter what was later known as Stuxnet was Sergey Ulason at VirusBlokAda, Belarus in June 2010. One of their customers in Iran contacted them because their computer kept crashing.

Ulason and his colleagues discovered several interesting factors about the malware they were presented with, including the replication methods, the ability to hide in other processes and the usage of stolen certificates to legitimize to antivirus programs and Windows security.

They contacted Microsoft and RealTek to inform them about their discovery. As neither of the companies reacted, they finally posted their findings online, but it took a blog article by Brian Krebs on KrebsOnSecurity.com to gain attention.

Symantec started their own research on Stuxnet as it was to be then named. Also, Ralph Langner, a German cybersecurity specialist and expert on industrial control systems, turned his attention on Stuxnet. He found clues that it targeted a specific environment and only two Siemens PLC models.

By the time Stuxnet was discovered, the scientists had to replace over 1.000 centrifuges and the cascades were only working at 45-65 percent. By September 2010, the researchers found out that about 100.000 computers worldwide had been infected. From these machines, over 60 percent were located in Iran, which gave researchers a good idea about the original target.

=== Infection Statistics ===

After the discovery of Stuxnet, Symantec set up a System on July 20, 2010 to monitor traffic to the command and control servers. The hereby collected data allowed to observe rates of infections and the location of infected computers. Only traffic from computers which are able to connect to the C&C servers can be collected. While the data has shown approximately 100.000 infected hosts, 40.000 unique external IP addresses from over 155 countries could be observed. Approximately 60% of infected hosts were located in Iran:

{| class="wikitable"
|-
! Country
! Share of infected computers
|-
| Iran
| 58.31%
|-
| Indonesia
| 17.83%
|-
| India
| 9.96%
|-
| Azerbaijan
| 3.40%
|-
| Pakistan
| 1.40%
|-
| Malaysia
| 1.16%
|-
| USA
| 0.89%
|-
| Uzbekistan
| 0.71%
|-
| Russia
| 0.61%
|-
| Great Britain
| 0.57%
|-
| Others
| 5.15%
|}

The accumulation of infections indicate that Iran was the initial target of the attack as well as the country where infections were originally seeded. The data further supports the classification of Stuxnet as a targeted attack.

=== Origins ===

Both evidence and motive indicate that the US and Israel were involved in the attack, as they have the financial means and human resources. Additionally, both countries maintain research facilities that could have been used to test the malware on the same setup as found in Natanz.
Other sources even mention China and Russia. However, neither of these states admitted any involvement. Even Iran denies that the closure of Natanz happened as a consequence of a cyberattack.

== Propagation ==

Stuxnet can spread in a variety of ways, as shown in the Figure "Stuxnet Propagation". Stuxnet spreads by infecting removable drives and copying itself over the network using a variety of means, including two Zero-Day exploits. Stuxnet also spreads by copying itself into Step 7 projects, using a technique that causes Stuxnet to run automatically when the project is opened. This section introduces the distribution routines via the network, removable drive and the Step-7 projects.

[[File: Stuxnet_propagation.png|400px|thumb|right|Stuxnet Propagation]]

=== Propagation via removable media ===

The real goal of Stuxnet are the computers that control the centrifuges. These are referred to as PLCs (Programmable Logic Controllers) and are special computers that are used to control electronic devices or systems, such as industrial systems. The PLCs are connected to computers which control and monitor these PLCs, and usually neither are connected to the Internet. Hence, Stuxnet needed another vector to reach these computers. One way was to propagate through USB flash drives. The different versions of Stuxnet use different ways for this: newer versions use a Windows-LNK vulnerability and older versions use a vulnerability in the autorun.inf file, both of which are examined in more detail below.

==== LNK vulnerability (CVE-2010-2568) ====

Stuxnet registers a code on an infected Windows computer that copies Stuxnet to the drive when a USB drive is inserted. Interestingly, an existing copy of Stuxnet on the external drive will be removed if that drive has already infected three computers. In addition to the Stuxnet DLL and a loader for this DLL, the malware creates four .lnk files on the removable drive. These are used to run the loader when a user is viewing the drive.

To make sure that Stuxnet would reach its target, the attackers made sure to infect every version of Windows operating systems released after Windows 2000. An infected flash drive contained six malicious shortcut files. The first four files related to the different versions of operating systems. The .LNK files executed on Windows 7, the second one on Windows Vista and the last two executed on Windows XP, Windows server 2003 and Windows 2000.

==== Autorun.inf ====

An autorun.inf file is a file that causes Windows to automatically run a file on removable media when the media is inserted into the computer. Older versions of Stuxnet place an autorun.inf file on flash drives that are inserted into an infected computer. However, instead of using a separate file, it inserts the code for itself directly into the autorun file, along with valid commands to infect the computer with that code. Windows ignores the Stuxnet data portion because it ignores invalid commands in an autorun.inf file.

=== Propagation over the network ===

Stuxnet can use shared Windows folders to spread over a local network. It places a dropper file on any shares on remote computers and schedules a task to run. According to ESET, the task will be scheduled for the next day, while according to Symantec it should run two minutes after the file is shared.

==== Zero-Day-Exploit in print-spooler MS10-061<ref name="MS_PrintSpooler"/> ====

This zero-day exploit was unique in that it had been discovered prior to its use by the creators of Stuxnet. Information along with source code had been published in a Polish security magazine in April 2009. However, the information about this vulnerability never reached Microsoft, which made it possible for Stuxnet creators to use it to spread the virus within a network. It has later been patched by Microsoft. It was also the only zero-day found in the first version of Stuxnet.

This zero-day made any system which had shared print rights in a network vulnerable. It allowed a remote user to copy files into the Windows %SYSTEM% directory, to which users have no access. There were two phases to this exploit. It first went through the injection phase, where a dropper and the files “winsta.exe” and “sysnullevent.mof” are copied into the directory. It did that by improperly impersonating a client who sent the two files to be printed to files in the directory.

The execution phase then triggered these two files. A dropper is a malicious program that is designed to spread malware to other computers. In the execution phase, the sysnullevent.mof file was used. This was a Managed Object Format or MOF for short, and it is used to create or register providers or events. This file also ran the winst.exe file, which would result in the infection of the system.

==== SMB vulnerability MS08-067 <ref name=MS_SMB/> ====

If a remote computer has this vulnerability, Stuxnet can send a bad path over SMB (a protocol for sharing files and other resources between computers), allowing arbitrary code to be run on the remote computer.
This vulnerability allowed Stuxnet to execute code on a remote host if an affected system received a specially crafted RPC (Remote Procedure Call) request. On Microsoft Windows 2000, Windows XP and Windows Server 2000, Stuxnet could exploit this vulnerability without authentication and run arbitrary code. For Stuxnet it was possible to use this vulnerability in the crafting of a wormable exploit.

==== Peer-to-peer communication ====

Stuxnet also use a simple peer-to-peer (P2P) communication protocol to update infected hosts within a local network. It installs a RPC server and client on newly infected hosts. The RPC server listens for connections, allowing previously infected hosts to connect and check for updates. If necessary, the server can then send the latest version of Stuxnet to the requesting client.

==== WinCC database servers ====

Stuxnet scans the network for WinCC database servers. If it finds one, it uses a hard-coded password to establish a connection. Once connected, Stuxnet infects the server using a modified SQL query. <ref name=WinCC/>

==== Network shares ====

Stuxnet attempts to infect all accessible shared network resources by leveraging the local user's credentials or employing the Windows Management Instrumentation (WMI). If successful, it copies itself to the resource and executes through a scheduled network job.

=== Propagation via Step 7 projects ===

Via Step7 projects, Stuxnet infects industrial control projects from Siemens SIMATIC Step7 that are opened on an infected computer. This is done by modifying DLLs (Windows Dynamic Link Library; a library with commonly used objects: code, data and resources) and an .exe file in the WinCC Simatic Manager so that they can also execute Stuxnet code. Stuxnet inserts the additional code into Step7 project directories.

== Infection Process ==

To evade detection, Stuxnet injects its DLL file into trusted processes such as lsass.exe, winlogon.exe, or svchost.exe. It adapts its choice based on installed antivirus software to minimize risk of detection. Stuxnet then uses the two previously mentioned zero-day exploits for privilege escalation to gain administrator rights. It proceeds with the main installation, installing two driver files: a load point driver to relaunch Stuxnet after system reboots and a rootkit driver to conceal Stuxnet binaries. These drivers are signed with stolen certificates to appear legitimate. Stuxnet also injects into Windows services.exe for infecting removable drives and into Step7 processes for infecting Step7 projects. After installation, Stuxnet connects to a remote command and control (C&C) server for backdoor access and distribution of updates. If the targeted ICS software is found, it proceeds with its specific operations; otherwise, it continues propagating until it infects a suitable host.

== Similar attacks ==

=== Duqu ===
In October 2011, Hungarian researchers discovered Duqu, which exhibited remarkable similarities to Stuxnet in terms of design, mechanisms, and internal structure. This led them to believe that the developers of Stuxnet might have been involved in creating Duqu. However, unlike Stuxnet, Duqu was not designed to manipulate physical processes in an industrial setting, but it was designed for the collection of data in cyber espionage. Duqu exploited a zero-day vulnerability in emails with a MS Word document. A parsing error in the kernel TrueType Font allowed the installation of Duqu.

=== Flame ===

The Flame attack, discovered in May 2012, was used for cyber espionage, similar to Duqu. After Flame was discovered in Europe, later also found in the United Arab Emirates as well as in Iran, the supposed main target of Stuxnet. Flame deploys mechanisms very similar to Stuxnet, though it is larger and does not target a specific industry. It also uses two zero-day exploits.

=== Triton ===

Triton was discovered in Saudi Arabia in 2017. Like Stuxnet, it was designed to target ICSs, in this case the control system of a petrochemical plant, endangering its safety. Luckily, it was discovered before it caused physical harm. It was also speculated that Triton was developed to modify safety systems to enable future attacks.

== References ==

* Kim Zetter. Countdown to Zero Day: Stuxnet and the Launch of the World’s First Digital Weapon. Broadway Books, 2015.
* Ben Buchanan. The Hacker and the State. Harvard University Press, 2020
* Nicolas Falliere, Liam O Murchu, and Eric Chien. W32. Stuxnet dossier. White paper, Symantec Corp., Security Response, 5(6):29, 2011.
* D.E. Sanger. Confront and Conceal: Obama’s Secret Wars and Surprising Use of American Power. Crown, 2012.
* T. M. Chen and S. Abu-Nimeh. Lessons from stuxnet. Computer, 44(4):91-93, 2011
* Aleksandr Matrosov, Eugene Rodionov, David Harley, Juraj Malcho. [https://web-assets.esetstatic.com/wls/2012/11/Stuxnet_Under_the_Microscope.pdf Stuxnet Under the Microscope. Paper, ESET, 2010] accessed 02.03.2024.
* Boldizsár Bencsáth, Gábor Pék, Levente Buttyán, and Márk Félegyházi.The Cousins of Stuxnet: Duqu, Flame, and Gauss. Future Internet, 4(4):971–1003, November 2012.
* Sumayah Al-Rabiaah. The “Stuxnet” Virus of 2010 As an Example of A “APT” and Its “Recent” Variances. In 2018 21st Saudi Computer Society National Computer Conference (NCC), pages 1–5, Riyadh, IEEE, April 2018.
* Martin Giles. [https://www.technologyreview.com/2019/03/05/103328/cybersecurity-critical-infrastructure-triton-malware/ Triton is the world’s most murderous malware, and it’s spreading. MIT Technology Review, March 2019] accessed 04.03.2024.

<references>

<ref name="CVE_LNK">NIST. [https://nvd.nist.gov/vuln/detail/CVE-2010-2568 CVE-2010-2568] accessed 04.03.2024.</ref>

<ref name="MS_LNK">Microsoft. [https://learn.microsoft.com/en-us/security-updates/SecurityBulletins/2010/ms10-046 Microsoft Security Bulletin MS10-046 - Critical] accessed 03.03.2024.</ref>

<ref name="CVE_PrintSpooler">NIST. [https://nvd.nist.gov/vuln/detail/CVE-2010-2729 CVE-2010-2729] accessed 03.03.2024.</ref>

<ref name="MS_PrintSpooler">Microsoft, [https://learn.microsoft.com/en-us/security-updates/securitybulletins/2010/ms10-061 Microsoft Security Bulletin MS10-061 - Critical] accessed 04.03.2024.</ref>

<ref name="CVE_Task">NIST. [https://nvd.nist.gov/vuln/detail/CVE-2010-3888 CVE-2010-3888] accessed 03.03.2024.</ref>

<ref name="CVE_PrivEsc">NIST. [https://nvd.nist.gov/vuln/detail/CVE-2010-2743 CVE-2010-2743] accessed 03.03.2024.</ref>

<ref name="MS_PrivEsc">Microsoft. [https://learn.microsoft.com/en-us/security-updates/securitybulletins/2010/ms10-073 Microsoft Security Bulletin MS10-073 - Important] accessed 03.03.2024.</ref>

<ref name=MS_SMB>Microsoft. [https://docs.microsoft.com/en-us/security-updates/SecurityBulletins/2008/ms08-067 Microsoft Security Bulletin MS08-067 - Critical] accessed 02.03.2024.</ref>

<ref name="WinCC">NIST. [https://nvd.nist.gov/vuln/detail/CVE-2010-2772 CVE-2010-2772] accessed 04.03.2024.</ref>

</references>

[[Category:Documentation]]

Buffer Overflows

2024-01-08T22:38:39Z

DHomberg:

== Definition ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Functionality ==
A buffer overflow is essentially about how the system reacts to errors when executing software. If a program expects information from the user to be processed and a buffer of static size is created and the data that was entered is not checked for length, it would result in a buffer overflow. An example is shown below.

[[File:Example.jpg|center]][https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/]

In a buffer, data is stored temporarily while it is transferred from one location to another. If it is assumed that 8 bytes of data are allocated and the user enters data that would be more than 8 bytes, it would result in a buffer overflow because 2 bytes more than allowed were entered. The corresponding source code example is shown below.

#include <string.h>

using namesprace std;

int main()
{
char buffer [8];
cout << "Input data: ";
cin >> buffer;

return 0;
}

A variable of the data type ''char'' is used, which creates an array named ''buffer'' that can store 8 bytes of data.

== Practical Guide ==

In the following example, a piece of code is shown, which lets the user manipulate the output of the program enabled through a buffer vulnerability. Make sure, to have the GCC compiler installed on your Windows machine.

#include <string.h>

int main(int argc, char **argv)
{
char jayce[4]="Oum";
char herc[8]="Gillian";
strcpy(herc, "BrookFlora");
printf("%s\n", jayce);
return 0;
}

To run the program, open the command prompt in the directory of the source file. Compile the file with the following command:

$gcc example.c

Subsequently, execute the compiled file to display its output:

$./example.out
ra
$

The intention of the program is supposed to be the output of the string "BrookFlora". As the following illustration shows, two buffers are stored back to back in the stack. Since ten characters are copied into the buffer which is only eight bytes long, the operation causes an overflow into the first buffer.

|\0| m| u| O| |\0|\0| a| r|
|\0|\0| a| i| | o| l| F| k|
| l| l| i| G| | o| o| r| B|

The first diagram shows the initial stack organization. The second diagram shows the overflowed memory layout.

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of
the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Affected Programming Languages ==
Buffer overflows most commonly, if not exclusively, appear in the programming languages C and C++. The reason for that is that they are closely hardware-related programming languages, meaning that out-of-the-box, they do possess very little
in terms of safety mechanisms. Given said information, it would be even easier to exploit buffer overflows when using an assembler, as it is as hardware-related as it gets for programming languages. Whereas more abstract and ”heavyweight”
Programming languages such as C# and Java already come with lots of safeguards.

== Memory structure ==
In order to understand the principle of a buffer overflow-based attack, it is of great importance to look at the memory structure in detail. Binary data refers to files that can be executed and have different file formats. One of them is ''ELF'', which stands for ''Executable and Linking Format'' and is supported by UNIX. When such an executable binary file is loaded via the linker and the program is executed, the corresponding program code is loaded into the main memory and executed by the CPU. Different parts of the program, such as the program code, constants, and data, are stored in different memory segments. The memory structure is shown below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

=== Code ===
The code segment contains byte patterns that can be read and understood by the CPU. This memory segment is read-only, so it can be executed and used by users at the same time. Therefore, this segment is not the target of a buffer overflow, since attempting to write to it would result in a ''Memory Access Violation Error'', which would mean that the program will close.

=== Data and BSS ===
The Data and BSS segments store global variables that can be accessed by any function. Since variables should not contain executable code, these memory segments are not executable and should be pointed to with a command pointer, which would mean that the program will close.

=== Stack ===
The stack segment stores local variables that are used in a function and can be accessed via the function's instructions. The variables are located in a memory segment, which is the stack and corresponds to a last-in-first-out (LIFO) method. This means that only access to the top element is granted, or to move the element to another location to be able to advance to the next element. Each function call creates a new stack frame for its data, which is removed once the function returns, with automatic cleanup after function completion. The stack is at the end of the memory accessible to the program and grows downward, so the top element is actually the element with the lowest address but is still called the top element. The CPU has a special register that keeps track of only the top of the stack, that is, whether the stack is growing or shrinking, and this register is called the stack pointer (SP).

=== Heap ===
The heap segment is a memory area where it is possible to request and release memory during the execution of a program. If a programmer would need 1000 bytes of memory, that would be allocated immediately with the function ''malloc()'' and returned to the system with the function ''free()''. This can be useful in situations where it can't predict how much memory it will end up using, since it depends on what is put into the program. However, this requires manual allocation and deallocation by the programmer. Compared to the stack, the heap starts from the lowest address and grows upwards.

== Buffer overflow variations ==
Three different types of buffer overflows are distinguished: stack overflow, heap overflow, and integer overflow. The stack overflow and heap overflow, also referred to as stack-based buffer overflow and heap-based buffer overflow, differ in where the buffer overflow exploit takes place, namely the stack or the heap in a system's memory.

=== Stack Overflow ===
A stack overflow is a type of program error that can cause a computer's buffer to overflow with too much data. This means that if a program wants to write something to an address outside its data structure, it will not end up in the buffer but will overwrite the memory location, which would then lead to an overflow. Such an attack exploits the fact that when a function is called, the CPU stores the address of the next instruction on the stack, and the compiler uses the frame pointer, which is also stored on the stack and is used to remember the beginning of the current stack area. Each called function then creates its own block of memory in the stack area, gradually filling the stack with the highest address. If a buffer is allocated to the stack and the input is copied to the stack by the user without verification, the attacker can expand the size of the input to overwrite the data behind it. This then leads to the possibility of the frame pointer pointing back to a memory address, more often than not into the buffer itself, containing malicious code.

=== Heap Overflow ===
Heap overflows work on a similar principle as stack overflows and differ in that they maintain persistence between function calls, among other things. This would mean that, as long as the memory area is not used later, the overflow is also not noticed. This is possible with the function ''malloc()'', since the memory can be allocated and remains allocated until one executes the function ''free()''.

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== 32-bit vs. 64-bit systems ===
Additionally, buffer overflows vary based on the system used. Usually, this vulnerability is more common in 32-bit systems compared to 64-bit systems. This is because 64-bit systems can address more memory, making them less vulnerable to buffer overflows.

== Use After Free Bug ==
The Use After Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Countermeasures ==

=== Canaries ===
Canaries can be employed in order to recognize whether a buffer overflow has occurred. Therefore, in the simplest cases, canaries are specific values in memory that are located right after the thereby protected buffer. If their values are changed at any point, it is safe to assume that a buffer overflow occurred and countermeasures (e.g., termination) can be taken. Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

=== Data Execution Prevention (DEP) ===
Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Address Space Layout Randomization (ASLR) ===
Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular. ASLR randomizes the location of data, and code region layout randomization offers a plausible defensive strategy since code region layout randomization hinders code reuse in exploits and data randomization impedes the redirection of control flow by making it difficult to guess the location of injected code (partly paraphrased from the 2013 paper by Snow et al.).

=== Standard Template Library (STL) ===
Using the Standard Template Library (STL) can significantly lower risks, as STL provides safer alternatives for string handling and vectors.

=== C++ Compiler ===
Compiling C code with a C++ compiler can enhance safety due to the stricter functionality of C++ compilers.

=== High-level Programming Languages ===
Using higher-level languages such as Java and C#. They come with built-in features like bounds-checked arrays and native string types, which offer more security.

=== Fuzz Testing ===
Fuzz testing involves testing applications with random and unexpected inputs to find potential vulnerabilities, including buffer overflows.

=== Unsafe Functions ===
Replacing unsafe writing instructions and functions, such as the most commonly used "strcpy," "strcat," and "sprintf,” with their safer counterparts can drastically decrease the likelihood of exploits.

== Summary ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== Courses ==

* [https://moodle.fh-campuswien.ac.at/course/view.php?id=19428 Ausgewählte Kapitel der IT-Security ILV (2021, 2022)]

* [https://moodle.fh-campuswien.ac.at/course/view.php?id=29360 Ausgewählte Kapitel der IT-Security ILV (2023, 2024)]

== References ==

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory, Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory, Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]

Buffer Overflows

2024-01-08T22:32:47Z

DHomberg:

== Definition ==
Buffer overflow is a security vulnerability that should not be underestimated, as it has been the most common type of vulnerability in the last decade. This type of attack is an essential part of all security attacks, as buffer overflow vulnerabilities are widespread and easy to exploit. Especially in the field of cyber attacks, they are exploited by users to gain access to vulnerable servers and control them.

== Functionality ==
A buffer overflow is essentially about how the system reacts to errors when executing software. If a program expects information from the user to be processed and a buffer of static size is created and the data that was entered is not checked for length, it would result in a buffer overflow. An example is shown below.

[[File:Example.jpg|center]][https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/]

In a buffer, data is stored temporarily while it is transferred from one location to another. If it is assumed that 8 bytes of data are allocated and the user enters data that would be more than 8 bytes, it would result in a buffer overflow because 2 bytes more than allowed were entered. The corresponding source code example is shown below.

#include <string.h>

using namesprace std;

int main()
{
char buffer [8];
cout << "Input data: ";
cin >> buffer;

return 0;
}

A variable of the data type ''char'' is used, which creates an array named ''buffer'' that can store 8 bytes of data.

== Practical Guide ==

In the following example, a piece of code is shown, which lets the user manipulate the output of the program enabled through a buffer vulnerability. Make sure, to have the GCC compiler installed on your Windows machine.

#include <stdio.h>

int main(int argc, char **argv)
{
char jayce[4]="Oum";
char herc[8]="Gillian";
strcpy(herc, "BrookFlora");

printf("%s\n", jayce);

return 0;
}

To run the program, open the command prompt in the directory of the source file. Compile the file with the following command:

$gcc example.c

Subsequently, execute the compiled file to display its output:

$./example.out
ra
$

The intention of the program is supposed to be the output of the string "BrookFlora". As the following illustration shows, two buffers are stored back to back in the stack. Since ten characters are copied into the buffer which is only eight bytes long, the operation causes an overflow into the first buffer.

|\0| m| u| O| |\0|\0| a| r|
|\0|\0| a| i| | o| l| F| k|
| l| l| i| G| | o| o| r| B|

The first diagram shows the initial stack organization. The second diagram shows the overflowed memory layout.

== History ==
In the past, there were often a series of events executed with the help of buffer overflows. In 1980, the term Internet worm was a very well-known and sensitive topic because a worm was malicious software that reproduced itself and spread through network connections. It was called a Morris worm because on November 2, 1988, an event occurred that changed the way people thought about networks and about the Internet. On that day, tens of thousands of computers quickly and simultaneously became infected with a self-replicating computer program. Back then, computer science student Robert T. Morris created a computer worm that exploited an unsafe function, which at the time was very commonly used and distributed. Through the practical application of a buffer overflow, the computer worm spread itself around at an alarming rate and, going back, nearly shut down the entire internet. This situation resulted in Morris being the first person convicted under the Computer Fraud and Abuse Act, demonstrating further how dangerous buffer overflows can be. To this day, this attack is perhaps one of the most significant events in the history of computing. With buffer overflows, it was also possible to bypass various security measures. For example, buffer overflows could be used to remove software restrictions from firmware or to bypass copy protection. This was the case with the Android and iOS operating systems, where it was possible to remove various locks and modify the smartphone according to one's own wishes. For example, it was possible to install apps that were not available in the store elsewhere, change the boot animation, access hidden system files, remove manufacturer-specific apps, remove network locks, and much more. One keyword is "jailbreaking" for Apple devices and "rooting" for Android devices. On Nintendo's game console, a game called Pokemon Yellow could be changed from the inside by manipulating the program using shellcode.

While many of these events already reside in the past, buffer overflows do not. The exploit reoccurs frequently, so much so that in 2023 they still secured themselves a spot on the Common Weakness Enumeration/SANS list of
the Top 25 Most Dangerous Software Errors. Whether through the adaptation of the exploit's mechanism or simply by focusing on a new set of targets, buffer overflows stay relevant. That's why, when dealing with cybersecurity of any sort, there is no way past them.

== Affected Programming Languages ==
Buffer overflows most commonly, if not exclusively, appear in the programming languages C and C++. The reason for that is that they are closely hardware-related programming languages, meaning that out-of-the-box, they do possess very little
in terms of safety mechanisms. Given said information, it would be even easier to exploit buffer overflows when using an assembler, as it is as hardware-related as it gets for programming languages. Whereas more abstract and ”heavyweight”
Programming languages such as C# and Java already come with lots of safeguards.

== Memory structure ==
In order to understand the principle of a buffer overflow-based attack, it is of great importance to look at the memory structure in detail. Binary data refers to files that can be executed and have different file formats. One of them is ''ELF'', which stands for ''Executable and Linking Format'' and is supported by UNIX. When such an executable binary file is loaded via the linker and the program is executed, the corresponding program code is loaded into the main memory and executed by the CPU. Different parts of the program, such as the program code, constants, and data, are stored in different memory segments. The memory structure is shown below.

[[File:Memory structure.png|center]][https://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf#page=8]

=== Code ===
The code segment contains byte patterns that can be read and understood by the CPU. This memory segment is read-only, so it can be executed and used by users at the same time. Therefore, this segment is not the target of a buffer overflow, since attempting to write to it would result in a ''Memory Access Violation Error'', which would mean that the program will close.

=== Data and BSS ===
The Data and BSS segments store global variables that can be accessed by any function. Since variables should not contain executable code, these memory segments are not executable and should be pointed to with a command pointer, which would mean that the program will close.

=== Stack ===
The stack segment stores local variables that are used in a function and can be accessed via the function's instructions. The variables are located in a memory segment, which is the stack and corresponds to a last-in-first-out (LIFO) method. This means that only access to the top element is granted, or to move the element to another location to be able to advance to the next element. Each function call creates a new stack frame for its data, which is removed once the function returns, with automatic cleanup after function completion. The stack is at the end of the memory accessible to the program and grows downward, so the top element is actually the element with the lowest address but is still called the top element. The CPU has a special register that keeps track of only the top of the stack, that is, whether the stack is growing or shrinking, and this register is called the stack pointer (SP).

=== Heap ===
The heap segment is a memory area where it is possible to request and release memory during the execution of a program. If a programmer would need 1000 bytes of memory, that would be allocated immediately with the function ''malloc()'' and returned to the system with the function ''free()''. This can be useful in situations where it can't predict how much memory it will end up using, since it depends on what is put into the program. However, this requires manual allocation and deallocation by the programmer. Compared to the stack, the heap starts from the lowest address and grows upwards.

== Buffer overflow variations ==
Three different types of buffer overflows are distinguished: stack overflow, heap overflow, and integer overflow. The stack overflow and heap overflow, also referred to as stack-based buffer overflow and heap-based buffer overflow, differ in where the buffer overflow exploit takes place, namely the stack or the heap in a system's memory.

=== Stack Overflow ===
A stack overflow is a type of program error that can cause a computer's buffer to overflow with too much data. This means that if a program wants to write something to an address outside its data structure, it will not end up in the buffer but will overwrite the memory location, which would then lead to an overflow. Such an attack exploits the fact that when a function is called, the CPU stores the address of the next instruction on the stack, and the compiler uses the frame pointer, which is also stored on the stack and is used to remember the beginning of the current stack area. Each called function then creates its own block of memory in the stack area, gradually filling the stack with the highest address. If a buffer is allocated to the stack and the input is copied to the stack by the user without verification, the attacker can expand the size of the input to overwrite the data behind it. This then leads to the possibility of the frame pointer pointing back to a memory address, more often than not into the buffer itself, containing malicious code.

=== Heap Overflow ===
Heap overflows work on a similar principle as stack overflows and differ in that they maintain persistence between function calls, among other things. This would mean that, as long as the memory area is not used later, the overflow is also not noticed. This is possible with the function ''malloc()'', since the memory can be allocated and remains allocated until one executes the function ''free()''.

=== Integer Overflow ===
Integer overflows occur when an arithmetic operation attempts to generate a value that lies outside a range that can be represented with a specified number of bits. The most common result of an overflow is that the least significant representable bits of the result are stored. An overflow condition can lead to results that are equivalent to unintended behavior. In particular, if the possibility is not expected, an overflow can affect the reliability and safety of a program. A code example is shown below.

unsigned char a = 255;
unsigned char b = 2;
unsigned char Result = a + b;

The data type unsigned char is used, which comprises 8 bits, and the value range is from 0 to 255. For the variable "a," the value 255 is assigned, and for the variable "b," the value 2 is assigned. If an arithmetic operation is performed, we would get a result that requires more bits than are present to represent. The corresponding dual calculation is shown below.

11111111 (a)
+ 00000010 (b)
----------
100000001 (Result)

The front one, the ninth bit, is no longer contained in the 8 bits of the data type ''unsigned char''. If only the last 8 bits were considered, the result would be 1 and not 257.

=== 32-bit vs. 64-bit systems ===
Additionally, buffer overflows vary based on the system used. Usually, this vulnerability is more common in 32-bit systems compared to 64-bit systems. This is because 64-bit systems can address more memory, making them less vulnerable to buffer overflows.

== Use After Free Bug ==
The Use After Free bug is a vulnerability where memory should not be used in this way while the program is running. If a program clears memory, but the pointer to that memory is not yet cleared, an attacker can use this bug to gain access and control.

== Countermeasures ==

=== Canaries ===
Canaries can be employed in order to recognize whether a buffer overflow has occurred. Therefore, in the simplest cases, canaries are specific values in memory that are located right after the thereby protected buffer. If their values are changed at any point, it is safe to assume that a buffer overflow occurred and countermeasures (e.g., termination) can be taken. Typical types of canaries, which are supported by security hardening technologies like ProPolice or Stackguard (GCC), are terminator canaries, random canaries, and random XOR canaries.

=== Data Execution Prevention (DEP) ===
Data Execution Prevention (DEP) is a security feature originally developed by MicrosoftR© for Windows XP SP2. There are two basic variants: hardware-based DEP and software-based DEP. If supported by the CPU as well as the process, hardware DEP will be employed; otherwise, DEP has to be carried out in software, which is part of the Windows operating system. The basic functionality of DEP is to prevent applications from executing code in a non-executable area of memory.

=== Address Space Layout Randomization (ASLR) ===
Since code reuse attacks (e.g., ROP attacks) require the memory addresses of gadgets to be known to an attacker, techniques to randomize their entry points have become increasingly popular. ASLR randomizes the location of data, and code region layout randomization offers a plausible defensive strategy since code region layout randomization hinders code reuse in exploits and data randomization impedes the redirection of control flow by making it difficult to guess the location of injected code (partly paraphrased from the 2013 paper by Snow et al.).

=== Standard Template Library (STL) ===
Using the Standard Template Library (STL) can significantly lower risks, as STL provides safer alternatives for string handling and vectors.

=== C++ Compiler ===
Compiling C code with a C++ compiler can enhance safety due to the stricter functionality of C++ compilers.

=== High-level Programming Languages ===
Using higher-level languages such as Java and C#. They come with built-in features like bounds-checked arrays and native string types, which offer more security.

=== Fuzz Testing ===
Fuzz testing involves testing applications with random and unexpected inputs to find potential vulnerabilities, including buffer overflows.

=== Unsafe Functions ===
Replacing unsafe writing instructions and functions, such as the most commonly used "strcpy," "strcat," and "sprintf,” with their safer counterparts can drastically decrease the likelihood of exploits.

== Summary ==
Since the rise of C in the early 1970s, buffer overflows have become a serious security vulnerability. Even though high-level programming languages are typically not affected, the number of vulnerable systems is actually rising. At the same time, a wide array of countermeasures are also increasingly adopted and applied. Features like executable space protection (e.g., data execution prevention under Windows) have already been deployed since the mid-2000s, and on the compiler side, technologies like Stackguard support several detection and prevention mechanisms (e.g., different types of canaries). Furthermore, almost every widely used operation system supports Address Space Layout Randomization in order to minimize the attack surface for buffer overflow attacks. For example, at the beginning of 2020, most of the bigger operating systems (Linux, Windows, macOS, iOS, Android, Solaris, OpenBSD, etc.) will offer support for ASLR.

Another key point is the expansion of the Internet of Things (IoT). These widely distributed networks of hardware endpoints have deemed themselves the perfect target for buffer overflow attacks. This stems from the fact that IoT applications mostly utilize low-level, closely hardware-related languages such as C and C++, both of which are almost exclusively for buffer overflows.

== Courses ==

* [https://moodle.fh-campuswien.ac.at/course/view.php?id=19428 Ausgewählte Kapitel der IT-Security ILV (2021, 2022)]

* [https://moodle.fh-campuswien.ac.at/course/view.php?id=29360 Ausgewählte Kapitel der IT-Security ILV (2023, 2024)]

== References ==

* [http://phrack.org/issues/49/14.html Smashing the stack for fun and profit (1996, Aleph One)]
* [http://phrack.org/issues/60/10.html#article Basic Integer Overflows (2002, Blexim)]
* [https://doi.org/10.1109/SP.2013.45 Just-In-Time Code Reuse: On the Effectiveness of Fine-Grained Address Space Layout Randomization (2013, Snow et al.)]
* [http://www.cs.ucf.edu/~czou/CDA6938-06/Buffer%20Overflows.pdf Buffer Overflow for Dummies (2002, Josef Nelißen)]
* [https://www.hackingarticles.in/a-beginners-guide-to-buffer-overflow/ A Beginner’s Guide to Buffer Overflow (2021, Raj Chandel)]
* [https://repository.unikom.ac.id/56387/1/24_Deadly_Sin.pdf 24 Deadly Sins of Software Security (2009, Michael Howard, David LeBlanc, and John Viega)]
* [https://scholar.google.com/scholar_case?case=551386241451639668 United States v. Morris (1991, U.S. Dept. of Justice)]
* [https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html 2023 CWE Top 25 Most Dangerous Software Weaknesses (2023, CWE)]
* [https://computersciencewiki.org/index.php?title=Stack_memory, Stack memory (2023, Bill MacKenty)]
* [https://computersciencewiki.org/index.php?title=Heap_memory, Heap memory (2023, Bill MacKenty)]

[[Category:Basic]]