When trial and error is a bad thing

I'm a hacker. Not the breaking into systems and doing damage hacker. To me a hacker is someone who learns things by trial and error. I will systematically poke away at something which for all intents and purpose is a black box. I hack to learn. I hack things I own. I'll create an instance of something and hack away at it. People I work with will create development, test or staging environments which I will hack.

I do not hack sites I don't own or have permission to hack. This is what differentiates good hackers and bad hackers.

What I do is poke at something. Maybe I'll try changing an input or altering the environment slightly and see how that changes things. I'll keep doing this until a pattern merges. From trying different things I start forming a hypothesis of what is happening inside the black box. If I try something and the result does not fit in my hypothesis, I form a new hypothesis. At some point I usually get a clear understanding of what is happening in the black box without ever seeing what is in the black box.

I essentially look at the symptoms and narrow down what the cause would be.

This is a good use of trial and error. The goal is not to find the input which gives me the desired output. If I stopped the moment I got the desired output, I might think I have the solution but I don't. Case in point, I input 2 and 2 and get 4. My hypothesis is that the black box does addition. At this point my hypothesis is correct. However, if I poke further I might find that inputing 2 and 3 gives me 6. Now I see that it is not addition. New hypothesis is that it is multiplication.

Hacking is really empirical. Unless I try every possible input, I cannot be certain my hypothesis is correct. For example, I might input 1 to a function and it returns 43, I input 2 and get 47, I input 3 and get 53. After inputting the numbers from 1 to 20 I notice all the numbers are prime! My hypothesis is that the function is a prime number generator. However, if I input 41 I get 1763. This is not prime (43 * 41 = 1763). Turns out the function is Euler's formula for finding prime numbers, i.e. n^2 + n + 41. This has been proven to only produce prime numbers when n is less than 40.

Still hacking can be a good thing. Trail and error to find THE answer is never a good thing.

I see a lot of people solving problems as follows:

1. Program or computer not functioning correctly.
2. Change something.
3. If program or computer not functioning correctly go to step 2.
4. Problem solved.

Now maybe they did find the right solution but most often they don't. Later the problem will come back with different symptoms. If I purchased a program from you and you used this method to solve the problem, here is how I see this as a consumer of software:

My car is running slower than normal. I bring it to my mechanic and he does the following:

1. He changes the spark plugs and charges me for that.
2. Car is still running slow.
3. He adjusts the valve on the carburetor and charges me for that.
4. Car is still running slow.
5. He rotates the tires and charges me for that.
6. Car is still running slow.
7. He changes all the fluids and charges me for that.
8. Car is still running slow.
9. Cars today have a lot of electronics, so he disconnects the battery for a week.
10. All my programming, bluetooth, radio stations, clock, GPS, etc. are gone.
11. The car is no longer running slow.
12. Three months later the car is running slow again.
13. My mechanic disconnects the battery for a week.
14. All my programming, bluetooth, radio stations, clock, GPS, etc. are gone.
15. My car is still running slow.

Would you pay for all the work the mechanic did? I think it is safe to say that NO ONE would put up with this. Some people might put up with it until step 12 then find a new mechanic. Others would put up with this until just step 2 or 4. Most of us would not pay for anything after step 2.

I've worked in industries where EVERYONE programs like this. There might be 4 or 5 different vendors and you really don't have any other choice. However, it just takes one guy to write quality software and everyone switches to that other guy. Trying to win back those customers means you have to make up for all the poor software issues PLUS give them some incentive to switch away from the guy who has always given them good software.

SQL Injection

Do you test an application which uses a database? If you do you should be testing for SQL Injection.

What is SQL Injection? It is when the input to the application allows queries to be sent to the database which the programmer did not intend. To make it more clear, here is an example.

A web application has an administrator log in which checks the username and password against an entry in a database. The user inputs:

Username: admin'; --
Password: whatever

This seems odd but harmless. Now let's look at some potential code:

statement = "SELECT * FROM users WHERE username=' + userName + "' AND password='" + passWord + "';"

Given the input from the user, the SQL statement becomes

SELECT * FROM users WHERE username='admin'; -- 'AND password='whatever';

If the administrator's username is admin then this will return the rowset for the administrator. Here is how it works. The -- in MySQL is a comment. Everything from the -- to the end of line is a comment. So the above statement might as well be:

SELECT * FROM users WHERE username='admin';

It eliminates the check for the correct password. This is a known hack and I would be DEEPLY surprised if you find this simple mistake. The solution is simple. Check the user input before sending it to the method that builds the SQL statement. We could either reject input with semicolons, SQL comments, etc. or we could escape them. That is, change the input so things like ' become \'.

You might have noticed one thing. I mentioned that -- is a comment for the MySQL database. How did I know it was the MySQL database? Maybe I didn't and I'm just guessing. Actually, as a tester I would know which database it is but as a hacker, how would I know? It is actually quite simple. Peek under the covers.

