Welcome to Volume 3, Issue 16 of The Internet Security Conference Newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.
TISC is about sharing clue. So is the newsletter. We promise to provide something useful each issue. If we don't, flame me.
Enjoy, and be safe,
Dave
In this issue, Stefan Hoelzner shows us that if you don't exercise care and caution when assigning access rights to certain system functions, you can easily turn a feature into a backdoor. To emphasize his point, Stefan describes how an entire network was hacked by exploiting SAP R/3 system functions. Stefan assures us that this was a real scenario. And it pointedly demonstrates the dangers of assigning access rights that are too liberal in complex modern computing environments.
Happy reading...
Stefan Hoelzner, KPMG Germany
A SAP system administrator's daily routine work: System maintenance. Windows NT login screen: Username, password. Login failed. Again: Username, password. Login failed. What seems to be a simple data entry error at first sight turns out to be something completely different: the system has just been hacked.
Plenty of books and columns - even here - have been written about the risks and threats that make one a target for professional hackers. But still a great deal of all security violations originate from "the inside" - a fact that is frequently ignored.
One of an enterprise's most crucial decisions is to determine the appropriate user access rights to data. And this surely is one of the critical weaknesses in most software implementation projects. "Assigning access rights should always be limited to an actually needed minimum". That principle has penetrated into almost every administrator's and CIO's mind, but often is not put into practice. The careless approach usually used can be very devastating when assigning access rights to certain system functionalities that may be classified both as a "feature" or as a "legalized backdoor" depending on the point of view.
This column documents the hacking of an entire computer network by exploiting SAP R/3 system functions. This is a real scenario. It is not fictitious. And it demonstrates the dangers of assigning access rights that are too liberal in complex modern computing environments.
Assigning access rights the hard way
SAP R/3 offers very sophisticated user authorization features. Despite this, many system administrators feel like Sisyphus when trying to manage authorization rights, because
It is not always the (in)famous profile "SAP_ALL" which causes severe security holes in a SAP system. In our case, there was actually just one authorization object that was assigned unintentionally to some user profiles: the object S_RZL_ADM with the field value "*" (a wildcard meaning "all" and which guarantees full access to all data protected by this specific object). Perhaps this mistake happened just because the system administrator did not know that RZL stands for "Rechenzentrumsleitstand" in German, which means computing center control. This administrative control, combined with the transaction authorizations SM49 and SM69, authorized these users to perform and create "External Operating System Commands".
The following sequence of events used during this exploit was reconstructed using log files and intense analysis in testing systems. The hacker used a Windows NT Workstation and a SAP R/3 account; his target was the SAP application server running Windows NT Server. This attack would have been also possible and just slightly different if the hacker had been targeting a UNIX-based system.
Chronology of a hack
A SAP R/3 system provides predefined commands that can be sent to the application server's operating system ("external operating system commands"). These commands can be displayed by using the transaction SM49 (see Figure 1) and support functions like DISPLAY_DIAGLOG (displays the content of text files) and LIST_DB2DUMP (lists the content of directories). Obviously, these command names describe the functions the commands were designed to carry out. However, command functionality is not actually limited to these purposes. It is possible to supply additional parameters to further specify the desired action.
Taking a closer look at the column "OS command" reveals that the assigned operating system commands cmd /c type and cmd /c dir hand over a command to the Windows NT shell cmd.exe. The parameter /c executes the shell commands that follow. For example, the complete syntax for displaying the file C:\boot.ini is therefore cmd /c type C:\boot.ini.
Given this, you may suppose that executing an arbitrary shell command may not be that difficult. In fact, by using the transaction SM69, external operating system commands can be defined specifying any OS command available on the target machine. These commands can even be aimed at remote servers. First of all, a new command has to be created (let's name it ZCMD) and then the OS command cmd /c has to be assigned to it (Figure 2). Saving this command twice(!) saves the newly created command. It is now available for execution using the transaction SM49. Our ZCMD now offers the possibility to execute any Windows NT shell command by typing the shell command into the field "parameter". But be patient: only one command line can be executed at a time. Commands requiring interactive user input, e.g. the command fdisk, or even a graphical user interface, are not a good choice because they will not be processed correctly. But network mapping, using tools like ping, finger or tracert, may be good starting point for any hacker, as well as displaying the current routing table (route print). Unfortunately, these shell commands are included in every Windows NT standard installation. A sample output is shown in Figure 3.
In the case reconstructed here, the hacker made use of the command net.exe. Even if you are not familiar with all the options net offers, just ask the system! cmd /c net /? shows all available parameters and options (Figure 4).
The actual point of attack was the NetBIOS-Protocol and Windows "File and Print Sharing" respectively. To avoid as many authentication procedures as possible, the hacker used the command net user hacker /add to create the NetBIOS user "hacker" on the target machine ("hacker" has to be identical with his Windows NT logon username). The next step was to type net share hack1:=C:\ /unlimited, a command that created the share hack1 (the share name may be chosen arbitrarily - see Figure 3). By simply using the Windows Explorer ("map network drive"), this newly created share can be mapped into the local directory structure without any user authentication (see Figure 5). All you need to know is the IP address (or NetBIOS name) of the target machine. If not already known, it can be easily displayed via cmd /c ipconfig /all.
In almost every Windows NT installation the file sam._ resides in the subdirectory C:\WinNT\repair. This file is a copy of the user database and it contains, among others, the user names and the encrypted passwords. If a hacker gets hold of this file, you are doomed: even for talentless attackers, it's only a matter of time and freely available password cracking tools before sensitive accounts and passwords are revealed. But accessing this file still requires one additional step.
Ordinary users are not allowed to access the file sam._, so simply transferring the file to the local computer usually will fail. But SAP R/3 actually helps the attacker in this situation because it accesses operating system resources with administrative privileges (e.g. the user sapr3): copying any file within the directory structure will succeed using the "SAP command line" cmd /c copy c:\winnt\repair\sam._ c:\winnt\repair\sam.txt
Read access to this file is usually less restricted, so copy operations by the sapr3 user are often allowed by file access rules. A hacker exploiting the "SAP command line" is then able to transfer the file sam.txt to his local computer.
The following tools are a part of every hacker's basic equipment:
In the actual case described here, john the ripper needed exactly 7 hours 37 minutes (unattended) to "brute force" the admin password.
The attacker's footprints were easily erased using the administrative privileges gained during the attack. The commands net user hacker /del and net share hack1 /delete deleted the NetBIOS user account and share created by the hacker. Editing the NT event log file to eliminate evidence of the hacker activity is a minor challenge for a professional.
An additional administrative (and policy) vulnerability made it quite easy for the hacker to penetrate further into the network: the same password was used for several "Administrator" accounts, the most notable of these being the Administrator account of the Primary Domain Controller (PDC)! Gaining complete control of a network once this critical account is known is accomplished in a matter of minutes.
What about attacks based on fraud?
Attacking a system does not always have to be so extensive and - probably - easy to detect. The ability to execute external operating system commands offers manifold ways to manipulate a system. It is possible to change date and time of the application server to (nearly) arbitrary values, e.g. using the commands cmd /c time 17:00:00 and cmd /c date 12/21/99 (Figure 6). Every activity executed thereafter will be logged to the database with the altered time and date. It may be possible to enter accounting transactions with false dates, post to invalid accounting periods or to disguise authorization changes to user accounts trying to trick security or financial auditors. The ways of abusing this "functionality" are numerous
Counter measures
In complex software systems like SAP R/3, every user should be assigned only those access rights he/she absolutely needs to be productive. This is particularly true when dealing with basic/system functions that may permit the execution of tasks that are most critical to system security. The decision to assign a specific value to an authorization object for a given user should always take into account that such objects may enable more than the intended function, and that such consequences are not clearly visible from the object's name. To understand the risk, the table USOBT should always be consulted. This table lists all transactions that require the authorization object in question. But you should not always rely solely on this table, because it may be incomplete, especially when dealing with large customized SAP R/3 deployments.
Many basic security risks can be avoided by installing the system according to the "SAP Security Guide" issued by SAP AG [7]. But, in practice, these recommendations are often ignored, resulting in vulnerable operating systems and network topology. In this case study, a more stringent password policy, the installation of firewalls and a well-reasoned network topology with secured operating systems would have minimized the outlined risks.
Conclusion
The combination of vulnerabilities - or even "features" - on different platforms may result in systems that are open to hackers. Sometimes, a security flaw in a subordinate system may compromise the security of an entire networking environment. Traditional security analysis has largely been focused on individual systems: the firewall, the PDC, the fileserver or the ERP system. Securing each of these components remains necessary and essential. But one must also consider the aspects of increasingly interlocked applications by using more complex analysis techniques.
Finally, a computer system can only be as secure as the organizational structures and guiding principles supporting it. Without a security policy that organizes administrative proceedings, e.g. the choice of good passwords, the definition of an authorization concept, or the periodical analysis of server log files, any technical solution promising "real security" will fail.
[1] Computer Security Institute (http://www.gocsi.com)
[2] Georg Hohnhorst, "Maschinelle Tools für sichere SAP R/3-Prozesse", IT-SICHERHEIT 2/2000
(German only, but you can contact the author of this article for further information)
[3] NSFocus (http://www.nsfocus.com/english.php)
[4] Nomad Mobile Research Centre (http://www.nmrc.org/files/snt/index.html)
[5] L0pht Heavy Industries (http://www.l0pht.com/)
[6] The Openwall Project (http://www.openwall.com/)
[7] SAP Security Guide, Version 3.0
SAP R/3 is a registered trademark of SAP AG, Walldorf,
Germany.
Windows NT is a registered trademark of Microsoft Corp., Redmond,
U.S.
© 2001 - 2006 Core Competence & Mactivity, Inc.
