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 News¹ 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:

¹Greenberg, 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: SQL injections, Buffer Overflow, web application programming, SQL Programming, Application Security, Google Hacking, Buffer Overflow Attack

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: Buffer Overflow, SQL, Google hacking, Code Red

The Domain Name System (DNS) relies on a hierarchical database system. At the top of this system sit thirteen root servers with names following the format letter.root-servers.net, where the letter ranges from A to M.

Many people mistakenly assume that there are only 13 root servers in the world. In fact, each root server notation represents a cluster of servers dispersed all over the world. Each of these is administrated by different organizations.

The cluster of servers working for a particular letter of root servers uses the routing technique of “anycasting,” according to RFC 1546¹:

“There are a number of situations in networking where a host, application, or user wishes to locate a host which supports a particular service but, if several servers support the service, does not particularly care which server is used.  Anycasting is an internetwork service which meets this need.  A host transmits a datagram to an anycast address and the internetwork is responsible for providing best effort delivery of the datagram to at least one, and preferably only one, of the servers that accept datagrams for the anycast address.”

Check out these links for a geographical mapping of the root servers’ locations:
http://www.icann.org/maps/root-servers.htm
http://www.circleid.com/posts/dns_root_servers_google_maps/ (on Google Maps)

Root servers serve as the final point of resort to resolve the Top Level Domain (TLD). For example, if your DNS servers do not know where to locate the DNS record of the “.jp” of the domain name www.jetro.go.jp, it will query the root servers to locate the DNS server taking part in the resolution of TLD “jp” and then continue the resolution of the domain “go.jp” by the DNS server referred by the root server. This domain name resolution process works recursively until it gets an authoritative answer for the requested host of the domain name www.jetro.go.jp.

In fact, DNS servers rarely query the root servers as they cache any previously resolved domain names, including those of the TLDs. Depending on a DNS server’s configuration, it usually keeps those responses in the cache for two days. Therefore, considering the example given above, the DNS server will store the DNS server information to process TLD “jp” in the cache memory, so that each query related to TLD “jp” will go directly to the DNS server handling “jp” TLD without repeatedly querying the root servers.

Perhaps the most common reason for your DNS servers to query root servers is an error in typing a non-exiting TLD. For instance, if you mistakenly type “jq” instead of “jp” in the above domain name, your DNS servers have not yet resolved any TLD of “jq”. Therefore, it has to go to the root server to check for its related information. Of course, in this case, the root server will return a non-existing error message to your DNS servers, and you are notified of the failure to locate the domain name.

As the root servers are dispersed all over the world, it is quite difficult technically to launch an attack on all of them at the same time. Therefore, it is unlikely that this robust system will stop servicing the Internet community because of common attack such as DOS (Denial of Service), even by the most well planned hacking activity. This is fortunate, since the DNS root server system is a vital part of the Internet, serving thousands or millions of people online everyday.

If you are interested to understand more about root DNS servers’ operation, go to this link for more details:
http://www.isoc.org/briefings/020/

¹ Partridge, C., Mendez, T., Milliken, Walter. (1993) Request for Comments: 1546, Network Working Group, Available from: http://rfc.net/rfc1546.html [Accessed 4 April 2008]

Tags: DNS Root Servers Attack, anycasting, TTL

Technorati Tags: Domain Name System, DNS, letter.root-servers.net, 13 root servers, RFC 1546, Top Level Domain, TLD, DOS, Denial of Service, rfc1546, DNS Root Servers Attack, anycasting, TTL

Domain Name System (DNS) is the magical ability of Internet hosts to translate the machine-readable IP address numbers like 216.109.112.135 to something meaningful to humans, like www.yahoo.com. A sophisticated hierarchical database system in the Internet is required to accomplish this task. One of the core components of that system is the DNS server, which serves as the translator. For instance, when you type the domain name http://www.yahoo.com into your favorite browser, your computer directs this request to a designated DNS server—usually provided by your Internet Service Provider (ISP)—which helps translate it to the machine-readable IP address 216.109.112.135. This enables your computer to connect your browser software to the correct web server’s website.