Sometimes there is information in the HTTP headers that reveals information about the technology being used at the site. Also, have a look at how data is getting sent to the server. If it is a form with POST or GET parameters, I can fake those. Let's say the HTML source code for http://my.site.com/myapp/ is:

<form action="login.action">
    <input type="hidden" name="key" value="293674"/>
    Username: <input name="username" value=""/><br/>
    Password: <input type="password" name="password" value=""/>
</form>

I can go:

http://my.site.com/myapp/login.action?key=293674&username=admin&password=wildguess

Or I could change the value of the hidden inputs until I get an error from the application server. Usually the error messages will have something in them to tell me what technology is being used. Worst case, if the site administrator is smart enough to hide the database we can use syntax that works on all databases or just try hacks we know work for MySQL in hopes you are using that.

So if there are known security flaws in your database, you want to make sure you get them patched or the software guards against them.

So how do you test for this? You could become the ultimate hacker and discover new and innovative ways to inject data into SQL queries. Or you could use some common tools for generating SQL Injections. Here is a list of possible site to start with, in no particular order:

• http://code.google.com/p/mysqloit/
• http://www.nosec.org/2009/0920/74.html
• http://sqlninja.sourceforge.net/
• http://www.sqlpowerinjector.com/index.htm
• http://www.owasp.org/index.php/Category:OWASP_SQLiX_Project

Happy hacking testing

Do hackers make good testers?

Someone on LinkedIn was asking about becoming an ethical hacker.

Back before I got into computers I understood the term hacker to mean someone who learns from trial and error. So a computer hacker was someone who tried things and remembered the results. Now if you started hacking a computer site you probably found things the average user didn't and potentially crashed the site. Because a lot of what was happening on the server was hidden from you, you had no idea what trying different things would do until you tried them. And even then you might not know what actually happened other than you lost the connection.

If I was hacking a web site or piece of software I would need to narrow things down. If I tried something I might know it will be one of four things that caused the resulting crash. If I tried something else, it might have three things in common with the first hack. If it crashed you might say that one thing that is not common to both hacks is not the crash. You'd be wrong. You're assuming there is one crash. Could be there are two different crashes. :)

Keeping your mind open like that is what is needed to be a good hacker. I picture things in terms of Venn diagrams. Overlapping areas are not important as it could be one or the other. The things which can only happen in one area are the interesting bits.

There is something about this way of thinking that makes it easy to find defects. It is almost like detective work. You have some evidence and you need to see if you can find more. You poke and probe to see what falls out. You interrogation the application under test and see what secrets it reveals. You keep track of cause and effect. I do this over a long period of time. You look for patterns.

Case in point, I was testing an application that had a load feature. There was a defect in the load routine. I filed the defect and the developer fixed it. Once I could load, I could save. A similar defect existed in the save routine. Programmers make common mistakes. Is there more than one place that programmer could make the same mistake? I always take the time to find out what the defect was (from a technical standpoint) and what was really happening.

After a while I can almost predict what errors will occur in a program.

The other trait I have and see in other good testers is curiosity. I'm always wondering why things work the way they do. Before computers I'd take apart lawnmowers, watches, bicycles, kitchen stand mixer. When my first hard drive died, took it apart. Hooked it up with the cover off to figure out what was wrong with it. Head was stuck on a scratch on the platter. Smoothed out the scratch and got the hard drive working again. Had some problems with the area I smoothed out but it worked in all other places.

When it came to understanding the Internet, Telecommunications, etc. I started reading things like RFCs, research papers at MIT, JSRs, ISO/ANSI drafts.

As I write this I am reminded of many of my students (I used to teach programming). During computer labs there was always someone who would ask me, "What would happen if I did XXX?" to which I always replied, "Try it and see." It always amazed me that most students would ask rather than just try it.

So if you want to be a good tester. Understand, Try, Hack.

Safely probing web sites

The whole recruitmenttech.com / Bernard Haldane scam thing got me using my old telnet trick to examine the contents of a website. A number of bad eggs like to use security flaws in IE or Firefox to infect your computer. Most people try to make sure the security patches are up to date. But, there is always a period of time between when a virus is released and when a security patch is released to deal with it. If you visit the wrong website during that time you could be in for trouble.

What I like to do is avoid the security flaw by using a method the virus writers are not expecting. I like to use telnet. I tend to telnet from different operating systems as well. You might not have the luxury of a dozen different OS. You could consider Vmware or some other OS emulator.

Anyways, here is how it works. I'll use telnet from MSDOS. The connection for a web browser and for telnet is pretty much the same. Telnet defaults to port 23 and web browsers default to port 80. So if I wanted to use telnet to connect to say www.blogger.com I'd use:

telnet www.blogger.com 80

At this point the MSDOS telnet program will print nothing. If you press CTRL-] you get to the telnet settings. In there enter set localecho. Press ENTER twice, once to turn on local echo and once to get out of the telnet settings. You are now back at a blank screen again. Enter:

GET / HTTP/1.1
Host: www.bogus-computer.com

