BestInternetSecurity.net

Information Security Resources


Archive for the 'Application Security' Category



Google Hacking and Buffer Overflow Attacks: In the News

Friday 2 May 2008 @ 8:45 pm

Recently I spotted a piece of news about a type of network attack combining techniques we have discussed in recent articles involving Google Hacking and Buffer Overflow Attack . The incident, according to Forbes News1 involves “using Google searches to track down sites vulnerable to so-called ‘SQL injections’.”

Essentially, the hackers use Google to hunt for sites with a problem in the web server program codes and exploit them using the knowledge gained from the error messages displayed on the problem websites. In this particular case, the hackers used the SQL command to take control of the sites under attack.

(If you are interested to know about how to work safely using SQL commands, read our post about Buffer Overflow Attack here: http://www.bestinternetsecurity.net/52.)

Some security experts attribute this situation to the usage of Microsoft-related technologies in web sites, such as Microsoft’s own Internet Information Servers (IIS) and its SQL server.

“Whitehat Security’s Grossman speculates that machines running that software were targeted because they allow several commands to be injected in a single user input field on the sites they host, making those sites easier to hijack,” according to Forbes News.

However, I have a different view, and this is the same comment that I expressed in my previous post: It does not matter what technologies you are using to run your websites. What does matter is taking extra care in writing programs that use SQL commands to manage program data. If in the original program design you fail to carefully validate users’ inputs, you will open doors to possible attacks. This is especially disastrous if you fail to do so with web application programming, like in the case we are discussing now.

But as I have also said, it is extremely difficult (if not totally impossible) to write completely bullet-proof code. But to be aware of what can happen if you do not take extra steps to write code that carefully lessens the risk of attack is more than half of the battle. Read the news in the reference section to know more about this case.

Reference:

1Greenberg, A. (2008), Google-Hacking Goes To China, Forbes.com LLC, Available from: http://www.forbes.com/2008/04/28/hackers-google-china-tech-security
-cx_ag_0428hack.html?partner=yahootix
[Accessed 28 April 2008]

Tags: SQL Programming, Application Security, Google Hacking, Buffer Overflow Attack

Technorati Tags: , , , , , ,




Buffer Overflow: How does it happen?

Thursday 17 April 2008 @ 6:29 pm

Buffer Overflow refers to what happens when an area of a program’s code is overwritten with new code using the technique of inputting data longer than the length expected when the program asks for input. This creates an overflow in the program’s buffer system, and causes the program to react negatively − sometimes even resulting in system crashes. Hackers can cause buffer overflows intentionally to sabotage systems.

This overflow of data can be written to a critical program area, such as where execution code was placed. With carefully planned code overwritten in this area, a hacker can seize control of the program and, as a result, the system where the program resides.

The main reason a hacker can do this is due to negligence in the programmer’s coding. We call these types of problems “bugs” in the program. A common bug that leads to the possibility of a hacker causing a buffer overflow is when a coder neglects to include proper validation of data type and length for user input into the program.

Some common programming tools such as SQL commands allow a user to input carefully crafted responses to embed a request that triggers the program to execute a nested SQL command.

A good example of this is demonstrated in the following situation:

Consider a program that asks a user for input to find the name of a student by his or her surname. A proper input will trigger the program to successfully search the database for a match to the Surname inputted by the user, and return all records matching that surname. For example, suppose the input variable is named S_NAME. The input will execute the following SQL command:

Select * from Student_Table Where Student_Table.Name = S_NAME
This command instructs the program to locate all records with surname equal to S_NAME.

If a skilled user inputs something for S_NAME such as as “Select Surname from Student_Table”, then the program may execute the unexpected nested SQL command as:

Select * from Student_Table Where Student_Table.Name = Select Surname from Student_Table

This literally instructs the program to locate all records for all surnames in the Student_Table, and this is certainly not the original intention of the programmer who wrote the code. Depending on the subsequent codes of this program, this could possibly list all of the student names in a row − or simply crash the program, if it does not know how to handle the command.

The fact that a hacker can do this depends on three factors:

  • The hacker is an experienced SQL command writer
  • The hacker understands the underlying database structure of the program
  • The program does not exercise a careful input validation to verify the validity of the inputs

For the second factor, a hacker can come to understand the database structure in a lot of different ways. As we have noted in previous posts, most hackers are insiders of an organization. As such, they are able to gain access to related knowledge that aids in hacking. Another technique, Google hacking, is also an effective technique for hackers. (Click here to read our post on Google hacking.)

In the third factor, we’re talking about a bug in the program. If you have ever written computer programs, you probably understand that it is difficult − if not impossible − to write a bug-free program. Program input validation involves the consideration of so many exceptional input violation cases that a programmer cannot possibility foresee all of them. As long as even just one single case is missed (which usually is the case), the input process can be put into risk.

Throughout computing history, there are many examples of system exploitations by buffer overflow. Perhaps the most wide-spread example for Windows OS is one that happened in 2001, named “Code Red.”

If you are interested to know more about buffer overflow security incidents, refer to the information in Wikipedia:
http://en.wikipedia.org/wiki/Buffer_overflow

Technorati Tags: , , ,