Ho, just rememberred that, I wrote that little shit in my free times a while ago (not sure if it's still very actual an will help), teach you "step-by-step" ("noob-friendly") how to use Ardamax keylogger.
Here it is:
Here, I'll now explain how to use Ardamax Keylogger to infect another PC.
This will allow yout to know exactly what people are typing on the remote PC (Passwords, Cerdit Card Numbers, etc..).
I'm no sure this is legal, so use at your own risk.
And, by the way, excuse again my imperfect english (French Canadian).
Let's start.
First of all, you'll need Ardamax Keylogger 2.8 downloadable here: http://www.ardamax.com/
If you don't register it (buy a "CD-Key"), when the user will execute the infected program/file, a window about Ardamax will open.
So I searched for a KeyGen, but all were infected wit malwares, trojans...I finally hopefully found this:
*...can't post serials, that's a joke?*
Next step for you, is, once you downloaded Ardamax, to open "setup_akl.exe".
You'll have to install Ardamax on your PC (it will record all you'll type until you uninstall it).
Installing Aramax
-So, double click on "setup_akl.exe". In the new window (about the License Agreement), click on "I Agree".
-Be sure the 3 boxes are tick and click on "Next".
-Choose a new installation path or leave this one, and click "Install" (Ardamax is now installing).
-Once it's done, untick "View the Quick Tour" and press on "Finish".
Infecting a file
-In the new window, click on "Enter Key..." and enter the name and serial I gave you, then press "OK".
-If everything went fine, the window should have close and now you'll have to do a right click on the Ardamax icon in the tray bar (in the right bottom corner of your screen), then click on "Remote Installation...".
-A new screen will open and you'll have to click on "Next".
-Tick the "Append keylogger engine to file or another application" and click on "Browse...". Now, you'll have to browse for the file or the application you want to infect. It can be anything, and, don't worry, the file won't be infected (Ardamax will make a copy of it and leave the one you chose intact). So, when someone will double click on this file, Ardamax will be install on his PC (He won't see any Ardamax installation or w/e window and probably never know he's infected). Once you choosed the file, click on "Open".
-In the same window ("Appearance"), leave "Installation folder on target computer" the same, and under "Additional components", untick "Log Viewer" (untick all) and click on "Next".
-In "Invisibility" window, leave all options tick, click on "Next".
-Now, click on "Enable..." and in the window that popuped, enter a password. Leave all the options tick, and click on "Next".
-Untick "Check for updates" and click on "Next".
-Leave the 2 options tick, and I suggest to change the "Hidden mode on:" to something easier to remember (such as ctrl+z). Also, I would put a "Self destruct on:" date (you have to tick the box beside the date, scroll down and choose a date) this will uninstall Ardamax on the remote PC on the date you choosed)) such as a week later (or until you're sure you know what you want to). Click on "Next".
-Now, in the new window ("Control"), tick "Send logs every" and, right beside, choose the frequency of the logs you'll receive (usually 1/hour or 1/day is fine).
-In the same window ("Control"), under "Delivery method", select (tick) "FTP" and untick "Email". This will send all the logs to your website instead of an email address, it make easier and faster to see the logs in my opinion.
-Again in the same window, leave all the other fields the same, but untick "Send only if log size exceeds". Click on "Next".
-You're now in the "FTP" window. If you don't already have a website (such as mine: www.bambellz.110mb.com) you need to make one. You can follow my tut about pishing sites: *Woha, dead link, too lazy to re-post* and stop after you deleted "index.htm". Once you have a website, you'll have to enter it's address (ex: www.bambellz.110mb.com) in "FTP Host:". Under "Remote Folder:" simply enter "/" and enter the username and password of the website (the one you use to login in www.110mb.com). After that, click on "Test", if everythin went fine, a window witn the message "The Ardamax Keylogger test FTP delivery has been completed succesfully". Click on "OK", and then "Next".
-Select the options you want (I suggest to leave all them tick), and press "Next".
-If you choosed to take screenshot, now select the frequency of them (I think 1/15min is fine), select "Full Screen" and put the quality to the maximum, press on "Next".
-Leave these fields intact, but, I stongly suggest to change the icon to whatever you want (click on "Change Icon..." and look for one you want, you can also click on "Browse..." and browse for what you want) when you chosed it, press on "OK". Press on "Next".
-Now, press on "Finish". If everything went fine, a window with the message "Deployment package created succesfully." appear, press "OK".
Using the infected file
A new window popuped, your infected file is there, it's call "Install.exe" and it have the icon you choosed. Don't touch at any other file in this folder, they are useless. I suggest you rename it.
You now have to spread this file and hope someone will download it and double click on it. Once he do this, Ardamax will start recoring and sending logs to your website.
I suggest emailing people and giving them the file, or upload it in forums. Of course you have to put (infect) Ardamax in a file that people are interested to download.
If they decide to scan the file at www.virustotal.com, they will know it's infected, though only "Webwasher-Gateway" detect Ardamax in the file as "Riskware.Ardamax.K.Gen" and "Ikarus" detect "Trojan-Dropper.Win32.Agent.bnk".
"Webwasher-Gateway" is the last antivirus VirusTotal use to scan, so if that person is lasy, you should be fine.
Basically, I think people can't get rid of Ardamax unless they re-install Windows, so if you didn't put "Self Destruct" date, you will receive logs for a very long time.
How to view the logs
Very easy, again, go to www.110mb.com and log in. You'll have to click on "Access" under "File Manager". There is all the logs and the screenshot there. The one ending with .jpg are screenshots, the ones starting with "chat" are logs while the person chat, "keys" is all the keylogs, "web" are the websites visited.
You simply need to click on the log you want to see (the dates and hour are write).
Note that for some reason, you need to download the screenshots to see them (instead of clicking on the link).
That took me few hours to write, so enjoy, and give credits to: "Bambell" if ever shared.
Ha, please excuse the old dead links of letware
Wednesday, March 5, 2008
Tuesday, March 4, 2008
Google Hacking: Ten Security Searches That Work
This chapter is excerpted from the book titled "Google Hacking for Penetration Testers" by Johnny Long, Ed Skoudis; Published by Syngress; ISBN: 1931836361; Published: June 2001; Copyright; Pages: 528
Chapter 7 – Ten Simple Security Searches That Work
Solutions in this Chapter:
Site
intitle:index.of
error | warning
login | logon
username | userid | employee.ID | “your username is”
password | passcode | “your password is”
admin | administrator
–ext:html –ext:htm –ext:shtml –ext:asp –ext:php
inurl:temp | inurl:tmp | inurl:backup | inurl:bak
intranet | help.desk
List of Sites
Introduction
Although we see literally hundreds of Google searches throughout this book, sometimes it’s nice to know there’s a few searches that give good results just about every time. In the context of security work, we’ll take a look at 10 searches that work fairly well during a security assessment, especially when combined with the site operator, which secures the first position in our list. As you become more and more comfortable with Google, you’ll certainly add to this list, modifying a few searches and quite possibly deleting a few, but the searches here should serve as a very nice baseline for your own top 10 list. Without further ado, let’s dig into some queries.
site
The site operator is absolutely invaluable during the information-gathering phase of an assessment. Combined with a host or domain name, this query presents results that can be overwhelming, to say the least. However, the site operator is meant to be used as a base search, not necessarily as a standalone search. Sure, it’s possible (and not entirely discouraged) to scan through every single page of results from this query, but in most cases it’s just downright impractical.
Important information can be gained from a straight-up site search, however. First, remember that Google lists results in page-ranked order. In other words, the most popular pages float to the top of the results. This means you can get a quick idea about what the rest of the Internet thinks is most worthwhile about a site. The implications of this information are varied, but at a basic level you can at least get an idea of the public image or consensus about an online presence by looking at what floats to the top. Outside the specific site search itself, it can be helpful to read into the context of links originating from other sites. If a link’s text says something to the effect of “CompanyXYZ sucks!” there’s a good chance that some discontent is breeding somewhere about CompanyXYZ.
As we saw in Chapter 5, the site search can also be used to gather information about the servers and hosts that a target hosts. Using simple reduction techniques, we can quickly get an idea about a target’s online presence. Consider the simple example of site:washingtonpost.com –site:www.washingtonpost.com shown in Figure 7.1.
This query effectively locates pages on the washingtonpost.com domain other than www.washingtonpost.com. Just from a first pass, Figure 7.1 shows three other domains: yp.washingtonpost.com, eg.washingtonpost.com, and topics.washingtonpost.com. Although one result lists washingtonpost.com as a server name (without the www prefix), a DNS lookup quickly reveals that it points to the same IP as washingtonpost.com, as expected. Google might be perfectly suited for performing reconnaissance, but it’s always a good idea to validate your Google findings whenever possible.
intitle:index.of
intitle:index.of is the universal search for directory listings. In most cases, this search applies only to Apache-based servers, but due to the overwhelming number of Apache-derived Web servers on the Internet, there’s a good chance that the server you’re profiling will be Apache-based. Regardless, directory listings are chock-full of juicy details, as we saw in Chapter 3. Firing an intitle:index.of query against a target is fast and easy and could produce a killer payoff.
error | warning
As we’ve seen throughout this book, error messages can reveal a great deal of information about a target. Often overlooked, error messages can provide insight into the application or operating system software a target is running, the architecture of the network the target is on, information about users on the system, and much more. Not only are error messages informative, they are prolific. A query of intitle:error results in over 55 million results, as shown in Figure 7.2.
Unfortunately, some error messages don’t actually display the word error, as shown in the SQL located with a query of “access denied for user”“using password” shown in Figure 7.3.
This error page reveals usernames, filenames, path information, IP addresses, and line numbers, yet the word error does not occur anywhere on the page. Nearly as prolific as error messages, warning messages can be generated from application programs. In some cases, however, the word warning is specifically written into the text of a page to alert the Web user that something important has happened or is about to happen. Regardless of how they are generated, pages containing these words may be of interest during an assessment, as long as you don’t mind teasing out the results a bit.
login | logon
As we’ll see in Chapter 8, a login portal is a “front door” to a Web site. Login portals can reveal the software and operating system of a target, and in many cases “self-help” documentation is linked from the main page of a login portal. These documents are designed to assist users who run into problems during the login process. Whether the user has forgotten his or her password or even user-name, these documents can provide clues that might help an attacker, or in our case a security tester, gain access to the site.
Many times, documentation linked from login portals lists e-mail addresses, phone numbers, or URLs of human assistants who can help a troubled user regain lost access. These assistants, or help desk operators, are perfect targets for a social engineering attack. Even the smallest security testing team should not be without a social engineering whiz who could talk an Eskimo out of his thermal boxer shorts. The vast majority of all security systems has one common weakest link:a human behind a keyboard. The words login and logon are widely used on the Internet, occurring on over 12 million pages, as shown in Figure 7.4.
Notice that the very first result for this query shows the words login trouble in the text of the page. This link provides help to users who have forgotten their login credentials. It’s exactly these types of links that security testers might use to gain access to a system.
username | userid |
employee.ID | “your username is”
As we’ll see in Chapter 9, there are many different ways to obtain a username from a target system. Even though a username is the less important half of most authentication mechanisms, it should at least be marginally protected from outsiders. Figure 7.5 shows that even sites that reveal very little information in the face of a barrage of probing Google queries return many potentially interesting results to this query. To avoid implying anything negative about the target used in this example, some details of the figure have been edited.
The mere existence of the word username in a result is not indicative of a vulnerability, but results from this query provide a starting point for an attacker. Since there’s no good reason to remove derivations of the word username from a site you protect, why not rely on this common set of words to at least get a foothold during an assessment?
password | passcode | “your password is”
The word password is so common on the Internet, there are over 73 million results for this one-word query. Launching a query for derivations of this word makes little sense unless you actually combine that search with the site operator.
During an assessment, it’s very likely that results for this query combined with a site operator will include pages that provide help to users who have forgotten their passwords. In some cases, this query will locate pages that provide policy information about the creation of a password. This type of information can be used in an intelligent-guessing or even a brute-force campaign against a password field.
Despite how this query looks, it’s quite uncommon for this type of query to return actual passwords. Passwords do exist on the Web, but this query isn’t well suited for locating them. (We’ll look at queries to locate password in Chapter 9.) Like the login portal and username queries, this query can provide an informational foothold into a system. Although this query is somewhat useless without the site operator, Figure 7.6 shows that the first hit for this query is a “forgotten password” page—exactly the type of page that can be informative.
admin | administrator
The word administrator is often used to describe the person in control of a network or system. There are so many references to the word on the Web that a query for admin | administrator weighs in at over 15 million results. This suggests that these words will likely be referenced on a site you’re charged with assessing. However, the value of these and other words in a query does not lie in the number of results but in the contextual relevance of the words. In this case, the word administrator is used in several common ways, each of which can provide relevance during an assessment. For example, the word administrator is referenced in many error messages as shown in Figure 7.7.
The phrase Contact your system administrator is a fairly common phrase on the Web, as are several basic derivations. A query such as “please contact your * administrator” will return results that reference local, company, site, department, server, system, network, database, e-mail, and even tennis administrators. If a Web user is told to contact an administrator, odds are that there’s data of at least moderate importance to a security tester.
The word administrator can also be used to locate administrative login pages, or login portals. (We’ll take a closer look at login portal detection in Chapter 8.) A query for “administrative login” returns 150,000 results, many of which are administrative login pages. A security tester can profile Web servers using seemingly insignificant clues found on these types of login pages. Most login portals provide clues to an attacker about what software is in use on the server and act as a magnet, drawing attackers who are armed with an exploit for that particular type of software. Remember that Google performs autostemming; a search for “admin login” returns approximately 1.3 million results, including results that were autostemmed to include the phrase administrator login. As shown in Figure 7.8, many of the results are for administrative login pages.
Another interesting use of the administrator derivations is to search for them in the URL of a page using an inurl search. If the word admin is found in the hostname, a directory name, or a filename within a URL, there’s a decent chance that the URL has some administrative function, making it interesting from a security standpoint.
-ext:html –ext:htm –ext:shtml –ext:asp –ext:php
The –ext:html –ext:htm –ext:shtml –ext:asp –ext:php query uses ext, a synonym for the filetype operator, and is a negative query. It returns no results when used alone and should be combined with a site operator to work properly. The idea behind this query is to exclude some of the most common Internet file types in an attempt to find files that might be more interesting for our purposes.
As you’ll see through this book, there are certainly lots of HTML, PHP, and ASP pages that reveal interesting information, but this chapter is about cutting to the chase, and that’s what this query attempts to do. The documents returned by this search often have great potential for document grinding, which we’ll explore in more detail in Chapter 10.The file extensions used in this search were selected very carefully. First, www.filext.com (one of the Internet’s best resources for all known file extensions) was consulted to obtain a list of every known file extension. Each entry in the list of over 8000 file extensions was converted into a Google query using the filetype operator. For example, if we wanted to search for the PDF extension, we might use a query like filetype:PDF PDF to get the number of known results on the Internet.This type of Google query was performed for each and every known file extension from filext.com, which can take quite some time, considering that the Google API key only allows 1000 searches per day. Once the results were gathered, they were sorted in descending order by the number of hits.
By adding a common file extension used on this site, after a few pages of mediocre results we discover a page full of interesting information. Result line 1 reveals that the site supports the HTTPS protocol, a secured version of HTTP used to protect sensitive information. The mere existence of the HTTPS protocol often indicates that this server houses something worth protecting. Result line 1 also reveals several nested subdirectories (/research/files/summaries) that could be explored or traversed to located other information. This same line also reveals the existence of a PDF document dated the first quarter of 2003.
Result line 2 reveals the existence of what is most likely a development server named DEV. This server also contains subdirectories (/events/archives/strategiesNAM2003) that could be traversed to uncover more information. One of the subdirectory names, strategiesNAM2003, contains a the string 2003, most likely a reference to the year 2003. Using the incremental substitution technique discussed in Chapter 3, it’s possible to modify the year in this directory name to uncover similarly named directories. Result line 2 also reveals the existence of an attendee list that could be used to discover usernames, e-mail addresses, and so on.
Result line 3 reveals another machine name, JOBS, which contains a ColdFusion application that accepts parameters. Depending on the nature and security of this application, an attack based on user input might be possible. Result line 4 reveals new directory names, /help/emp, which could be traversed or fed into other third-party assessment applications.
The results continue, but the point is that once common, purposefully placed files are removed from a search, interesting information tends to float to the top. This type of reduction can save an attacker or a security technician a good deal of time in assessing a target.
inurl:temp | inurl:tmp | inurl:backup | inurl:bak
The inurl:temp | inurl:tmp | inurl:backup | inurl:bak query, combined with the site operator, searches for temporary or backup files or directories on a server. Although there are many possible naming conventions for temporary or backup files, this search focuses on the most common terms. Since this search uses the inurl operator, it will also locate files that contain these terms as file extensions, such as index.html.bak, for example. Modifying this search to focus on file extensions is tricky because this requires OR’ing the filetype operator (which is often flaky, since filetype also requires a search term that gets lost in the mess of ORs) and also limits our search, leaving out temporary or backup directories.
intranet | help.desk
The term intranet, despite more specific technical meanings, has become a generic term that describes a network confined to a small group. In most cases the term intranet describes a closed or private network, unavailable to the general public. However, many sites have configured portals that allow access to an intranet from the Internet, bringing this typically closed network one step closer to potential attackers.
In rare cases, private intranets have been discovered on the public Internet due to a network device misconfiguration. In these cases, network administrators were completely unaware that their private networks were accessible to anyone via the Internet. Most often, an Internet-connected intranet is only partially accessible from the outside. In these cases, filters are employed that only allow access to certain pages from specific addresses, presumably inside a facility or campus. There are two major problems with this type of configuration. First, it’s an administrative nightmare to keep track of the access rights of specific pages. Second, this is not true access control. This type of restriction can be bypassed very easily if an attacker gains access to a local proxy server, bounces a request off a local misconfigured Web server, or simply compromises a machine on the same network as trusted intranet users. Unfortunately, it’s nearly impossible to provide a responsible example of this technique in action. Each example we considered for this section was too easy for an attacker to reconstruct with a few simple Google queries.
Help desks have a bad reputation of being, well, too helpful. Since the inception of help desks, hackers have been donning alternate personalities in an attempt to gain sensitive information from unsuspecting technicians. Recently, help desk procedures have started to address the hacker threat by insisting that technicians validate callers before attempting to assist them. Most help desk workers will (or should) ask for identifying information such as usernames, Social Security numbers, employee numbers, and even PIN numbers to properly validate callers’ identities. Some procedures are better than others, but for the most part, today’s help desk technicians are at least aware of the potential threat that is posed by an imposter.
In Chapter 4, we discussed ways Google can be used to harvest the identification information a help desk may require, but the intranet | help.desk query is designed not to bypass help desk procedures but rather to locate pages describing help desk procedures. When this query is combined with a site search, the results could indicate the location of a help desk (Web page, telephone number, or the like), the information that might be requested by help desk technicians (which an attacker could gather before calling), and in many cases links that describe troubleshooting procedures. Self-help documentation is often rather verbose, and a crafty attacker can use the information in these documents to profile a target network or server. There are exceptions to every rule, but odds are that this query, combined with the site operator, will dig up information about a target that can feed a future attack.
Summary
There’s no such thing as the perfect list, but these 10 searches should serve you well as you seek to compile your own list of killer searches. It’s important to realize that a search that works against one target might not work well against other targets. Keep track of the searches that work for you, and try to reach some common ground about what works and what doesn’t. Automated tools, discussed in Chapters 11 and 12, can be used to feed longer lists of Google queries such as those found in the Google Hacking Database, but in some cases, simpler might be better. If you’re having trouble finding common ground in some queries that work for you, don’t hesitate to keep them in a list for use in one of the automated tools we’ll discuss later.
Solutions Fast Track
site
The site operator is great for trolling through all the content Google has gathered for a target.
This operator is used in conjunction with many of the other queries presented here to narrow the focus of the search to one target.
intitle:index.of
The universal search for Apache-style directory listings.
Directory listings provide a wealth of information for an attacker.
error | warning
Error messages are also very revealing in just about every context.
In some cases, warning text can provide important insight into the behind-the-scenes code used by a target.
login | logon
This query locates login portals fairly effectively.
It can also be used to harvest usernames and troubleshooting
procedures.
username | userid | employee.ID | “your username is”
This is one of the most generic searches for username harvesting.
In cases where this query does not reveal usernames, the context around these words can reveal procedural information an attacker can use in later offensive action.
password | passcode | “your password is”
This query reflects common uses of the word password.
This query can reveal documents describing login procedures, password change procedures, and clues about password policies in use on the target.
admin | administrator
Using the two most common terms for the owner or maintainer of a site, this query can also be used to reveal procedural information (“contact your administrator”) and even admin login portals.
ext:html –ext:htm –ext:shtml –ext:asp –ext:php
This query, when combined with the site operator, gets the most common files out of the way to reveal more interesting documents.
This query should be modified to reduce other common file types on a target-by-target basis.
inurl:temp | inurl:tmp | inurl:backup | inurl:bak
This query locates backup or temporary files and directories.
intranet | help.desk
Chapter 7 – Ten Simple Security Searches That Work
Solutions in this Chapter:
Site
intitle:index.of
error | warning
login | logon
username | userid | employee.ID | “your username is”
password | passcode | “your password is”
admin | administrator
–ext:html –ext:htm –ext:shtml –ext:asp –ext:php
inurl:temp | inurl:tmp | inurl:backup | inurl:bak
intranet | help.desk
List of Sites
Introduction
Although we see literally hundreds of Google searches throughout this book, sometimes it’s nice to know there’s a few searches that give good results just about every time. In the context of security work, we’ll take a look at 10 searches that work fairly well during a security assessment, especially when combined with the site operator, which secures the first position in our list. As you become more and more comfortable with Google, you’ll certainly add to this list, modifying a few searches and quite possibly deleting a few, but the searches here should serve as a very nice baseline for your own top 10 list. Without further ado, let’s dig into some queries.
site
The site operator is absolutely invaluable during the information-gathering phase of an assessment. Combined with a host or domain name, this query presents results that can be overwhelming, to say the least. However, the site operator is meant to be used as a base search, not necessarily as a standalone search. Sure, it’s possible (and not entirely discouraged) to scan through every single page of results from this query, but in most cases it’s just downright impractical.
Important information can be gained from a straight-up site search, however. First, remember that Google lists results in page-ranked order. In other words, the most popular pages float to the top of the results. This means you can get a quick idea about what the rest of the Internet thinks is most worthwhile about a site. The implications of this information are varied, but at a basic level you can at least get an idea of the public image or consensus about an online presence by looking at what floats to the top. Outside the specific site search itself, it can be helpful to read into the context of links originating from other sites. If a link’s text says something to the effect of “CompanyXYZ sucks!” there’s a good chance that some discontent is breeding somewhere about CompanyXYZ.
As we saw in Chapter 5, the site search can also be used to gather information about the servers and hosts that a target hosts. Using simple reduction techniques, we can quickly get an idea about a target’s online presence. Consider the simple example of site:washingtonpost.com –site:www.washingtonpost.com shown in Figure 7.1.
This query effectively locates pages on the washingtonpost.com domain other than www.washingtonpost.com. Just from a first pass, Figure 7.1 shows three other domains: yp.washingtonpost.com, eg.washingtonpost.com, and topics.washingtonpost.com. Although one result lists washingtonpost.com as a server name (without the www prefix), a DNS lookup quickly reveals that it points to the same IP as washingtonpost.com, as expected. Google might be perfectly suited for performing reconnaissance, but it’s always a good idea to validate your Google findings whenever possible.
intitle:index.of
intitle:index.of is the universal search for directory listings. In most cases, this search applies only to Apache-based servers, but due to the overwhelming number of Apache-derived Web servers on the Internet, there’s a good chance that the server you’re profiling will be Apache-based. Regardless, directory listings are chock-full of juicy details, as we saw in Chapter 3. Firing an intitle:index.of query against a target is fast and easy and could produce a killer payoff.
error | warning
As we’ve seen throughout this book, error messages can reveal a great deal of information about a target. Often overlooked, error messages can provide insight into the application or operating system software a target is running, the architecture of the network the target is on, information about users on the system, and much more. Not only are error messages informative, they are prolific. A query of intitle:error results in over 55 million results, as shown in Figure 7.2.
Unfortunately, some error messages don’t actually display the word error, as shown in the SQL located with a query of “access denied for user”“using password” shown in Figure 7.3.
This error page reveals usernames, filenames, path information, IP addresses, and line numbers, yet the word error does not occur anywhere on the page. Nearly as prolific as error messages, warning messages can be generated from application programs. In some cases, however, the word warning is specifically written into the text of a page to alert the Web user that something important has happened or is about to happen. Regardless of how they are generated, pages containing these words may be of interest during an assessment, as long as you don’t mind teasing out the results a bit.
login | logon
As we’ll see in Chapter 8, a login portal is a “front door” to a Web site. Login portals can reveal the software and operating system of a target, and in many cases “self-help” documentation is linked from the main page of a login portal. These documents are designed to assist users who run into problems during the login process. Whether the user has forgotten his or her password or even user-name, these documents can provide clues that might help an attacker, or in our case a security tester, gain access to the site.
Many times, documentation linked from login portals lists e-mail addresses, phone numbers, or URLs of human assistants who can help a troubled user regain lost access. These assistants, or help desk operators, are perfect targets for a social engineering attack. Even the smallest security testing team should not be without a social engineering whiz who could talk an Eskimo out of his thermal boxer shorts. The vast majority of all security systems has one common weakest link:a human behind a keyboard. The words login and logon are widely used on the Internet, occurring on over 12 million pages, as shown in Figure 7.4.
Notice that the very first result for this query shows the words login trouble in the text of the page. This link provides help to users who have forgotten their login credentials. It’s exactly these types of links that security testers might use to gain access to a system.
username | userid |
employee.ID | “your username is”
As we’ll see in Chapter 9, there are many different ways to obtain a username from a target system. Even though a username is the less important half of most authentication mechanisms, it should at least be marginally protected from outsiders. Figure 7.5 shows that even sites that reveal very little information in the face of a barrage of probing Google queries return many potentially interesting results to this query. To avoid implying anything negative about the target used in this example, some details of the figure have been edited.
The mere existence of the word username in a result is not indicative of a vulnerability, but results from this query provide a starting point for an attacker. Since there’s no good reason to remove derivations of the word username from a site you protect, why not rely on this common set of words to at least get a foothold during an assessment?
password | passcode | “your password is”
The word password is so common on the Internet, there are over 73 million results for this one-word query. Launching a query for derivations of this word makes little sense unless you actually combine that search with the site operator.
During an assessment, it’s very likely that results for this query combined with a site operator will include pages that provide help to users who have forgotten their passwords. In some cases, this query will locate pages that provide policy information about the creation of a password. This type of information can be used in an intelligent-guessing or even a brute-force campaign against a password field.
Despite how this query looks, it’s quite uncommon for this type of query to return actual passwords. Passwords do exist on the Web, but this query isn’t well suited for locating them. (We’ll look at queries to locate password in Chapter 9.) Like the login portal and username queries, this query can provide an informational foothold into a system. Although this query is somewhat useless without the site operator, Figure 7.6 shows that the first hit for this query is a “forgotten password” page—exactly the type of page that can be informative.
admin | administrator
The word administrator is often used to describe the person in control of a network or system. There are so many references to the word on the Web that a query for admin | administrator weighs in at over 15 million results. This suggests that these words will likely be referenced on a site you’re charged with assessing. However, the value of these and other words in a query does not lie in the number of results but in the contextual relevance of the words. In this case, the word administrator is used in several common ways, each of which can provide relevance during an assessment. For example, the word administrator is referenced in many error messages as shown in Figure 7.7.
The phrase Contact your system administrator is a fairly common phrase on the Web, as are several basic derivations. A query such as “please contact your * administrator” will return results that reference local, company, site, department, server, system, network, database, e-mail, and even tennis administrators. If a Web user is told to contact an administrator, odds are that there’s data of at least moderate importance to a security tester.
The word administrator can also be used to locate administrative login pages, or login portals. (We’ll take a closer look at login portal detection in Chapter 8.) A query for “administrative login” returns 150,000 results, many of which are administrative login pages. A security tester can profile Web servers using seemingly insignificant clues found on these types of login pages. Most login portals provide clues to an attacker about what software is in use on the server and act as a magnet, drawing attackers who are armed with an exploit for that particular type of software. Remember that Google performs autostemming; a search for “admin login” returns approximately 1.3 million results, including results that were autostemmed to include the phrase administrator login. As shown in Figure 7.8, many of the results are for administrative login pages.
Another interesting use of the administrator derivations is to search for them in the URL of a page using an inurl search. If the word admin is found in the hostname, a directory name, or a filename within a URL, there’s a decent chance that the URL has some administrative function, making it interesting from a security standpoint.
-ext:html –ext:htm –ext:shtml –ext:asp –ext:php
The –ext:html –ext:htm –ext:shtml –ext:asp –ext:php query uses ext, a synonym for the filetype operator, and is a negative query. It returns no results when used alone and should be combined with a site operator to work properly. The idea behind this query is to exclude some of the most common Internet file types in an attempt to find files that might be more interesting for our purposes.
As you’ll see through this book, there are certainly lots of HTML, PHP, and ASP pages that reveal interesting information, but this chapter is about cutting to the chase, and that’s what this query attempts to do. The documents returned by this search often have great potential for document grinding, which we’ll explore in more detail in Chapter 10.The file extensions used in this search were selected very carefully. First, www.filext.com (one of the Internet’s best resources for all known file extensions) was consulted to obtain a list of every known file extension. Each entry in the list of over 8000 file extensions was converted into a Google query using the filetype operator. For example, if we wanted to search for the PDF extension, we might use a query like filetype:PDF PDF to get the number of known results on the Internet.This type of Google query was performed for each and every known file extension from filext.com, which can take quite some time, considering that the Google API key only allows 1000 searches per day. Once the results were gathered, they were sorted in descending order by the number of hits.
By adding a common file extension used on this site, after a few pages of mediocre results we discover a page full of interesting information. Result line 1 reveals that the site supports the HTTPS protocol, a secured version of HTTP used to protect sensitive information. The mere existence of the HTTPS protocol often indicates that this server houses something worth protecting. Result line 1 also reveals several nested subdirectories (/research/files/summaries) that could be explored or traversed to located other information. This same line also reveals the existence of a PDF document dated the first quarter of 2003.
Result line 2 reveals the existence of what is most likely a development server named DEV. This server also contains subdirectories (/events/archives/strategiesNAM2003) that could be traversed to uncover more information. One of the subdirectory names, strategiesNAM2003, contains a the string 2003, most likely a reference to the year 2003. Using the incremental substitution technique discussed in Chapter 3, it’s possible to modify the year in this directory name to uncover similarly named directories. Result line 2 also reveals the existence of an attendee list that could be used to discover usernames, e-mail addresses, and so on.
Result line 3 reveals another machine name, JOBS, which contains a ColdFusion application that accepts parameters. Depending on the nature and security of this application, an attack based on user input might be possible. Result line 4 reveals new directory names, /help/emp, which could be traversed or fed into other third-party assessment applications.
The results continue, but the point is that once common, purposefully placed files are removed from a search, interesting information tends to float to the top. This type of reduction can save an attacker or a security technician a good deal of time in assessing a target.
inurl:temp | inurl:tmp | inurl:backup | inurl:bak
The inurl:temp | inurl:tmp | inurl:backup | inurl:bak query, combined with the site operator, searches for temporary or backup files or directories on a server. Although there are many possible naming conventions for temporary or backup files, this search focuses on the most common terms. Since this search uses the inurl operator, it will also locate files that contain these terms as file extensions, such as index.html.bak, for example. Modifying this search to focus on file extensions is tricky because this requires OR’ing the filetype operator (which is often flaky, since filetype also requires a search term that gets lost in the mess of ORs) and also limits our search, leaving out temporary or backup directories.
intranet | help.desk
The term intranet, despite more specific technical meanings, has become a generic term that describes a network confined to a small group. In most cases the term intranet describes a closed or private network, unavailable to the general public. However, many sites have configured portals that allow access to an intranet from the Internet, bringing this typically closed network one step closer to potential attackers.
In rare cases, private intranets have been discovered on the public Internet due to a network device misconfiguration. In these cases, network administrators were completely unaware that their private networks were accessible to anyone via the Internet. Most often, an Internet-connected intranet is only partially accessible from the outside. In these cases, filters are employed that only allow access to certain pages from specific addresses, presumably inside a facility or campus. There are two major problems with this type of configuration. First, it’s an administrative nightmare to keep track of the access rights of specific pages. Second, this is not true access control. This type of restriction can be bypassed very easily if an attacker gains access to a local proxy server, bounces a request off a local misconfigured Web server, or simply compromises a machine on the same network as trusted intranet users. Unfortunately, it’s nearly impossible to provide a responsible example of this technique in action. Each example we considered for this section was too easy for an attacker to reconstruct with a few simple Google queries.
Help desks have a bad reputation of being, well, too helpful. Since the inception of help desks, hackers have been donning alternate personalities in an attempt to gain sensitive information from unsuspecting technicians. Recently, help desk procedures have started to address the hacker threat by insisting that technicians validate callers before attempting to assist them. Most help desk workers will (or should) ask for identifying information such as usernames, Social Security numbers, employee numbers, and even PIN numbers to properly validate callers’ identities. Some procedures are better than others, but for the most part, today’s help desk technicians are at least aware of the potential threat that is posed by an imposter.
In Chapter 4, we discussed ways Google can be used to harvest the identification information a help desk may require, but the intranet | help.desk query is designed not to bypass help desk procedures but rather to locate pages describing help desk procedures. When this query is combined with a site search, the results could indicate the location of a help desk (Web page, telephone number, or the like), the information that might be requested by help desk technicians (which an attacker could gather before calling), and in many cases links that describe troubleshooting procedures. Self-help documentation is often rather verbose, and a crafty attacker can use the information in these documents to profile a target network or server. There are exceptions to every rule, but odds are that this query, combined with the site operator, will dig up information about a target that can feed a future attack.
Summary
There’s no such thing as the perfect list, but these 10 searches should serve you well as you seek to compile your own list of killer searches. It’s important to realize that a search that works against one target might not work well against other targets. Keep track of the searches that work for you, and try to reach some common ground about what works and what doesn’t. Automated tools, discussed in Chapters 11 and 12, can be used to feed longer lists of Google queries such as those found in the Google Hacking Database, but in some cases, simpler might be better. If you’re having trouble finding common ground in some queries that work for you, don’t hesitate to keep them in a list for use in one of the automated tools we’ll discuss later.
Solutions Fast Track
site
The site operator is great for trolling through all the content Google has gathered for a target.
This operator is used in conjunction with many of the other queries presented here to narrow the focus of the search to one target.
intitle:index.of
The universal search for Apache-style directory listings.
Directory listings provide a wealth of information for an attacker.
error | warning
Error messages are also very revealing in just about every context.
In some cases, warning text can provide important insight into the behind-the-scenes code used by a target.
login | logon
This query locates login portals fairly effectively.
It can also be used to harvest usernames and troubleshooting
procedures.
username | userid | employee.ID | “your username is”
This is one of the most generic searches for username harvesting.
In cases where this query does not reveal usernames, the context around these words can reveal procedural information an attacker can use in later offensive action.
password | passcode | “your password is”
This query reflects common uses of the word password.
This query can reveal documents describing login procedures, password change procedures, and clues about password policies in use on the target.
admin | administrator
Using the two most common terms for the owner or maintainer of a site, this query can also be used to reveal procedural information (“contact your administrator”) and even admin login portals.
ext:html –ext:htm –ext:shtml –ext:asp –ext:php
This query, when combined with the site operator, gets the most common files out of the way to reveal more interesting documents.
This query should be modified to reduce other common file types on a target-by-target basis.
inurl:temp | inurl:tmp | inurl:backup | inurl:bak
This query locates backup or temporary files and directories.
intranet | help.desk
Friday, February 29, 2008
Man-In-The-Middle Attack
01: Introduction
02: Arp Spoofing
03: Port Stealing
04: Conclusions
---------------------------------------------------------------------------------
Introduction
The Man-In-The-Middle attack is an a very common attack but most of all really
effective, which is took in action in switched LANs.
This kind of attack can be accomplished with several types of tecniques, and
the most important are ARP Spoofing (or ARP Poisoning) and the Port Stealing.
-----------------------------------------------------------------------------[/]
ARP Spoofing
The ARO (Address Resolution Protocol) is a protocol is definitely old that
permits to obtain the MAC address of a computer from his IP address.
This protocol is used in the nets which uses the IP protocol and, in order
to send packets, uses the datalink model: as to say that the data is
incapsulated in datalink packets addressed to a certain IP and into which is
contained the MAC address of addresser, obtained as said from the ARP.
It's possible, exploiting the really low security level of this protocol,
"squeeze" in the middle of a communication between to computers (for example
an host and a gateway) and intercept each data in transit.
________ ________
| HOST A |----------(*)-------------| HOST B |
```````` | ````````
|
|
|
____|_____
| ATTACKER |
``````````
The fundamental concept is this: the ATTACKER squeeze in the line of
communication between HOST A and HOST B in an absolutely TRANSPARENT way and
can observe each packet in transit and eventually also modify them or create
new ones.
This is the new situation.
________ ________
| HOST A |----------( )-------------| HOST B |
````|``` | ```|````
| | |
| | |
| | |
| ____|_____ |
`---->-----| ATTACKER |-----<------'
``````````
As we can see all packets in transit between HOST A and HOST B pass first
from ATTACKER, who as actually the power to make anything he want to them.
A very versatile tool for this type of attack is Ettercap, which is a full
italian suite (written by ALoR and NaGa from blackhats.it) very easy to use
and which allows us to make this attack effective.
The command to be used in the case of arp spoofing attack is as follows:
# ettercap -T -M arp:remote /xxx.xxx.xxx.xxx/ /yyy.yyy.yyy.yyy/ -w results.log
Where "-T" says to ettercap to start running in textual mode, "-M arp:remote"
defines the attack type and where xxx.xxx.xxx.xxx is the HOST A ip (any
computer connected to the net) and yyy.yyy.yyy.yyy is the ip of HOST B (that
can be eventually the same gateway): the slash are important, don't forget
them.
The "-w results.log" creates a pcap file in which all packets are dumped: this
can be useful in this situation because later we could analize the dumped
infos with software like tcpdump or ethereal.
-----------------------------------------------------------------------------[/]
Port Stealing
An attack a little bit complex is the PORT Stealing: I'll threat that in a easy way,
considering that in this tutorial has been decided only to introduce you to this
kind of tecniques! An deeper tutorial may be a topic for upcoming papers
If you don't know how a switch works out, probably you'll need some preliminar
explaination.
First of all we got to say that a switch is a net device which works on ethernet
level and which comprehend only MAC addresses: the IPs doesn't know what are.
In addiction a switch is equipped of a CACHE, in which it take trace of all the
MAC addresses of encountered computers.
Let's begin the attack.
When we connect to a switch, we send an ARP packet in broadcast as to let everybody
know that we came.
When we send a packet from our computer to an HOST B the switch act in this way:
If HOST A has MAC address like AA:AA:AA:AA:AA:AA and HOST B of the type
BB:BB:BB:BB:BB:BB and between them there's a packets transit, the switch detects
the existance of these to computers connected to the net and which it works for
adding them to his cache.
The packet starts from the HOST A and inside it contains the MAC address of HOST B,
the switch detect the packet and get first of all the MAC address of HOST A and it
saves it in its cache indicating the Interface in which is connected, for example 0.
When the packet comes to HOST B, this reply with a new packet and, watching it, the
switch does the same thing as before and it adds to its cache the MAC address of
HOST B and its Interface, for example 1
Now everything is ok, and the switch detected the computers and it knows at which
Interfaces they are connected.
Now let's get on...
If we modify our MAC address, that has we know it stands in an eprom at our net
card inside (and as it comes it is programmable as we want), and we put into
the MAC address of HOST A (for example) we can start to communicate with the
switch and send new informations.
To modify the MAC address (under Linux machines) it's sufficient to operate
with the command "ifconfig".
If to start we try a command like:
# ifconfig eth0
We'll get an output like this:
eth0 Link encap:Ethernet HWaddr 00:11:22:3A:4B:5C
inet addr:192.168.1.2 Bcast:255.255.255.255 Mask:255.255.255.0
inet6 addr: fe80::211:d8ff:fe1a:6d23/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:132976 errors:0 dropped:0 overruns:0 frame:0
TX packets:149359 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:101226683 (96.5 MiB) TX bytes:24193224 (23.0 MiB)
Interrupt:185 Base address:0xc800
The field concerning the MAC address is this:
HWaddr 00:11:22:3A:4B:5C
Now nothing left than modify it's value with the string obtained during our
attack; to accomplish this it's sufficient to give this command:
# ifconfig eth0 hw ether 01:02:03:04:05:06
And the new result will be:
eth0 Link encap:Ethernet HWaddr 01:01:03:04:05:06
inet addr:192.168.1.2 Bcast:255.255.255.255 Mask:255.255.255.0
inet6 addr: fe80::211:d8ff:fe1a:6d23/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:132976 errors:0 dropped:0 overruns:0 frame:0
TX packets:149359 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:101226683 (96.5 MiB) TX bytes:24193224 (23.0 MiB)
Interrupt:185 Base address:0xc800
Now that we have "spoofed" the MAC address of victim machine we can proceed on.
The switch, seeing the same MAC address of HOST A contained in his cache but
associated to a different Interface, "thinks" that probably it has disconnected
and reconnected to another port (even if it's not like this really ) and then
it updates his table and substitute the Interface of HOST A (which previously was 0)
with the new one (that is ours, for example 2).
Now we got EFFECTIVELY stolen the port of HOST A in a absolute transparent way,
because everything stands on switch level.
This kind of attack requires a great traffic of ARP packets, that despite to that
doesn't slow down the connection because are very little packets.
Doesn't exist any way to prevent this kinds of attacks, there are only some
advanced switch (like Cisco ones) which supervise the traffic of ARP packets
in its net, and if from an host comes an excessive number of packets, it excludes
it from the traffic.
But considering that these switch are really too much expensive, in the 80-90% of
cases, our attacks will come to an end.
-----------------------------------------------------------------------------[/]
Conclusions
We have finished our short "excursus" in the world of switched nets, and if you
got a duly developed brain in order to understand the written words on this paper
probably you should understand that the proposed tecniques are really very
easy and doesn't requires lots of knowledges on net protocols, even if knowing
something more on what we're doing doesn't really should make sick
But this wasn't the purpose of this article: I just wanted to propose a quick
overview on security in LANs.
02: Arp Spoofing
03: Port Stealing
04: Conclusions
---------------------------------------------------------------------------------
Introduction
The Man-In-The-Middle attack is an a very common attack but most of all really
effective, which is took in action in switched LANs.
This kind of attack can be accomplished with several types of tecniques, and
the most important are ARP Spoofing (or ARP Poisoning) and the Port Stealing.
-----------------------------------------------------------------------------[/]
ARP Spoofing
The ARO (Address Resolution Protocol) is a protocol is definitely old that
permits to obtain the MAC address of a computer from his IP address.
This protocol is used in the nets which uses the IP protocol and, in order
to send packets, uses the datalink model: as to say that the data is
incapsulated in datalink packets addressed to a certain IP and into which is
contained the MAC address of addresser, obtained as said from the ARP.
It's possible, exploiting the really low security level of this protocol,
"squeeze" in the middle of a communication between to computers (for example
an host and a gateway) and intercept each data in transit.
________ ________
| HOST A |----------(*)-------------| HOST B |
```````` | ````````
|
|
|
____|_____
| ATTACKER |
``````````
The fundamental concept is this: the ATTACKER squeeze in the line of
communication between HOST A and HOST B in an absolutely TRANSPARENT way and
can observe each packet in transit and eventually also modify them or create
new ones.
This is the new situation.
________ ________
| HOST A |----------( )-------------| HOST B |
````|``` | ```|````
| | |
| | |
| | |
| ____|_____ |
`---->-----| ATTACKER |-----<------'
``````````
As we can see all packets in transit between HOST A and HOST B pass first
from ATTACKER, who as actually the power to make anything he want to them.
A very versatile tool for this type of attack is Ettercap, which is a full
italian suite (written by ALoR and NaGa from blackhats.it) very easy to use
and which allows us to make this attack effective.
The command to be used in the case of arp spoofing attack is as follows:
# ettercap -T -M arp:remote /xxx.xxx.xxx.xxx/ /yyy.yyy.yyy.yyy/ -w results.log
Where "-T" says to ettercap to start running in textual mode, "-M arp:remote"
defines the attack type and where xxx.xxx.xxx.xxx is the HOST A ip (any
computer connected to the net) and yyy.yyy.yyy.yyy is the ip of HOST B (that
can be eventually the same gateway): the slash are important, don't forget
them.
The "-w results.log" creates a pcap file in which all packets are dumped: this
can be useful in this situation because later we could analize the dumped
infos with software like tcpdump or ethereal.
-----------------------------------------------------------------------------[/]
Port Stealing
An attack a little bit complex is the PORT Stealing: I'll threat that in a easy way,
considering that in this tutorial has been decided only to introduce you to this
kind of tecniques! An deeper tutorial may be a topic for upcoming papers
If you don't know how a switch works out, probably you'll need some preliminar
explaination.
First of all we got to say that a switch is a net device which works on ethernet
level and which comprehend only MAC addresses: the IPs doesn't know what are.
In addiction a switch is equipped of a CACHE, in which it take trace of all the
MAC addresses of encountered computers.
Let's begin the attack.
When we connect to a switch, we send an ARP packet in broadcast as to let everybody
know that we came.
When we send a packet from our computer to an HOST B the switch act in this way:
If HOST A has MAC address like AA:AA:AA:AA:AA:AA and HOST B of the type
BB:BB:BB:BB:BB:BB and between them there's a packets transit, the switch detects
the existance of these to computers connected to the net and which it works for
adding them to his cache.
The packet starts from the HOST A and inside it contains the MAC address of HOST B,
the switch detect the packet and get first of all the MAC address of HOST A and it
saves it in its cache indicating the Interface in which is connected, for example 0.
When the packet comes to HOST B, this reply with a new packet and, watching it, the
switch does the same thing as before and it adds to its cache the MAC address of
HOST B and its Interface, for example 1
Now everything is ok, and the switch detected the computers and it knows at which
Interfaces they are connected.
Now let's get on...
If we modify our MAC address, that has we know it stands in an eprom at our net
card inside (and as it comes it is programmable as we want), and we put into
the MAC address of HOST A (for example) we can start to communicate with the
switch and send new informations.
To modify the MAC address (under Linux machines) it's sufficient to operate
with the command "ifconfig".
If to start we try a command like:
# ifconfig eth0
We'll get an output like this:
eth0 Link encap:Ethernet HWaddr 00:11:22:3A:4B:5C
inet addr:192.168.1.2 Bcast:255.255.255.255 Mask:255.255.255.0
inet6 addr: fe80::211:d8ff:fe1a:6d23/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:132976 errors:0 dropped:0 overruns:0 frame:0
TX packets:149359 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:101226683 (96.5 MiB) TX bytes:24193224 (23.0 MiB)
Interrupt:185 Base address:0xc800
The field concerning the MAC address is this:
HWaddr 00:11:22:3A:4B:5C
Now nothing left than modify it's value with the string obtained during our
attack; to accomplish this it's sufficient to give this command:
# ifconfig eth0 hw ether 01:02:03:04:05:06
And the new result will be:
eth0 Link encap:Ethernet HWaddr 01:01:03:04:05:06
inet addr:192.168.1.2 Bcast:255.255.255.255 Mask:255.255.255.0
inet6 addr: fe80::211:d8ff:fe1a:6d23/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:132976 errors:0 dropped:0 overruns:0 frame:0
TX packets:149359 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:101226683 (96.5 MiB) TX bytes:24193224 (23.0 MiB)
Interrupt:185 Base address:0xc800
Now that we have "spoofed" the MAC address of victim machine we can proceed on.
The switch, seeing the same MAC address of HOST A contained in his cache but
associated to a different Interface, "thinks" that probably it has disconnected
and reconnected to another port (even if it's not like this really ) and then
it updates his table and substitute the Interface of HOST A (which previously was 0)
with the new one (that is ours, for example 2).
Now we got EFFECTIVELY stolen the port of HOST A in a absolute transparent way,
because everything stands on switch level.
This kind of attack requires a great traffic of ARP packets, that despite to that
doesn't slow down the connection because are very little packets.
Doesn't exist any way to prevent this kinds of attacks, there are only some
advanced switch (like Cisco ones) which supervise the traffic of ARP packets
in its net, and if from an host comes an excessive number of packets, it excludes
it from the traffic.
But considering that these switch are really too much expensive, in the 80-90% of
cases, our attacks will come to an end.
-----------------------------------------------------------------------------[/]
Conclusions
We have finished our short "excursus" in the world of switched nets, and if you
got a duly developed brain in order to understand the written words on this paper
probably you should understand that the proposed tecniques are really very
easy and doesn't requires lots of knowledges on net protocols, even if knowing
something more on what we're doing doesn't really should make sick
But this wasn't the purpose of this article: I just wanted to propose a quick
overview on security in LANs.
Monday, February 25, 2008
Basic Info on Rootkits
What is a rootkit?
– A root kit is a set of tools used by an intruder after
cracking a computer system. These tools can help
the attacker maintain his or her access to the
system and use it for malicious purposes. Root kits
exist for a variety of operating systems such as
Linux, Solaris, and versions of Microsoft Windows
Types of rootkits
• Persistent Rootkits
A persistent rootkit is one associated with malware that activates
each time the system boots. Because such malware contain code
that must be executed automatically each system start or when a
user logs in, they must store code in a persistent store, such as the
Registry or file system, and configure a method by which the code
executes without user intervention.
• Memory-Based Rootkits
Memory-based rootkits are malware that has no persistent code and
therefore does not survive a reboot.
User-mode Rootkits
There are many methods by which rootkits attempt to evade
detection. For example, a user-mode rootkit might intercept all calls
to the Windows FindFirstFile/FindNextFile APIs, which are used by
file system exploration utilities, including Explorer and the command
prompt, to enumerate the contents of file system directories. When
an application performs a directory listing that would otherwise
return results that contain entries identifying the files associated with
the rootkit, the rootkit intercepts and modifies the output to remove
the entries.
• Kernel-mode Rootkits
Kernel-mode rootkits can be even more powerful since, not only can
they intercept the native API in kernel-mode, but they can also
directly manipulate kernel-mode data structures. A common
technique for hiding the presence of a malware process is to remove
the process from the kernel's list of active processes. Since process
management APIs rely on the contents of the list, the malware
process will not display in process management tools like Task
Manager or Process Explorer.
Popular rootkits
• AFX Rootkit 2005
• FU
• Hacker Defender
• HE4Hook
• NT Root
• NTFSHider
• NTIllusion
• Vanquish
• Winlogon Hijack
What can they hide
• Covert Channels
• Custom GINA’s
• Files and Directories
• Processes
• Registry Keys
• Services
• TCP/UPD ports
How they hide and go undetected
• Kernel Native API hooking
– SDT
• This technique is typically implemented by modifying the ServiceTable entries in the Service Descriptor
Table (SDT).
– Directly unlinking the process's EPROCESS entry from ActiveProcessLink.
• User Native API hooking
– Import Address Table (IAT) / Export Address Table (EAT)
• Each process and module(DLL) have their own Import Address Table (IAT) that contains the entry-point
addresses of the APIs that are used. These addreseses will be used whenever the process makes a call
to the repective APIs. Therefore, by replacing the entry-point address of an API (in the IAT) with that of a
replacement function, it is possible to redirect any calls to the API to the replacement function.
• Every DLL has an Export Address Table (EAT) that contains the entry-point addresses of the APIs that are
implemented within the DLL. Hence, by replacing the entry-point of an API within the EAT with the relative
address of the replacement function, we can cause GetProcAddress to return the address of the
replacement function instead.
• Dynamic Forking of Win32 EXE
– Under Windows, a process can be created in suspend mode using the CreateProcess API with the
CREATE_SUSPENDED parameter. The EXE image will be loaded into memory by Windows but
execution will not begin until the ResumeThread API is used. Before calling ResumeThread, it is
possible to read and write this process's memory space using APIs like ReadProcessMemory and
WriteProcessMemory. This makes it possible to overwrite the image of the original EXE with the image
of another EXE, thus enabling the execution of the second EXE within the memory space of the first
EXE.
• Direct Kernel Object Manipulation (DKOM) in memory
– A device driver or loadable kernel module has access to kernel memory
– A sophisticated rootkit can modify the objects directly in memory in a relatively reliable fashion to hide.
• Interrupt Descriptor Table (IDT)
– Interrupts are used to signal to the kernel that it has work to perform.
– By hooking one interrupt, a clever rootkit can filter all exported kernel functions.
Removal
• Rootkit removal tools (eg. “Unhackme” by Greatis
Software)
• Clean from another kernel (eg. Knoppix, WinPE, etc)
• Use technology that reverts back to a previous state if
your environment allows for it:
– Undo disks in Microsoft Virtual PC/Server
– Faronics Deep Freeze
– Symantec Norton GoBack
– Winternals Recovery Manager
• Once a machine has been compromised, the only true
cleaning method is to format and reload the OS!
– A root kit is a set of tools used by an intruder after
cracking a computer system. These tools can help
the attacker maintain his or her access to the
system and use it for malicious purposes. Root kits
exist for a variety of operating systems such as
Linux, Solaris, and versions of Microsoft Windows
Types of rootkits
• Persistent Rootkits
A persistent rootkit is one associated with malware that activates
each time the system boots. Because such malware contain code
that must be executed automatically each system start or when a
user logs in, they must store code in a persistent store, such as the
Registry or file system, and configure a method by which the code
executes without user intervention.
• Memory-Based Rootkits
Memory-based rootkits are malware that has no persistent code and
therefore does not survive a reboot.
User-mode Rootkits
There are many methods by which rootkits attempt to evade
detection. For example, a user-mode rootkit might intercept all calls
to the Windows FindFirstFile/FindNextFile APIs, which are used by
file system exploration utilities, including Explorer and the command
prompt, to enumerate the contents of file system directories. When
an application performs a directory listing that would otherwise
return results that contain entries identifying the files associated with
the rootkit, the rootkit intercepts and modifies the output to remove
the entries.
• Kernel-mode Rootkits
Kernel-mode rootkits can be even more powerful since, not only can
they intercept the native API in kernel-mode, but they can also
directly manipulate kernel-mode data structures. A common
technique for hiding the presence of a malware process is to remove
the process from the kernel's list of active processes. Since process
management APIs rely on the contents of the list, the malware
process will not display in process management tools like Task
Manager or Process Explorer.
Popular rootkits
• AFX Rootkit 2005
• FU
• Hacker Defender
• HE4Hook
• NT Root
• NTFSHider
• NTIllusion
• Vanquish
• Winlogon Hijack
What can they hide
• Covert Channels
• Custom GINA’s
• Files and Directories
• Processes
• Registry Keys
• Services
• TCP/UPD ports
How they hide and go undetected
• Kernel Native API hooking
– SDT
• This technique is typically implemented by modifying the ServiceTable entries in the Service Descriptor
Table (SDT).
– Directly unlinking the process's EPROCESS entry from ActiveProcessLink.
• User Native API hooking
– Import Address Table (IAT) / Export Address Table (EAT)
• Each process and module(DLL) have their own Import Address Table (IAT) that contains the entry-point
addresses of the APIs that are used. These addreseses will be used whenever the process makes a call
to the repective APIs. Therefore, by replacing the entry-point address of an API (in the IAT) with that of a
replacement function, it is possible to redirect any calls to the API to the replacement function.
• Every DLL has an Export Address Table (EAT) that contains the entry-point addresses of the APIs that are
implemented within the DLL. Hence, by replacing the entry-point of an API within the EAT with the relative
address of the replacement function, we can cause GetProcAddress to return the address of the
replacement function instead.
• Dynamic Forking of Win32 EXE
– Under Windows, a process can be created in suspend mode using the CreateProcess API with the
CREATE_SUSPENDED parameter. The EXE image will be loaded into memory by Windows but
execution will not begin until the ResumeThread API is used. Before calling ResumeThread, it is
possible to read and write this process's memory space using APIs like ReadProcessMemory and
WriteProcessMemory. This makes it possible to overwrite the image of the original EXE with the image
of another EXE, thus enabling the execution of the second EXE within the memory space of the first
EXE.
• Direct Kernel Object Manipulation (DKOM) in memory
– A device driver or loadable kernel module has access to kernel memory
– A sophisticated rootkit can modify the objects directly in memory in a relatively reliable fashion to hide.
• Interrupt Descriptor Table (IDT)
– Interrupts are used to signal to the kernel that it has work to perform.
– By hooking one interrupt, a clever rootkit can filter all exported kernel functions.
Removal
• Rootkit removal tools (eg. “Unhackme” by Greatis
Software)
• Clean from another kernel (eg. Knoppix, WinPE, etc)
• Use technology that reverts back to a previous state if
your environment allows for it:
– Undo disks in Microsoft Virtual PC/Server
– Faronics Deep Freeze
– Symantec Norton GoBack
– Winternals Recovery Manager
• Once a machine has been compromised, the only true
cleaning method is to format and reload the OS!
Subscribe to:
Posts (Atom)