NOTE: you have to press enter twice at the end. Once to send the Host: field and once to signal the end of the HTTP header.

If you take too long to type things in, the computer at the other end will timeout and hang up on you. If you type it in quickly enough you'll get something back like:

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=ISO-8859-1
Set-Cookie: PREF=ID=0df2c62f96b9ffe7:TM=1203534740:LM=1203534740:S=0L2HwAZgQbyqrbmI; expires=Fri, 19-Feb-2010 19:12:20 GMT; path=/; domain=.google.com
Server: gws
Transfer-Encoding: chunked
Date: Wed, 20 Feb 2008 19:12:20 GMT

...

There should be a lot more as well. What I'm not posting here is all the stuff between <html> and </html>. What I have posted is the HTTP response header. Your web browser eats this and uses the information. For example, the Set-Cookie: field will make the web browser set a cookie.

The GET command is a standard HTML header command. The next part, /, is the path you want to get and the HTTP/1.1 is the protocol to use. Some web servers only work with HTTP/1.0, some only work with HTTP/1.1, most will use both.

If you wanted the web site, http://en.wikipedia.org/wiki/List_of_HTTP_headers then the sequence would be:

telnet en.wikipedia.org 80
GET /wiki/List_of_HTTP_headers HTTP/1.1
Host: www.bogus-computer.com

You'll notice that I always put a Host: field. Many web servers will not respond to robots or automation. They want to know who is talking to them. So if you don't include the computer name in the header, they just hang up or send you a HTTP/1.1 403 Forbidden response. Try using telnet to www.google.com and they will refuse you. They not only want the Host: information but they expect a number of other fields as well. If you go to the http://en.wikipedia.org/wiki/List_of_HTTP_headers web page, they talk about some of the common header fields and have a link to the HTTP standard on www.w3.org.

When you get the response back, you'll have to look through the body and see if there are other references, e.g. <SCRIPT> tags, which will create more GET requests. Your web browser is often getting the first page and from there doing multiple GET commands for the contents (each <IMG> tag is a GET, running Javascript will create more GET commands, etc.).

Once you have downloaded everything you can then look at it with a text editor and see if there is anything in it which could harm your computer. If you don't know how to read Javascript, this is obviously not an option for you but as a big nerd this is what I do. :^)

Hope you enjoy this. Let me know if you have any questions.

Happy hunting!

We're not dead yet...

It has been a while since I posted to my blog. I've been fairly busy moving into my new home. I'm in now and the computer is set up. So it is time to blog again...

We have been hiring people to work in my department, Software Quality Assurance. Because our software products are development and system administrator tools, our QA staff needs to know how to program and how to validate the information our tools are providing; do you know AIX, HP-UX, Solaris, Linux (Redhat and SuSE) and Windows? Can you confirm the Disk I/O, Process, Thread, NIC, etc. information is correct? Can you write a multithread application which is guaranteed to deadlock so our tools will detect the deadlock? Can you write a J2EE application that exercises all J2EE technologies (EJB, JDBC, Servlets, JSPs, RMI, JNDI, etc.)?

These are the sort of skills the QA staff at my company possess. We interview a lot of people. Most don't have a clue about the basics. No one (myself included) had all the knowledge necessary to do the job well. So how do we do it? An ability to learn and find answers.

As we hire people, some work out but many more don't make it through the probation period; we either terminate them or they quit. I've been trying to put my finger on what the survives have that the others don't and I think I figured it out. Those who survive have a hacker mentality. One guy I hired, Jerry, found this magazine and thought it would be right up my alley. It was called alt.2600.

It has been over a decade since I hung out in alt.2600. When I saw the magazine I thought I'd point Jerry to the alt.2600 newsgroup. I was surprised to find out it was gone. I checked google.com to see if the archives were there and there was no hint of alt.2600. If you google "alt 2600" you will find the FAQ and references to the newsgroup but the newsgroup itself is gone. The last time the FAQ was updated was April 2004.

The magazine made me realize though that hackers think differently. Case in point, when Kryponite locks came out they were advertised as impossible to cut with bolt cutters. I knew someone who took 4 foot bolt cutters and tried. He bent the bolt cuts. I looked at the lock and realized the locking mechanism overlapped the Kryponite bar by 2mm. A swift whack at this point with a 2 pound hammer and the the lock popped open. Most people looked at the ad and tried to figure out how to cut the bar (the ads indicated the bar was uncuttable). I stepped back and thought, the problem is not cutting the bar. This is narrow thinking. The real problem is removing the lock from what it held. Cutting the bar was only one way to do this.

Hackers get into web sites by looking for the weak points. They don't let the requirements lead them. The login web page only lets me enter limited information; don't use the login web page. Create your own web page and set the FORM action to point to the other web site. Design your FORM so you can send more information. Do something you know will fail just to see if there is useful information in the error message. The more you can reveal about the technology the more you can determine the weak point.

When I test a piece of software I'm looking for the weak point. This ability to see things form a different point of view lets me find the bugs the developer did not see.

Is being a hacker a dying art?