The Shellcode Generation
Tweet |
The Shellcode Generation Attackers carry out many network security com-promises using exploitation programs, or ex-ploits, which take advantage of bugs in softwarerunning on vulnerable systems. These programsare often the only remaining evidence of a security compromise;by analyzing them, we can assessthe incident’s impact and the at-tackers’ skills and intent. We canbuild an entire taxonomy of attacksby understanding these programs’technical capabilities and their con-nection to those who develop anduse them.For the past decade, exploit toolshave signaled the evolution of acommunity of adversaries compris-ing numerous inexperienced andunskilled “ankle biters”—commonly referred to as scriptkiddies—and a few experienced,technically savvy attackers. Exploitprograms are telltale signs of attack-ers’ sophistication: if studied metic-ulously, they can provide insightinto current and future trends.
Shellcode The next evolution in exploit pay-loads, known as the shellcode, be-came so prevalent by the mid ’90sthat today the term is almost synony-mous for exploit payload.The fundamental concept is that,upon seizing control of the vulnera-ble program by modifying its execu-tion flow, the exploit immediatelyspawns a command interpreter—ashell, in Unix parlance—that lets theattacker interactively enter com-mands to be executed on the vulner-able system and read back the out-put. To accomplish this, the payloadmust have the appropriate program-ming instructions, or code, to runthe command interpreter; hence,the name shellcode.AlephOne’s classic paper provideda clear, and very didactic, explanationof how to develop such exploits.Once the payload spawns a shell, theattacker can issue any other com-mands for it to interpret and execute.According to the author, several pub-licly available exploits were alreadyusing shellcode payloads at the time ofpublication (November 1996).Shellcode’s widespread adop-tion as the payload of choice signalsan advancement in exploit qualityand sophistication. Using shellcodepayloads, the attacker avoids theneed to alter the compromised sys-tem’s file system in any way toachieve his or her goals, thus reduc-ing the chances of being detectedby the system’s administrator. However, writing the propershellcode for any given operatingsystem and making it work within aparticular exploit requires the ex-ploit writer to acquire and developbasic assembly and C programmingskills as well as an understanding ofthe target operating system’s founda-tions and APIs for spawning newprocesses and threads. The few fullyfunctional examples that becamepublicly available for several Unixoperating systems have since beenused in hundreds of exploits over thepast decade.Once developers solved the tech-nicalities of how to spawn a com-mand interpreter in an efficient, op-erating-system version-independentmanner, exploit writers quicklyadopted the shellcode paradigm forWindows operating system vulnera-bilities as well. Today the term ‘shellcode’ is almost synonymous for exploit payload.
Network-aware shellcode The simplest network-awareshellcode spawns a command inter-preter that functions as a typical net-work server program (or daemon, inUnix parlance). The shellcode listensfor incoming connections on an at-tacker-specified network port andprotocol (usually TCP, though othertransport protocols are also usable);after receiving a connection from aremote system, the shellcode spawnsa shell that redirects its input and oput to the remote system from whichthe network connection was re-ceived. Presumably, the attacker willbe the one connecting from the re-mote system and served by a fullyfunctional command interpreter.This is typically known as a bindshellcode, or bindshell, because it usesthe Unix sockets library’s bindfunction (www.ecst.csuchico.edu/~beej/guide/net/html/syscalls.html#bind) to achieve its goal. The presence of a firewall or anyfiltering device in the topologicalpath between the attacker and thecompromised system can thwart anattack. Even if the exploit works andthe bindshell payload successfullycreates a shell service on the targetsystem, a firewall that blocks incom-ing connections to the port the at-tacker chooses will deny shell accessto the system. To address this prob-lem, attackers often use a variation ofthe bindshell, called the reverse shell. The reverse shell successfullycopes with firewalls and filtering de-vices that deny incoming connec-tions to ports where no legitimateservices are supposed to run on theprotected systems. It does so by ini-tiating the connection to the at-tacker from the compromised sys-tem. That is, the reverse shell spawnsa shell and establishes an outgoingconnection from the compromisedsystem to the attacker’s system, andthe shellcode transfers control of thecommand interpreter to the remotesystem once the connection is estab-lished. However, imposing strictcode is the findsocketor reuse-connectionshellcode, which identifiesthe network connection that wasused to trigger and exploit the secu-rity bug and spawns a shell that usesthe same connection for interactivecommunication with the attacker.This clever improvement of shell-code seeks to cope with networktopology and firewall policy restric-tions by allowing the attacker to use acommunications channel known towork for exploiting the vulnerabilityto run the shellcode.Multiple versions and variationsof these basic network-aware shell-codes are publicly available for com-mon operating systems, and the vastmajority of exploits for recent vul-nerabilities use one or more of thesenetwork-aware shellcodes. Notably,the devastating worms of 2004 andprevious years used network-awareshellcode that downloads and runsmultipurpose agent programs fromremote Internet systems while main-taining the basic spawn-shell func-tionality available on some networkport of the exploit writer’schoosing.Note that all variations of the net-work-aware shellcode rely on and as-sume that the payload has enoughaccess privileges to the file system ofthe compromised system to load andexecute a command interpreter orany other program of the exploit de-veloper’s choice. |
|
The Shellcode Generation
Attackers carry out many network security com-promises using exploitation programs, or ex-ploits, which take advantage of bugs in softwarerunning on vulnerable systems. These programsare often the only remaining evidence of a security compromise;by analyzing them, we can assessthe incident’s impact and the at-tackers’ skills and intent. We canbuild an entire taxonomy of attacksby understanding these programs’technical capabilities and their con-nection to those who develop anduse them.For the past decade, exploit toolshave signaled the evolution of acommunity of adversaries compris-ing numerous inexperienced andunskilled “ankle biters”—commonly referred to as scriptkiddies—and a few experienced,technically savvy attackers. Exploitprograms are telltale signs of attack-ers’ sophistication: if studied metic-ulously, they can provide insightinto current and future trends.
Shellcode injections |
Shellcode
The next evolution in exploit pay-loads, known as the shellcode, be-came so prevalent by the mid ’90sthat today the term is almost synony-mous for exploit payload.The fundamental concept is that,upon seizing control of the vulnera-ble program by modifying its execu-tion flow, the exploit immediatelyspawns a command interpreter—ashell, in Unix parlance—that lets theattacker interactively enter com-mands to be executed on the vulner-able system and read back the out-put. To accomplish this, the payloadmust have the appropriate program-ming instructions, or code, to runthe command interpreter; hence,the name shellcode.AlephOne’s classic paper provideda clear, and very didactic, explanationof how to develop such exploits.Once the payload spawns a shell, theattacker can issue any other com-mands for it to interpret and execute.According to the author, several pub-licly available exploits were alreadyusing shellcode payloads at the time ofpublication (November 1996).Shellcode’s widespread adop-tion as the payload of choice signalsan advancement in exploit qualityand sophistication. Using shellcodepayloads, the attacker avoids theneed to alter the compromised sys-tem’s file system in any way toachieve his or her goals, thus reduc-ing the chances of being detectedby the system’s administrator. However, writing the propershellcode for any given operatingsystem and making it work within aparticular exploit requires the ex-ploit writer to acquire and developbasic assembly and C programmingskills as well as an understanding ofthe target operating system’s founda-tions and APIs for spawning newprocesses and threads. The few fullyfunctional examples that becamepublicly available for several Unixoperating systems have since beenused in hundreds of exploits over thepast decade.Once developers solved the tech-nicalities of how to spawn a com-mand interpreter in an efficient, op-erating-system version-independentmanner, exploit writers quicklyadopted the shellcode paradigm forWindows operating system vulnera-bilities as well.
Today the term ‘shellcode’ is almost synonymous for exploit payload.
Shellcode is most suitable for ex-ploits in which the attacker alreadyhas interactive access to the vulnera-ble system and just needs elevatedprivileges. By taking advantage ofsoftware flaws in programs runningon the system on which the attackerhas access to the shellcode, exploitwriters avoid the complexity ofmanaging communications betweenthe spawn shell and any remote sys-tem the attacker might launch.To gain access to the system,however, the attacker needs somesort of tool; exploit writers thereforeadapted and further developed theshellcode payload to provide thesame capabilities to an attack on a re-mote system. The shellcode thus be-comes aware of the network topolo-gies in which the vulnerable systemand attacker are present.Linux shellcode Generation
Network-aware shellcode
The simplest network-awareshellcode spawns a command inter-preter that functions as a typical net-work server program (or daemon, inUnix parlance). The shellcode listensfor incoming connections on an at-tacker-specified network port andprotocol (usually TCP, though othertransport protocols are also usable);after receiving a connection from aremote system, the shellcode spawnsa shell that redirects its input and oput to the remote system from whichthe network connection was re-ceived. Presumably, the attacker willbe the one connecting from the re-mote system and served by a fullyfunctional command interpreter.This is typically known as a bindshellcode, or bindshell, because it usesthe Unix sockets library’s bindfunction (www.ecst.csuchico.edu/~beej/guide/net/html/syscalls.html#bind) to achieve its goal.
The presence of a firewall or anyfiltering device in the topologicalpath between the attacker and thecompromised system can thwart anattack. Even if the exploit works andthe bindshell payload successfullycreates a shell service on the targetsystem, a firewall that blocks incom-ing connections to the port the at-tacker chooses will deny shell accessto the system. To address this prob-lem, attackers often use a variation ofthe bindshell, called the reverse shell. The reverse shell successfullycopes with firewalls and filtering de-vices that deny incoming connec-tions to ports where no legitimateservices are supposed to run on theprotected systems. It does so by ini-tiating the connection to the at-tacker from the compromised sys-tem. That is, the reverse shell spawnsa shell and establishes an outgoingconnection from the compromisedsystem to the attacker’s system, andthe shellcode transfers control of thecommand interpreter to the remotesystem once the connection is estab-lished. However, imposing strictcode is the findsocketor reuse-connectionshellcode, which identifiesthe network connection that wasused to trigger and exploit the secu-rity bug and spawns a shell that usesthe same connection for interactivecommunication with the attacker.This clever improvement of shell-code seeks to cope with networktopology and firewall policy restric-tions by allowing the attacker to use acommunications channel known towork for exploiting the vulnerabilityto run the shellcode.Multiple versions and variationsof these basic network-aware shell-codes are publicly available for com-mon operating systems, and the vastmajority of exploits for recent vul-nerabilities use one or more of thesenetwork-aware shellcodes. Notably,the devastating worms of 2004 andprevious years used network-awareshellcode that downloads and runsmultipurpose agent programs fromremote Internet systems while main-taining the basic spawn-shell func-tionality available on some networkport of the exploit writer’schoosing.Note that all variations of the net-work-aware shellcode rely on and as-sume that the payload has enoughaccess privileges to the file system ofthe compromised system to load andexecute a command interpreter orany other program of the exploit de-veloper’s choice.
0 Comments:
Post a Comment