After Windows NT was released, it took virus writers five years to learn how to infect it. Windows NT 3.1 and the Win32 API were released in late 1993, but it wasn't until August 1998 that W32.Cabanas became the first NT virus by capturing coveted kernel mode access. .NET and some of Microsoft's other initiatives have not been as lucky. The purpose of this article is to discuss antivirus (AV) concerns with .NET and Microsoft Windows XP.
.NET Review
.NET was officially announced by Microsoft in July 2000 at a Microsoft Professional Development Conference. Since then, what .NET has meant and the products involved have changed (and been renamed). .NET is an idea and a programming platform. The basic concept is an evolving extension of Microsoft's Object Linking Embedding (OLE) introduced back in the early days of Windows 3.0. OLE allows you to copy objects and data created in one application, like a spreadsheet graph, to other applications. OLE evolved into ActiveX objects, which are executables you can download and run within an Internet browser.
.NET takes it two steps further by allowing the entire application to be hosted elsewhere (potentially allowing your environment to follow you, no matter where you go) and allowing different distributed software parts to make up one application. For example, your Windows desktop settings, your applications, and your data may be available to you where ever you compute. Running by an Internet kiosk in an airport? Just login and access your desktop and your data. Different applications will co-exist together, over the web, to bring you that integrated environment. One vendor will handle the login and authentication, another will store your data, and each of your applications will be made up of specifically customized components. I'll take two thesauruses, a math equation editor, and a French translation dictionary please. Hold the autocorrect.
All of this magic happens because of new distributed .NET programming platform and a horde of new Microsoft developer tools and languages: C# (C Sharp), Visual J#, VB.NET, Visual Studio .NET, ASP.NET, increased reliance on XML, and a host of other new programming tools and platforms.
The .NET execution framework reminds many people of Java's model. In order for a Java applet to run, it must be executed in a Java Virtual Machine (JVM) environment. .NET executables (regular Windows 32-bit Portable Executables) run on top of a similar environment called the Common Language Runtime or CLR. This is what you are installing when you install the Microsoft .NET Framework component. The CLR runtime engine performs security checks, does type checking, checks memory pointers, loads other component dependencies, and Just-In-Time (JIT) compiles the platform-independent source code into executable code. And further, there are intermediate source code representations (called Microsoft Intermediate Language or MSIL), class files, class loaders, and separate treatment between trusted and untrusted code. Untrusted code is sandboxed and prevented from accessing or risking system resources. This should sound a whole lot like Java to anyone.
I bring up this comparison because .NET is more complex than Java, and complexity doesn't mix well with security. I often hear that Java is very secure because it has only had one widespread in-the-wild exploit. I love Java and the people who designed it did so with security as top priority. But the truth is that Java has had dozens of security holes patched since its release. Just because the white-hatters are the ones finding them doesn't make it a secure platform. Many Java exploits have been found by breaking assumptions between its mesh of interoperating components. See, in order for Java security to work, all the components must work 100% of the time. If one fails, they all fail. Because .NET's execution model is roughly similar, it isn't a hard stretch to believe that many holes will be found in .NET.
Web Services
Web services are the reason for all the complexity. Web services are XML applications, interfaces, and data, designed to be shared across multiple platforms around the Internet. A web service might be a single application hosted by an Application Service Provider (ASP) or it could be a combination of several different vendor's web services making up one application experience for the user. For example, consider a typical online transaction such as buying a pair of jeans. You may use one web service to authenticate your login to the manufacturer's web site, another to help get you the perfect fit, and another to determine delivery details and payments.
Microsoft's Passport was the first example of a web service. Passport allows you to use a single login name and password for all web sites that support Passport authentication. It has tens of millions of users and it has had a series of security issues over the years. In one such instance in May of this year, it was discovered that a remote attacker could send a rather trivial, malicious URL to hotmail.com, be able to change anyone's password and take over the passport account. Maliciously altered Passport accounts can be used to buy goods online and to view confidential data.
The idea that a single, widespread web service with a vulnerability that can immediately expose tens of millions of people to new threats has security experts paying attention. Today's conventional worms and viruses are infecting millions of computers in ten minutes. But a crafty web service worm could potentially conduct millions of falsified commercial transactions in a matter of minutes, something a MS-Office macro virus can't hope to do.
The complexity and popular use of .NET's execution model worries security experts. The widespread sharing of applications, code, and data around the Internet is bound to culminate in interesting future exploits. Lucky for us so far, .NET exploits have been limited to some 'growing pain' problems with Microsoft Passport and a few worms and viruses.
.NET Viruses
There are already at least three .NET worms and viruses: Donut, Serot and Sharpei. Donut, discovered on January 9, 2002, was the first .NET virus. Sent only to researchers as concept malware, the buggy Donut attempts to infect all the .EXE files in the current folder and up to 20 folders above it. It contains a never-executed payload display message and only a small amount of MSIL code. It is mostly normal 32-bit assembly language and the .NET files it infects are turned into regular looking PE files. Donut was the first .NET virus, but it only had a short lead on the others.
Donut was quickly followed up by the Serot, worm which arrives as an impersonated email from support@microsoft.com. It infects all .NET (MSIL) .EXE files on drive C: and will attempt to send itself to all email addresses in the Windows Address Book and those it finds in the Internet Explorer cache folder. Like the virus that followed it, Serot contains a VBS file that does the mass mailing effort. This appears to be easier to do in a script language for the crackers than in MSIL. Serot attempts to terminate antivirus processes on infected PCs and contains a plug-in architecture similar to the one successfully used in the Hybris worm.
Then the Sharpei virus was discovered on February 26, 2002. It arrives in email pretending to be a Microsoft patch, MS02-010.EXE. Written in C#, it drops a Sharp.VBS file that sends itself to all contacts in the Microsoft Outlook address book. After messages are sent, the evidence is deleted from the Sent Items folder in Outlook.
Both the Sharpei and Donut viruses are direct action infectors, meaning they execute and do their damage upon running, and then exit until the next execution. All three "concept" programs have their problems and are unlikely to spread far. Antivirus researchers expect the future to bring memory-resident .NET viruses.
Note: Peter Szor, with Symantec, did detailed write-ups on Donut and Sharpei for the Virus Bulletin publication. You can visit www.peterszor.com or www.virusbtn.com for detailed reading on .NET infections.
Because all three .NET malware programs are very buggy and require .NET to be installed, none spread very far outside research laboratories. But a crucial point, that malware writers are ready to exploit the .NET framework, has been proven. It won't be a five-year wait this time. Meanwhile, new features in other Microsoft platforms have raised concern among AV experts.
Windows XP Concerns
Windows XP has an improved model of NT's HAL, kernel, and user mode processes. Overall, with XP and Server 2003, Microsoft has increased the stability and security of their operating systems. True, Internet Explorer and Outlook continue to be the weak points in Microsoft's Trustworthy Computing initiative, but their core operating systems are becoming more secure out of the box. At the same time, Microsoft cannot resist (and consumers demand) new features, and XP has plenty of those. Some have been exploited, most haven't...yet. The next part of this article will briefly discuss the new feature XP sets that concern computer security analysts.
Windows Media Player
It used to be that you only had to worry about malicious executable content. Data was data was data, and it could not be launched as an attack. Times change and data content is often exploited in today's multimedia world. The content itself can be used maliciously, in a buffer overflow or through embedded script languages. Another common ruse is for the file to have a header claiming it is one type of file, but instead it contains something completely different, bypassing security-checking mechanisms. The multimedia program itself is often used for the attack. If the interface allows scripting or "skin" updating, rogue coders can instruct the program to do things that would otherwise be constrained by one of Internet Explorer's security zones.
Microsoft's Windows Media Player is installed by default on every version of Windows. The original release of XP came with version 8.0, although anyone can upgrade to version 9 for free. Several holes have been found with the Windows Media Player over the last few years, and Microsoft has patched them when reported. The older versions of Windows Media Player have more security holes than the newer versions, but many people are hesitant to upgrade because of their bulkiness and the restrictive Digital Rights Management features of the newer versions. To be fair to Microsoft, let's not forget that Flash files, RealPlayer, Winamp, and just about every other popular media distribution content has be found to have one or more exploit holes over the past year. But network administrators would appreciate it if Windows Media Player was not installed by default and upgrades were not offered to end-users via Windows Update when it has been removed on purpose.
WebDAV (Web Digital Authoring and Versioning)
WebDAV is a feature installed on machines with XP or IIS 5, or greater. WebDAV is a HTTP protocol extension that allows users to publish and collaborate on documents that are stored on the web. Contrary to common belief, WebDAV is a popular open standard and not just a Microsoft feature. There have been a handful of exploits against Microsoft's implementation of WebDAV, including DoS and buffer overflows. The biggest problem with WebDAV is that it is installed and turned on by default when most people don't use it. It's a good, powerful collaboration tool, it just needs more security analysis and should not be turned on by default. WebDAV is not turned on by default on Server 2003 and IIS 6.
Remote Desktop Connection
Remote Desktop Connection allows one XP Pro PC to remotely connect and control another XP Pro PC with a PC Anywhere-style session. Remote Desktop, as it is called in the System Control Panel applet, uses Terminal Server's Remote Desktop Protocol (RDP) over TCP port 3389. It is not turned on by default, and so far has not been exploited. Still, knowing that it is installed as an inactive shell on every Windows XP computer, many of which are poorly secured, raises some concerns.
Remote Assistance
Unlike Remote Desktop Connection, Remote Assistance is turned on by default. It allows one XP user to invite, using either email or instant messaging, another XP user to have remote control access over their PC. Besides desktop control, the remote user can participate in chat sessions and transfer files. Invitations can be open for many days, and the default is 30 days. One of the main concerns is that there is no vetting mechanism to guarantee who is who in the remote assistance scenario. There exists the possibility that a malicious remote user may impersonate a tech support person and plant malicious files. While there have been no public exploits using Remote Assistance, AV experts worry about poorly password protected connections and buffer overflow attacks.
Internet Connetion Firewall (ICF)
Microsoft's first attempt at a desktop firewall is laudable, but comes up a bit short. ICF's main deficiency is that it lacks the ability to block outgoing port traffic. Many malware programs, once installed, will initiate outbound communications to continue their maliciousness. It could be a remote access trojan contacting its originating hacker to advertise the successful intrusion or an email worm with its own SMTP engine sending itself out around the world. In either of these two cases, because ICF allows all outgoing requests by default, the end-user will not be warned. Most of today's personal desktop firewalls would stop the request and alert the user. I hope if Microsoft continues to support ICF as firewall product that additional features sets will be added and its usefulness increased. ICF is also installed on Server 2003.
UPnP
Universal Plug and Play is another feature that should be turned off by default. UPnP allows a Windows machine to discover UPnP devices (ex. printers, scanners, etc.) on the network and to auto-configure their use. UPnP ended up being XP's first big publicly touted hole in December 2001. It was a buffer overflow and could be successfully exploited over the Internet, and if a firewall did not block UDP port 1900, it could be used to gain complete control of the machine. Luckily, UPnP is not even installed on Microsoft's latest offering, Windows 2003.
Simple File Sharing
XP the Home Edition has a feature called Simple File Sharing. When a folder is shared, it is immediately accessible to everyone on the local network and no specific permissions can be set. The folder can be set as read-only, but if changes are allowed, full control is given to anyone who can see the folder. AV experts worry that if a virus or worm gets loose on a home network with Windows XP Home, the malware will have no problem traveling machine to machine using network shares
Windows Messenger
Microsoft's Windows Messenger is installed by default on XP Pro and Home editions. Instant messaging (IM) clients open additional avenues for attacks. First, there have been many buffer overflow attacks against instant messaging clients, even when not turned on and only installed. Second, IM clients allow yet another avenue for the unsuspecting Joe User to receive malicious files. Many antivirus programs do not monitor IM file transfers. Third, there are malicious programs and viruses that specifically target Microsoft's IM clients. Although not attacked nearly as much as IRC and AOL's AIM clients, instant messaging is a technology being used before the security is all in place.
Office XP
Although only affiliated with Windows XP by name only, here's a good point to discuss a potential security problem in Microsoft Office XP. One of the most touted features of Office XP is its ability to read and write files in XML format. Macro viruses, which for several years were the number one infection type, have been mostly tamed by Office's macro security and antivirus software. XML has the potential to allow yet another round of new technology viruses into our Office documents. This is because XML is an everyman's language. An XML file is what you define it to be. Besides text, it can contain executable code, scripting, multi-media content, whatever programmers might want it to contain. As has been proven so many times in the past, flexibility and choice increases the risk of malicious exploitation.
I'm sure there are some features I missed that may be exploited in the future, but at the moment these are the main ones garnering increased scrutiny by security professionals.
Windows XP Security
Before this paper ends, I want to point out that security has been strengthened in Windows XP, and much more so in Windows 2003. XP was the first Microsoft operating system to offer a firewall (ICF), and it's better than nothing for the consumer that isn't motivated to install another vendor's personal firewall product. XP has Encrypted File System (EFS), Windows File Protection (WFP), Certificate Services, IPSEC, Kerberos, Software Restriction Policies, and System Restore. All of these additional features fight malicious code and are welcome additions to the Microsoft family. All security reviews of Server 2003 have been positive. More unnecessary features have been turned off by default and file and registry settings strengthened.
Summary
The complexity of the .NET execution platform worries security experts. Once it is widespread, malicious coders will find holes in between the interoperable layers and then execute security exploits. The persuasive nature of web services means that one malware threat could quickly compromise a large number of machines. There are already three .NET viruses and worms. Although they are buggy, future viruses and worms will be able to perform without error as crackers begin to target .NET.
Windows XP contains much new functionality, some of which has been exploited, and other features which have yet to be maliciously explored. XP also contains many new security features, like Windows File Protection and Internet Connection Firewall, which strengthens the OS's response to security threats.
Roger A. Grimes, CPA, MCSE (NT/2000), CNE (3/4), A+, has been fighting malicious code since 1987 and is the author of Malicious Mobile Code: Virus Protection for Windows (O'Reilly). He is a frequent writer and speaker on computer security topics. His next book, Honeypots for Windows (APress) will be available near the end of the year.
Source : http://securityfocus.com
Sunday, August 26, 2007
Antivirus Concerns in XP and .NET Environments
Malware Analysis for Administrators
1. Introduction
The threat of malicious software can easily be considered as the greatest threat to Internet security. Earlier, viruses were, more or less, the only form of malware. Nowadays, the threat has grown to include network-aware worms, trojans, DDoS agents, IRC Controlled bots, spyware, and so on. The infection vectors have also changed and grown and malicious agents now use techniques like email harvesting, browser exploits, operating system vulnerabilities, and P2P networks to spread. A relatively large percentage of the software that a normal internet user encounters in his online journeys is or can be malicious in some kind of way. Most of this malware is stopped by antivirus software, spyware removal tools and other similar tools. However, this protection is not always enough and there are times when a small, benign looking binary sneaks through all levels of protection and compromises user data. There may be many reasons for this breach, such as a user irregularly updating his AV signatures, a failure of AV heuristics, the introduction of new or low-profile malware which has not yet been discovered by AV vendors, and custom coded malware which cannot be detected by antivirus software. Though AV software is continually getting better, a small but very significant percentage of malware escapes the automated screening process and manages to enter and wreak havoc on networks. Unfortunately, this percentage is also growing everyday.
It is essential for users and absolutely essential for administrators to be able to determine if a binary is harmful by examining it manually and without relying on the automated scanning engines. The level of information desired differs according to the user's needs. For instance, a normal user might only want to know if a binary is malicious or not, while an administrator might want to completely reverse engineer the binary for his purposes.
Traditionally, malware analysis has been considered to be very complicated, and in fact some of the techniques are still very complicated and beyond a normal user's access. Nevertheless, looking at the current scenario, we can see that there is a clear need for people to learn how to analyze malware themselves. But the caveat is that the analysis techniques have to be simplified and the learning curve has to be made smaller for mass consumption among the general public. Unfortunately, there is not much organized information in the public domain dealing with easy to use malware analysis techniques. This paper tries to fill this void. The focus is on malware reversing but these techniques can be applied to reverse engineer any binary.
Besides the uses mentioned above, malware analysis is used for forensics, honeypot research, security vulnerability research, etc.
2. Background, goals, assumptions and tools
2.1 Background
There are basically two broad categories of techniques that are used for analyzing malware: code analysis and behaviour analysis. In most cases, a combination of both these techniques is used. We will consider code analysis first.
Code analysis is one of the primary techniques used for examining malware. The best way of understanding the way a program works is, of course, to study the source code of the program. However, the source code for most malware is not available. Malicious software is more often distributed in the form of binaries, and binary code can still be examined using debuggers and disassemblers. However, the use of these tools is often beyond the ability of all but a small minority because of the specialized knowledge required and the very steep learning curve needed to acquire it. Given sufficient time, any binary, however large or complicated, can be reversed completely by using code analysis techniques.
On the other hand, behaviour analysis is more concerned with the behavioural aspects of the malicious software. Like a beast kept under observation in a zoo, a binary can be kept in a tightly controlled lab environment and have its behaviour scrutinized. Things like changes it makes to the environment (file system, registry, network, etc), its communication with the rest of the network, its communication with remote devices, and so on are closely observed and information is collected. The collected data is analyzed and the complete picture is reconstructed from these different bits of information.
The best thing about behaviour analysis is that it is within the scope of an average administrator or even a power user. The learning curve is very small and existing knowledge can be leveraged to make the learning process faster. This makes it ideal for teaching newbies the art of malware reverse engineering. These reasons are consistent with our stated goals, focused on the typical administrator, and therefore this paper is mostly concerned with behaviour analysis.
Though reverse engineering using behaviour analysis does not lead to the complete reversing of a binary, it is sufficient for most users' needs. For instance, it is not sufficient for an antivirus researcher but for most other users, behaviour analysis can fulfill all their needs.
2.2 Goals in the analysis
As stated before, our goal is to provide a set of behaviour analysis techniques for reverse engineering malware. Also, the learning curve should be small so that it is within the scope of most people.
Using these methods, people should be able to analyze an unknown binary and determine whether it is malicious or not. Those who require more in-depth knowledge should be able to reverse engineer the binary, understand and document its workings completely.
2.3 Assumptions and definitions
This paper makes a few assumptions for the sake of convenience and clarity. These are:
1. We assume that the malware under consideration is a Win32 based binary on an Intel x86 machine. This is just for the sake of clarity. The basic principles can be just as easily applied to any other platform.
2. We sometimes refer to the malware as "the binary". This does not however mean that the principles are applicable only to a malicious application that is composed of a single binary.
3. The host machine on which the binary is executed is referred to as the "victim host" or the "victim machine".
4. The other machine on the test network is referred to as the "sniffer machine".
2.4 Tools
Since the goal of this paper is to propose a generic set of techniques, the tools mentioned in this paper are just "proposed" tools and are available as references at the end of this document. Any other tool that has the same or similar functionality can be used in place of the proposed ones.
3. Methodology
The framework proposed is broadly divided into six stages. They are:
1. Creating a controlled environment
2. Baselining the environment
3. Information collection
4. Information analysis
5. Reconstructing the big picture
6. Documenting the results
3.1 Creating a controlled environment
The setting up of a controlled and sanitized environment is absolutely essential for analyzing malware. A special "test lab" is created for this purpose. Some essential features of the test lab are:
* At least two machines should be used. One machine is for hosting the malicious binary (victim machine) and the other is for baselining and sniffing the network traffic (sniffer machine). They should be networked in such a way that each of them is able to sniff the other's network traffic.
* The two networked lab machines should be isolated from the rest of the network.
* Fresh copies of Operating Systems should be installed on each of the two machines. It is preferable to have a WinNT kernel family OS on one machine and a *nix based OS on the other. Since we are assuming a Win32 binary, the WinNT machine acts as the "victim host" and the *nix machine is used as the "sniffer machine".
* Tools should be transferred to the relevant machines.
* The binary that is to be examined should be transferred to the relevant machine. Since we are assuming a Win32 binary, it is transferred to the Win32 machine in this case.
* It is highly preferable not to install any other application upon the "victim host" apart from the tools required for analysis.
This is the most basic setup for a malware analysis lab. Apart from this and depending on the situation, more modifications can be carried out. For instance, if the malicious binary tries to communicate with a remote server xyz.com, a DNS server has to be setup in one of the lab machines and a DNS entry for xyz.com has to be created. An excellent paper that discusses the creation of a malware analysis lab is "An Environment for Controlled Worm Replication and Analysis".
We may have to return to this "creating a controlled environment" stage many times during the analysis process. Sometimes, in the light of new information generated during the later stages, the lab will have to be tweaked and modified.
3.2 Baselining the environment
Baselining the environment is the next major step. "Baselining" means taking a snapshot of the current environment. This is the most vital stage in our analysis. If baselining is not done properly, it has a serious effect on the information gathering stage, which in turn seriously effects our understanding of the binary. If baselining is done efficiently, the information generated during the next stage becomes very accurate and the rest of the stages become easy to execute.
To accomplish our goals, the binary which is to be analyzed is executed in a controlled environment and the changes it makes to that environment are captured. Before executing the binary, a snapshot of the environment is created (baseline) and then after execution another snapshot is created. In theory, the difference between the baseline and the final snapshot gives the changes made by the binary.
The elements of the environment that have to be baselined are:
3.2.1 Victim machine
Some of the elements that are to be baselined in the Victim Machine are:
o Filesystem: The file system on the victim host has to be baselined. There are many programs that can create a snapshot of the file system and after a few changes occur, they can point out the modifications. Some of the programs we can use are Winalysis and Installrite.
o Registry: The registry is the next component that is to be baselined. Most malware applications rely on registry entries. Therefore it is crucial to capture registry modifications. Winalysis as mentioned above is one of the available programs that can be used for registry baselining.
o Running processes: A snapshot of the running processes can be created using a number of programs. Some of them are available from Sysinternals.
o Open Ports: A snapshot of the open ports can be created using the 'netstat' utility. However, it does not list the name of the process that is tied to the port. For this, we can use Fport available from Foundstone.
o Users, Groups, Network Shares and Services are some of the other elements that should be baselined.
3.2.2 Network traffic
The next element that has to be baselined is the network traffic. Even when there is no application running on either of the test machines, there will still be some network traffic. This traffic has to be recorded and the "normal traffic" in our test network has to be defined. This is because when deviations occur in the "normal traffic" pattern, we can assume it to be generated by the binary and perform further testing on it.
Sniffing software that is installed on our "sniffer machine" is used for this purpose. Any sniffing software running in verbose mode is sufficient for our purposes. However, to make our task easier, it is preferable to use a protocol analyzer like Ethereal.
3.2.3 External view
Although we have created a snapshot of the open ports in the victim machine, it is always better to create one more snapshot from an external machine. A port scanner running on our "sniffer machine" can achieve this task for us. It goes without saying that Nmap will be the port scanner of choice for most users.
3.3 Information collection
Now that the preparations are over, we can go ahead with our task. This is the only stage where we have an actual interaction with the binary. A lot of raw information about the binary is collected during this stage which is analyzed in the next stage. Therefore, it is very important to carefully record all the information generated in this stage. The steps in the information collection stage are:
3.3.1 Static analysis
During the static analysis stage, we collect as much information about the binary as possible, without executing it. This involves many techniques and tools. Static analysis reveals the scripts, HTML, GUI, passwords, commands, control channels, and so on. Simple things like the file name, size, version string (right-click>properties>version in Win32), are recorded.
Human-readable strings are extracted from the binary and these strings are recorded. A program like Binary Text Scan can be used for this purpose. These strings reveal a lot of information about the function of the binary.
Resources that are embedded in the binary are extracted and recorded. A program like Resource Hacker can be used for this purpose. The resources that can be discovered through this process include GUI elements, scripts, HTML, graphics, icons, and more.
3.3.2 Dynamic analysis
During this stage, we actually execute the binary and observe its interaction with the environment. All monitoring tools including the sniffing software are activated. Different experiments are done to test the response of the running malware process to our probes. Attempts to communicate with other machines are recorded. Basically a new snapshot of the environment is created like in the baselining the environment stage.
After taking a snapshot of all the changes the binary performs in the system, the binary process is terminated. Now, the differences between the new snapshot and the baseline snapshot are determined. The dynamic analysis step is very similar to the baselining the environment stage. Therefore, the tools are reused for this stage. Winalysis and InstallRite can be used for this purpose. Apart from these tools, Filemon and Regmon from Sysinternals can be used for monitoring the file system and the registry dynamically. These tools are used for observing the changes to the file system and the registry.
This information is recorded and forms the input for the next stage of our analysis. The information generated here can be new files, registry entries, open ports, etc.
Sometimes, the static analysis step has to be repeated once more after doing a dynamic analysis.
3.4 Information analysis
This is the stage where we can finally reverse engineer the binary based on all the information collected during the previous stages. Each part of the information is analyzed over and over and the "jigsaw puzzle" is completed. Then the big picture automatically begins to appear and the reverse engineering process is finished. However, before this is achieved, we may have to repeat the previous stages (See figure) several times.
The goals of the individual or organization evaluating the binary determine the type of analysis and because the goals differ, no standard methodology is provided for this stage. Looking for deviations from the stated security policy of an organization based on the information can be the determining factor in some cases.
Although a complete methodology for information analysis is beyond the scope of this paper, a few techniques are presented here. In many cases, these techniques are sufficient for analysis.
3.4.1 Internet searches
A search engine can be used for searching for more information on the binary. Keywords for the search engine can be drawn from the information generated during the "Static Analysis" step during the previous stage. Things like filenames, registry entries, commands, etc. often reveal a lot of information about the malware. Some good sources of information on the internet include Online Virus Databases (mostly maintained by Antivirus Vendors), News Groups and Mailing Lists. Many times, internet searches reveal almost all there is to know about the malware and no further research is needed.
3.4.2 Startup methods
Every malware needs a way to ensure that it is executed when a system reboots. This is the most vulnerable aspect of the malware. There are only a limited number of ways in all operating systems that a program can use to restart automatically when a machine reboots. The information collected during the previous stage can be analyzed to identify the startup method of the malware. A very good source for Startup Methods related information on the Internet is the Paul Collins' Startup List.
3.4.3 Communication protocol
A network protocol analyzer like Ethereal in many cases can identify the communication protocol used by the binary. When this is not the case, the protocol has to be reverse engineered. This is beyond the scope of this document.
3.4.4 Spreading mechanism
If the malware under scrutiny is a self-spreading worm or virus, the collected network traffic data will easily reveal its spreading mechanism. In most cases, a cursory glance is enough.
3.5 Documenting the results
Documenting the results of the malware analysis and reverse engineering exercise is essential. One of the main advantages is that the knowledge incorporated into the documentation can be leveraged for later analysis exercises. The documentation needs differ from individual to individual and organization to organization. The method preferred by the concerned party can be used here.
4. Conclusion
From this article we've seen that a basic behavioral analysis of a binary can be easily performed by an administrator, or indeed by a power user. While this approach does not give the same level of detail as code analysis would, it is sufficient for most people's needs when figuring out what a potentially malicious binary is capable of.
About the author
S.G.Masood is the founding CTO of the Chicago, Illinois based application security startup Circle Technologies. He currently stays in Hyderabad, India and manages the development center.
References
"An Environment for Controlled Worm Replication and Analysis" by Ian Whalley Bill Arnold, David Chess, John Morar, Alla Segal, Morton Swimmer - www.research.ibm.com/antivirus/SciPapers/VB2000INW.htm
"Reverse Engineering Malware" by Lenny Zeltser - www.zeltser.com/sans/gcih-practical/revmalw.html
"Paul Collins' Startup List" - http://www.sysinfo.org/startuplist.php
Archives of the various security and malware related mailing lists, most notably, Bugtraq, Full-Disclosure, Focus-Virus, Incidents.
VMWare - www.vmware.com
Winalysis - www.winalysis.com
Installrite - www.epsilonsquared.com
Fport - www.foundstone.com
Nmap - www.insecure.org
Binary Text Scan - netninja.com/files/bintxtscan.zip
Resource Hacker - www.users.on.net/johnson/resourcehacker/
Filemon and Regmon - www.sysinternals.com
Ethereal - www.ethereal.com
Source : http://securityfocus.com
Recent Security Enhancements in NetBSD (Part 2)
On one hand, some would claim that exploit mitigation discourages developers from writing secure code and vendors from quickly responding to security incidents: they know there's a safety net guarding them, and so they pay less attention to security when writing code, or taking their time coming up with fixes for security issues.
On the other hand, however, this is also where exploit mitigation technologies excel: they introduce the concept of preventing the successful exploitation of security vulnerabilities, even before a fix is available. Moreover, they prevent entire classes of bugs, and don't require constant updating.
2.2.3 Architectural Integration
So far, the previous two approaches assume the cause of a security breach is a bug in the code that is being exploited. The first approach tries to eliminate such bugs, and the second one tries to make it next to impossible to successfully exploit them. However, some environments require more than just that - for example, the ability to define detailed usage policies and associate them with entities on the system became a mandatory part of many security policies. In our context, we can relate that to the Unix permissions model; simply put, due to the coarse separation between a normal user and a superuser, it cannot be used to express many security policies as detailed as may be required.
That led to the research of various modern security models, of which most recognized ones are fine-grained [ref 5] discretionary access controls (DACs) and mandatory access controls (MACs). To put things simple, DACs focus on the data owner's ability to specify who can use it and for what; MACs focus on a mandatory policy that affects everyone.
These systems allow an administrator - and where applicable, the users - to specify fine-grained policies; effectively, this means that a user or a program can be made to work with the minimal amount of privileges required for their operation (which, as implied above, cannot be done with the traditional Unix security model), resulting in damage containment in case of compromise or otherwise minimized impact from security vulnerabilities.
2.2.4 Layered security
To itself, layered security [ref 6] is not a single approach. Where any of the previous three took a different route, the layered security approach suggests that maximized security can only be achieved by combining efforts on all fronts: code auditing is important, but does not come in place of useful exploit mitigation technologies; and architectural integration, of course, has little to do with any of them.
Although the above may sound obvious, it is not too often when you see an operating system that puts an emphasis on all three aspects; it will usually be the case that only one of the approaches is fully practiced. Following are some short case-studies that illustrate the importance of each approach by using real-world examples.
2.2.5 Case Studies
Shortly after splitting from NetBSD in 1995, OpenBSD became widely known for its unique - at the time - approach to security: proactive code auditing. Instead of retroactively responding to security issues, OpenBSD developers performed thorough code auditing sessions, sweeping for bugs. This act proved itself more than once, after vulnerabilities found in other operating systems were already fixed [ref 7] in OpenBSD.
This, however, did not last too long. In 2002, winds of change blew through the OpenBSD mindset: the long standing fort of code auditing fell, adopting exploit mitigation technologies to its lap [ref 8]. While the reasons behind the move were not published, some speculate that it was the release of an exploit allowing full system compromise of OpenBSD's default configuration [ref 9] that finally proved that even a group of dedicated programmers cannot find all bugs; at least not first.
Said exploit mitigation technologies made their public debut around 1996, with the appearance of the Openwall [ref 10] project, and later evolved dramatically by the PaX [ref 11] project in 2000. Research done in both projects formed the basis of today's exploit mitigation technologies. Another commonality of the two was that they offered an implementation based on Linux - which only makes one wonder why it was OpenBSD that was the first to officially adopt these technologies.
Linux, however, took a different direction. First with the addition of POSIX.1e [ref 12] capabilities in 1999, fine-grained discretionary access controls, later with SELinux [ref 13], an implementation of mandatory access controls, and finally with the introduction of the Linux Security Modules framework [ref 14], abstracting the implementation of both, Linux focused mainly on offering means for an administrator to define a detailed security policy, hoping to minimize the effect of a vulnerability.
Not lagging behind too much, though, exploit mitigation technologies also appeared in the official Linux kernel during 2004-2005; in fact, they also made an entrance to the official Windows world with Windows XP SP2 [ref 15], and Windows Vista is expected to include even more such technologies [ref 16].
Simply put, all three major approaches have been practiced by widely used operating systems at one point or another. It is clear to see that although initially a single approach was chosen, eventually it was understood that layered security is the key to stronger defense of computer systems.
2.3 The NetBSD Perception of Security
Learning from others’ experience, the approach taken by NetBSD employs three main principles:
* Simplicity. There is no point in providing a feature, whether it’s a kernel subsystem or a userland tool, if it’s not intuitive and easy to use. Furthermore, overly complex code is harder to audit, which may lead to additional bugs.
* Layered security. It is well understood that there is no single solution to security. NetBSD addresses security from a variety of angles, including code auditing, adequate and extensible security infrastructure, and exploit mitigation technologies.
* Sane defaults. Accepting that security may not be the highest priority for all users, NetBSD provides sane defaults to fit the common case. Detailed supplementary documentation helps enable and configure the various security features.
Using the above guidelines, a variety of security solutions were evaluated to address different threat models. With emphasis on implementing a solution that would fix a real problem and provide an intuitive and easy to use interface (when one is required), a variety of changes - ranging from tiny hooks, through additional kernel subsystems, to architectural modifications, NetBSD has made important first steps in improving its overall security.
[ref 5] I emphasize fine-grained because DACs already exist on Unix; however, as noted, they are too coarse.
[ref 6] Also known as Defense in Depth.
[ref 7] http://www.openbsd.org/security.html#process
[ref 8] http://www.monkey.org/openbsd/archive/misc/0207/msg01977.html
[ref 9] http://www.securityfocus.com/news/493
[ref 10] http://www.openwall.com
[ref 11] http://pax.grsecurity.net
[ref 12] http://wt.xpilot.org/publications/posix.1e/
[ref 13] http://www.nsa.gov/selinux/papers/module/t1.html
[ref 14] http://www.kroah.com/linux/talks/usenix_security_2002_lsm_paper/lsm.pdf
[ref 15] http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2mempr.mspx
[ref 16] http://blogs.msdn.com/michael_howard/archive/2006/05/26/608315.aspx
Source : http://securityfocus.com
Recent Security Enhancements in NetBSD (Part 1)
1. Introduction
Running on almost twenty different architectures, and easily portable to others, NetBSD gained its reputation as the most portable operating system on the planet. While that may indicate high quality code, the ever demanding networked world cares about more than just that. Over the past year, NetBSD evolved quite a bit in various areas. This paper, however, will focus on those aspects relating to security.
This paper was written and structured to present a full overview of the recent security enhancements in NetBSD in an easily readable and balanced form that will satisfy new, intermediate, and experienced users. References were sprinkled across the text to provide more information to those who want more detail, while preserving the continuity.
Following this introduction, the paper is presented in five major sections, spread over eight pages. Section 2 presents the bigger picture of security in NetBSD: how NetBSD perceives security, the design decisions of NetBSD software in general and the security infrastructure and features more specifically. Section 3 presents a detailed overview of the recent enhancements in the security infrastructure and features of NetBSD including, where relevant, details about the design, implementation, and possible future development. Section 4 shows current security-related research and development in NetBSD, and then section 5 discusses how the described enhancements work together to provide a more secure platform. Section 6 concludes the paper, and summarizes the availability of the discussed features.
2. The Tao of NetBSD Security
We are all familiar with the mantra that security is a process, not a product. When we consider software development, specifically operating systems, it should be part of the design from the ground up. As the descendent of an operating system over 20 years old, NetBSD carries a security model designed and implemented with different threats in mind; the Internet was smaller, more naive, and less popular.
The following sections will provide background to the approaches taken to enhance the security of the NetBSD operating system: the considerations, existing approaches, and case-studies.
2.1 Considerations
When investigating the enhancement of security in NetBSD, two of the most important leading principles were maintaining compatibility and interoperability [ref 1]. Presenting changes that would dramatically impact the user-base was out of question, and careful planning had to be done. In addition, any change to an underlying back-end had to be well thought-out so it maintains existing semantics without enforcing them during the design stage.
2.2 Security Approaches
Operating system security is nothing new, and NetBSD is not the first to address the issue. In designing software, and security software in particular, it is mandatory to learn from the experience of previous work. Below are some common approaches to security and real-world case studies.
2.2.1 Code Auditing
Code auditing addresses security issues by looking for programming glitches in the source code of the program, often with the assistance of automated tools [ref 2]. Normally the work of vulnerability researchers, when done proactively by the programmers themselves, code auditing has the potential of locating and fixing bugs that have security implications before anyone else finds and exploits them.
While some would argue that striving to produce bug-free code is the one true way of achieving security, this view is a fallacy for two main reasons. The first is that security issues are not always the result of programming errors; while code auditing tries to ensure no software bugs will be maliciously exploited because said bugs would simply not exist, it alone ignores other important aspects, such as configuration errors and user behavior policies.
The second reason is that it is not possible to write bug-free code [ref 3]. Over the past decade, awareness on writing secure code rose significantly; automated tools evolved, allowing easy pinpointing of software bugs; open-source software is available for the review of thousands - if not millions - of people. Yet, we still see new security vulnerabilities on a daily basis. Some of those, ironically, are of the exact same type that affected us ten or twenty years ago [ref 4].
2.2.2 Exploit Mitigation
The unorthodox approach of exploit mitigation addresses bugs from the opposite direction of code auditing: instead of looking for them in and removing them from software to make it more secure, it adds bugs to the exploit code to prevent it from working. While that may be over-simplified, the purpose of exploit mitigation technologies is to interfere with the inner-workings of the exploit, eliminating the - often unusual - conditions that make it work.
[ref 1] Two other leading principles - not impacting the system performance and an easy user interface, will not be discussed in this paper.
[ref 2] Coverity, for example, offered its services to various open-source projects, including NetBSD, for free. See http://scan.coverity.com
[ref 3] http://www.cs.columbia.edu/~smb/papers/acm-predict.pdf
[ref 4] http://www.cert.org/homeusers/buffer_overflow.html
Source : http://securityfocus.com
Analyzing Malicious SSH Login Attempts
Introduction
Malicious SSH login attempts have been appearing in some administrators' logs for several years. This article revisits the use of honeypots to analyze malicious SSH login attempts and see what can be learned about this activity. The article then offers recommendations on how to secure one's system against these attacks.
Using honeypots for research
The New Zealand Honeynet Alliance is a research organization and member of the Honeynet Alliance, which is dedicated to improving the security of computer systems and networks by researching the behavior, tactics, and tools of black hat hackers through the use of honeypot technology. Honeypots are computer systems whose value lies in their openness to attack and compromise, allowing the researcher to analyze malicious activity on the system.
We have set up such a system at the Victoria University of Wellington to investigate malicious activity that occurs on a university network in New Zealand. This system was a high interaction honeypot that an attacker can interact with like any other system on the network. As far as the attacker is concerned, there should be no discernible difference between the honeypot and other computer systems. However, it is closely monitored through the Honeynet Alliance Roo honeywall that captures all network traffic flowing to and from the honeypot. In addition, system events are recorded on the honeypot itself via its logging facility.
The honeypot ran a standard server configuration of RedHat 9 with a Secure Shell (SSH) server that was accessible via the public Internet. SSH is a program that allows a user to log into another computer over a network via an encrypted channel. After we encountered malicious SSH login attempts in previous setups, we configured our honeypot to allow for additional data collection. We patched the SSH server to record the password along with the account name that was used in the login attempt. The honeypot was brought online on July 11, 2006 and taken offline on August 1, 2006, after 22 full days. The honeypot was attacked numerous times during this period with login attempts on SSH. We take a closer look at the data to determine the tactics of the attackers and to make recommendations to improve security around SSH.
In an additional configuration of the honeypot, which ran from June 28 to July 4, we added the Sebek module that records key strokes of the attacker once the system has been compromised. We configured several user accounts with commonly used passwords. After a few days, an attacker successfully compromised the system. The analysis of this attack and subsequent attacks are presented in this paper and provide us with further insight into how the malicious SSH login attempts are used to compromise systems.
Analysis of SSH Login Attempts
This section analyzes the data captured by our honeypot from July 11 to August 1. The analysis is entirely based on data of system log files of the honeypot, in particular the ‘messages’ log. The ‘messages’ log captures authentication requests to the SSH server. It captures date, time, the IP address from which the login attempt originated, the result of the request (failure or success), the account name and the password used for the authentication request. Two ‘messages’ sample log entries are shown below.
Jul 13 09:37:59 basta sshd[22308]: PW-ATTEMPT: fritz
Jul 13 09:37:59 basta sshd[22308]: Failed password for root from 10.0.160.14
port 39529 ssh2
Jul 13 09:38:02 basta sshd[22310]: Illegal user fatacunike from 10.0.160.14
Jul 13 09:38:02 basta sshd[22310]: PW-ATTEMPT: fatacunike
Jul 13 09:38:02 basta sshd[22310]: Failed password for illegal user fatacunike
from 10.0.160.14 port 40444 ssh2
First, we analyzed the login names that were used on the login attempts. During the sample period, there were 2741 unique account names ranging from common first names, system account names, and common accounts to short alphabetical strings captured by the system logger. Of those, the 15 account names used most often are shown in Table 1. This table shows accounts that usually exist on a system (root, mysql), accounts that are likely to exist on a system (guest, test), as well as common first names (paul). Then Figure 1 shows the distribution of valid and invalid account names that were used.
It comes as no surprise that the invalid account names used far surpass the valid account names. However, we note that 96.30% of all default account names that exist on the honeypot have been used in an attack.
Account Name Number of login attempts
root 1049
admin 97
test 87
guest 40
mysql 31
info 30
oracle 27
postgres 27
testing 27
webmaster 27
paul 25
web 24
user 23
tester 22
pgsql 21
Table 1. Top 15 account names among 2741 attempts.
Figure 1. Number of account names, both existing and invalid.
Next, we looked at the passwords used in the login attempts. The attackers tried a range of passwords with most of the account names. In total during our analysis, they attempted to access 2741 different accounts and used 3649 different passwords. Not all passwords were used with all accounts. The passwords ranged from account names, account names with number sequences, number sequences, and keyboard sequences (like ‘qwerty’). There were a few more complex passwords used with seemingly random letter and number sequences or common substitution passwords (like r00t or c@t@lin).
Table 2 shows the top 15 passwords used in malicious login attempts.
Password Number of login attempts
123456 331
Password 106
Admin 47
Test 46
111111 36
12345 34
administrator 28
Linux 23
Root 22
test123 22
1234 21
123 20
Mysql 19
Apache 18
Master 18
Table 2. Top 15 passwords attempted.
Then we examined who attacked the honeypot and what strategy these attackers used. There were 23 unique IP addresses involved in the login attempts. The attackers were more or less persistent in their attempts to gain access to the system, as shown in Table 3. Ten of the sources tried less than 50 combinations and then gave up. Five tried harder with approximately 170 login attempts, and eight tried even harder with up to 1450 login attempts. Figure 2 shows the breakdown of login attempts per source address.
Number of Login Attempts Unique IP Addresses
< 50 10
50 <= x <= 200 5
> 200 8
Table 3. Frequency range of login attempts.
Figure 2. Failed login attempts by source IP.
A closer look at the attackers reveals more information about how the break-in attempts took place. The attackers tried one single account name per login attempt with a password that mostly matched the account name (e.g. test/test) and moved onto the next account name. Other attackers differed in their strategy. On average, attacker 10.0.179.148 tried five passwords before trying a different account. The passwords used in this attack scheme consisted of the number sequences or the account name with a combination of various number sequences (e.g. admin/admin, admin/admin1, admin/admin123, admin/111111). The attacker at 10.0.105.52 concentrated on the root account, attempting all but one of his login attempts (guest) with that account name. The passwords ranged from common passwords to random number and character sequences (e.g. root/!@#, root/123abc, root/default).
Several attackers exhibited behavior that was likely to evade the attention of an IDS by limiting their attacks to just a few attempts. Attacks became more serious by various degrees. First, the number of login attempts increased; second, the login attempts per account increased, and finally, we saw a concentration of login attempts on a particular account, like root. As attempts became more serious, detection of the attacker would become more likely if an intrusion detection system had been deployed. One would think that the attacker's success rate would increase with more attempts and a subsequent increased danger of detection, but we cannot confirm this as our data did not include a survey of account name/password combinations of existing systems.
In an effort to obtained further information about the methodology and tools the attackers used, we examined the variance and average time period between each login attempt per source IP. We assumed that if a tool was used in the attack, we could easily identify its usage by inspecting these values. A small gap between login attempts and a low variance would indicate usage of a tool, whereas larger irregular gaps would indicate the attacker was actually performing the login attempts in person. Figure 3 summarizes this data.
Figure 3. Average period between login attempts (seconds).
The top five offenders, who are likely to have used tools in their attacks due to the sheer number of attempts, show an average period between attempts of 2 to 4 seconds with a standard deviation that ranges from 0.45 to 1.39 seconds. On the other extreme, we find that the attacker at 10.0.192.15 with an average period between attempts of approximately 7 seconds and a standard deviation of 2.36 seconds - indicating a person might have performed the login attempts. However, the data does not support a clear indication of tool usage as many attack sequences fall in the middle or even below the values of the top offender attack sequences. A possible explanation might be that attack tools were used in most attack sequences and we are only observing network latencies.
Compared to the above attempts, a strong indicator of tool usage is revealed by examination of the account names and passwords used in the attacks from 10.0.255.81 and 10.0.242.26. Although the IP addresses resided in different physical networks and the attacks occurred 4 days apart, the account name/ password combination was identical.
The “Successful” malicious SSH login attempt
In the previous section, we analyzed the data captured of unsuccessful malicious SSH login attempts. The data gives us some insight into how attackers operate, but leaves many questions unresolved. One of those questions is whether or not tools are used in these attacks.
On July 2, an attacker successfully compromised the honeypot by guessing a valid user account name/password on SSH. The data captured during this incident revealed answers to these open questions.
First we examined the actions of the attacker after the successful compromise of the honeypot. Once a valid account name/password was determined, the attacker logged into the honeypot via SSH and proceeded to download an SSH scanner tool. This tool is described in more detail in the following section, but for now it will be summarized as a tool that allows its user to identify and compromise other SSH servers through password guessing attempts. The installed tool was immediately used to scan a class B network from our honeypot. Due to the restrictions on outgoing network connections enforced by the Roo honeywall, the SSH scanner did not identify any SSH servers.
After the initial scan, the attacker proceeded to download and install an IRC Bot. IRC Bots are tools that can control a compromised system remotely via IRC chat channels that the compromised system is set to listen to. Using IRC to control a compromised system is much more covert than using SSH directly, as the attacker does not have to directly log into the system anymore. Further, it allows the attacker to control several such systems, also known as Zombies, at the same time.
The conversations in the IRC channel revealed that the Zombies were used to scan class B networks with an SSH scanner just like the one that had been downloaded to our honeypot. During a period of a couple of hours, four class B networks were scanned with the SSH scanner from various IRC Bots, identifying thousands of SSH servers. A scan took approximately 700 seconds to complete. Further, we witnessed the exchange of an account name/password list with 160,324 unique account name/password combinations. The structure of these account names and passwords was very similar to the ones encountered during the attacks on our honeypot system, but more extensive.
Analysis summary
What do we make of this data captured by our honeypot? SSH is a way to access a computer over a network in a secure, encrypted way and has gained wide acceptance. However, despite its good reputation with respect to security, there are still threats associated with operating SSH on a machine. Password guessing clearly one of these threats, as we have shown in this paper. The mere fact that the SSH server is running and accessible from the Internet attracted 23 sequences of attacks from unique source IPs, with 6,899 login attempts to our honeypot in just 22 days. This equates to roughly one attack and approximately 300 login attempts per day, on average. Some attackers are very serious about performing attacks, executing hundreds of login attempts in a session.
The scanner capture revealed that very powerful tools are used. They are very flexible and can use customized account name/password lists for the attacks. If an attacker wanted to attack a particular domain, they potentially could harvest account names by social engineering and then combine these account names with standard passwords to be used in the attack. Observing the IRC Bot channel, we saw that attackers combined scanning tools with IRC Bot technology to perform scans via Zombies (compromised systems the attackers control via a remote channel). Our performance tests have revealed that the SSH password scanner can scan a class B network in 700 seconds.
Combined with an army of IRC bots, an attacker only needs 525 Zombies to scan the entire IP4 of today's public Internet in just one day. If you have a publicly accessible SSH server, you are very likely to be targeted by one of these attacks.
Recommendations
There are a number of simple methods to protect against these attacks. The most obvious way is to turn off the daemon service, which on many systems is installed by default. If the computer system runs as a desktop machine, there is likely no need for remote access via SSH to log into the machine. If this is not an option, there are numerous other options.
* Use the /etc/hosts.allow and /etc/hosts.deny files found on most Unix and Linux system to restrict daemon access to specific hosts.
* Install a firewall to restrict access to the SSH server from only designated machines and networks. This works particularly well if administration of a machine from an internal network necessitates remote access to that machine.
* Restrict the SSH server to only authenticate particular users or groups.
* Move the listening port of the SSH server from 22 to some other unused port. While this would not prevent attackers from connecting to the server and start guessing password, it will significantly reduce the likelihood of finding your SSH daemon, as attackers use standard SSH clients and attack tools that assume the SSH server is running on its standard port 22.
* Use an alternate authentication method besides simple passwords. More on this below. If this is not an option, ensure that a strong, complex password or passphrase is used.
SSH provides an alternate authentication method which successfully mitigates password guessing attacks. This authentication method is based on cryptographic keys, or so-called private key and public key. The public key is placed onto the server and acts as a custom lock for access to your account. This lock can only be opened with the corresponding private key. Once you provide this key, you gain access. Password guessing attacks would fail as attackers cannot guess or generate such a private key. All modern SSH servers are configured by default to support this authentication method. However, they usually fail back to password-based authentication in case the incorrect private key is provided, opening the door for password guessing attacks once again. The server needs to instead be configured to accept key-based authentication only for this mitigation strategy to be successful.
Setting up SSH with cryptographic keys is very simple and takes only a few minutes. Previous articles written by Brian Hatch have addressed SSH User Identities for secure access between an individual user and an SSH server. For more information on the host key generated by each server, the SSH Host Key Protection article may also be of use. Then, if SSH crytpo keys are in use, the reader may want to further example SSH and ssh-agent to make it easier and faster to login via SSH.
In some instances, password-based authentication or access to an SSH server cannot be disabled. In those cases, other measures need to be taken. We have seen that attackers guess accounts and have good knowledge of existing system accounts and accounts one can commonly find on computer systems. If the attacker is able to guess an account name that exists on the system – on our honeypot this was achieved for 96.30% of the default account names of the RedHat honeypot system – the attacker already has one foot in the door. As such, we recommend not making use of easily guessable account names, such as common first names. Don’t use ‘Peter’, ‘Ian’, or ‘Mark’ but rather create account names that contain a combination of first and last name, like ‘seifer_chr’. This can usually be achieved by the administrator who controls the assignment of account names.
In addition, we have seen that the ‘root’ account is the most often used account name for attacks, as it commonly exists on computer systems. We recommend that remote access to that account simply be disabled. Rather, an administrator should 'su' (superuser) gain access to this account first via a regular user account.
Attackers commonly attempted to guess accounts that exist on most systems by default, like ftp and mysql. Access to the shell can only be obtained for those accounts if a shell is associated with the account. For those accounts like ftp or mysql that simply exist to run a service on the machine, no shell is necessary and should be disabled, effectively barring remote access with these accounts via SSH.
In addition to having account names that cannot be guessed, it is important that the users’ passwords are strong. We have seen that the passwords used in the attacks often match account names or account names with number sequences. We assume that attackers select these passwords as they are most “successful” in malicious login attempts. This implies that at least some users set their passwords to these easily guessable strings. The only way an administrator of a system can prevent users from choosing such passwords is by installing various tools, like passwd+, that force users to choose strong passwords.
Attackers are using tools to perform password guessing and login attempts, such as the captured Scanner, QT, and 55hb. However, despite these tools, the minimum average time of login attempts was around two seconds due to an artificial delay on unsuccessful login attempts that was incorporated into the SSH server, as well as various network delays. While this provides protection against brute force attacks, only a few attempts and guesses are necessary on weak account names and passwords for them to be compromised. Security measures described above should be installed in order to practice security in breadth and depth.
Future work
Our analysis was based on data captured by our honeypot. We are not able to determine how successful these attacks are against systems that can be found on the web. We would have to compare the account name/password combinations used in the attacks to account name/password combinations that exist on real systems in order to determine success rate. Further, we proposed moving the listening port of the SSH server to some other unused port. We need to set up a system with such a configuration to assess its effectiveness.
About the author
Christian Seifert is a member of the New Zealand Honeynet Alliance.
Acknowledgement
Thanks to Jamie Riden for providing additional mitigation strategies on password guessing and references to actual SSH password guessing tools.
Reprints or translations
Reprint or translation requests require prior approval from SecurityFocus.
© 2006 SecurityFocus
Source : http://securityfocus.com