If you are interested in knowing the IP address(es) of your DNS server(s), you can access them using Windows 2000/XP/VISTA, by choosing Start -> Run, then typing the word “cmd” in the command window, and clicking OK.

In the command prompt window, type “ipconfig/all” and hit return. This will display a list of network connection information. For example:

From this list, you can see that the DNS server IP addresses are
217.1.32.208 and 215.251.144.126. This machine will query either one of these two DNS servers for any new domain name enquiry.

You may wonder: what if these two DNS servers return a wrong IP address for the domain name you specified? If this happens, you will be re-directed to a wrong site—even though you have typed the correct domain name in your browser.

And this is exactly what a hacker can do. If a hacker attacks a DNS server and maliciously corrupts the information in the DNS server’s database, then all the hosts that rely on this DNS server for domain name resolution could be misdirected to a wrong Internet sever.

This enables the hacker to hijack the Internet connection of the victims. For example, a hacker could re-direct an Internet banking site’s domain name to his or her own server and lure visitors to key in their private login information into this fake website. This allows the hacker to steal this information for the purpose of committing crimes such as identity theft.

Another type of attack involves using similar domain names like paypal.com and paypa1.com. Can you tell the difference between these two domain names? No, we didn’t make a typo! Actually, the first “paypal” ends with a lower-case “l” (L), and the second one ends with the numeral “1” (ONE). In this scenario, the attacker uses various tricks like scam emails to lure the visitors to click a deceptive link in order to direct visitors to their own fake site and obtain private login information as in the first example. The term “phishing” has been coined to describe this type of security breach.

Perhaps the solution to counter these problems is user education. Internet users should be made aware that these kinds of attacks are possible, and learn how to determine that the sites that they are visiting are genuine ones.

Usually, for a website to perform the authentication information exchange with a visitor, such as asking for a visitor’s login information, it will initiate a popular Internet secure communication method called SSL (Secure Socket Layer). You can determine that the website is using this secure method by looking at the address in the address bar: the “https.” part of the address will automatically change to “https.” At that moment, the web server opens an encrypted communication with the visitor by providing its server certificate to your computer. This server certificate can be viewed in your browser by clicking the “padlock” sign. It is usually at the lower right corner (Internet Explorer version 6 and Firefox) or upper right corner beside the address bar (Internet Explorer version 7) of your browser.

If the site is genuine, you can clearly see the site’s URL along with the certificate authority that issues the server certificate (two common certificate authorities are Verisign or Thawte).

Take a look at the well-known Internet banking website, Citicorp. When you pull up the Citicorp banking login screen, click on the padlock as described above to display the website’s certificate. Note that this one is issued by Verisign.

If you click on the option “View certificates” you can view more detailed information of this server certificate:

Here you can verify that the certificate is of the domain “citibank.com” and the certificate has not yet expired.

After completing validation process, you can now safely enter your login information with confidence, because the site is very unlikely a fake site. If you following these steps every time you access a secure web site, you can avoid becoming the victim of a DNS attack.

Tags: Domain Name Server, identity theft hacking

Technorati Tags: DNS, DNS server, ipconfig, domain name resolution, identity theft, phishing, SSL, Secure Socket Layer, https, server certificate, certificate authority, Verisign, Thawte, DNS attack, Domain Name Server, identity theft hacking

One information that is truly important when conducting Cryptographic Attack, it is: the nature of the plaintext. Is it a sentence of a particular language? or is it of some software code? If we know the fudemental nature of the plaintext, then our code breaking job could be a bit easier.

If it is of a commonly used language, then we can use the very unique characterisitc of that language to help deducing the plaintext. One popular method is frequency analysis. In the languages of latin origin, we know that certain alphabets are of higher freqency of appearance than others.
In English, we should know that the vowels - ‘a’, ‘e’, ,’i', ‘o’, ‘u’ appear more often than other alphabets.

And if we run analysis of a particular language long enough, we can deduce a table of relative frequency of each alphabet appearing in that language.

So if a particular language message is encrypted using substitution method like Caesar Cipher, we can easily break the code using frequency analysis if we know the original language used in the plaintext.

Technorati Tags: Cryptographic Attack, frequency analysis, Caesar Cipher