An anti-hacking guide

 Hackers are kindred of expert programmers who believe in freedom and spirit of mutual help. They are not malicious. They may be tied to the common belief described aptly by the modern Zen poem stating: To follow the path: look to the master, follow the master, walk with the master, see through the master, become the master.

 The malicious individuals who break into programs and systems in order to do damage or to steal something are referred to as crackers or attackers. Most attackers are not highly skilled, but take advantage of published exploit code and known techniques to do their damage.  Most attackers are not as highly skilled as hackers are, they take advantage of published exploits. Such people who use published code to attack software and computer systems are called script kiddies.

 The new Boeing 787 Dreamliner aircraft provides on board internet access to its passengers but concerns were raised about the fact that the flight’s controls were connected to the same network serving internet access to the passengers! What could it mean?  What if an Iraqi or Afghan hacker breaks open the networks at Pentagon’s missile stations?  Or talking about something that’s close to our chores, what if we leave loopholes in the SPFS codebase which may be exploited to crack the Core Billing Manager? What would it mean to the company that deploys the CBM application?

 There are numerous ways an attacker may break applications apart. We’ll take two specifically notorious and very widely used techniques of exploiting software, namely:  SQL Injection  Buffer Overflows

 SQL injection is a technique that exploits a security vulnerability occurring in the database layer of an application.  When an end user is asked for his/her credentials an attacker may inject malicious queries into the database if user input is not strongly typed.

 How would the code for checking the username in the login prompt look like? statement := "SELECT * FROM users WHERE name = '" + userName + "';“  Do you see anything wrong with this SQL code?  Is it vulnerable?

 NO?  What if an attacker entered the following username? a' or 't'='t  In the original query the completed entry would look something like, SELECT * FROM users WHERE name = 'a' OR 't'='t';  Do you think this username will ever be wrong?

 And what if a certain noble human being entered the following username? ‘ OR 1=1;DROP TABLE users;--  The original query will now look like: SELECT * FROM users WHERE name = ‘‘ OR 1=1;DROP TABLE users;--  As you may see this query will delete the users table completely and comment out any further queries in the statement.

 On November 01, 2005, A high school student used SQL injection to break into the site of a Taiwanese information security magazine and stole customer's information.  On January 13, 2006, Russian hackers broke into a Rhode Island government web site and allegedly stole credit card data from individuals who have done business online with state agencies.  On June 29, 2007, A hacker defaced Microsoft U.K. Web Page using SQL injection.

 Input Validation is GOSPEL:  Always perform strict type checking of all data input by users.  Don’t ever trust the user. They’re not always noble and trustworthy.  Limit the length of input.  Never use of any of the default database accounts.

void foo(char *bar) { char c[12]; strcpy(c,bar); } int main(int argc,char *argv[]) { foo(argv[1]); return 0; }

void foo(char *bar) { char c[12]; strcpy(c,bar); /* No bounds checking!! */ } int main(int argc,char *argv[]) { foo(argv[1]); return 0; }

Before data is copied.

When legitimate data is copied, INPUT: "hello"

When you’re hacked! INPUT: "AAAAAAAAAAAAAAAAAAAA\x08\x35\xC0\x80"

 As seen above, an attacker may send junk input to your program and change the return address of functions to anywhere in memory he likes to. That memory location could very well contain attacker implanted code! And imagine, what would happen if the program above was running with super user privileges!  One could also modify data contained in variables using buffer overflow!

 Functions like strcpy(), gets(), strcat(), sprintf() etc. don’t perform a bounds check on the destination buffer. This allows an attacker to copy unsolicited data into the buffer!  C and C++ are two languages that don’t perform any bounds checking on the input and are hence vulnerable if one is not careful while writing code.

 Always use the safe alternatives to strcpy(), strcat(), gets(), sprintf() etc. like strncpy(), strncat(), fgets(), snprintf() !  Always fail safely, which means perform error checking and exception handling at every possible place in the code. Remember, don’t trust the user!  Grant minimum required privileges to your programs.

 Use static code analyzers before you deploy your code!  Use Stack Canaries!  Use safe libraries!  Use Stack Smashing!

NO CODE IS BUG FREE, BUT PREVENTION IS BETTER THAN CURE!