C++ Programming: The Hacker′s Motives
After you′ve finished a quick study of programming and sharpened your C++ skills, you land that really sweet job that you were looking for at the bank. You′re a big-time programmer at the bank, and you′ve just finished writing the back-end code for some awesome ledger application that customers use to balance their accounts.
Performance is great because it′s C++, and the customers love it. You′re looking forward to that big bonus that′s surely coming your way. Then you get called to the Department Vice President′s office. Seems that hackers have found a way to get into your program from its interface to the Internet and transferred money from other peoples′ accounts into their own.
Millions have been lost. Disaster! No bonus. No promotion. Nobody will sit with you in the cafeteria. Your kids get bullied on the playground. You′ll be lucky to keep your now greatly reduced job.
The point of this story is that real world programs often have multiple interfaces unlike the simple programs you learn when you begin programming. For example, any program that reads a port or connects to a database is susceptible to being hacked.
What the hacker is after:
If you′re lucky, the hacker is doing nothing more than exploiting some flaw in your program′s logic to cause it to crash. As long as the program is crashed, no one else can use it. This is called a Denial of Service (DoS) attack because it denies the service provided by your program to everyone else.
DoS attacks can be expensive because they can cost your company lost revenue from business that doesn′t get conducted or customers who give up in frustration because your program is not taking calls right now. And this doesn′t even include the cost of someone going into the code to find and fix the susceptibility.
Some hackers are trying to get access to information that your program has access to but to which the user has no right. A good example of this would be identify theft.
The loss of information is more than embarrassing as a good hacker may be able to use this information to turn around and steal.
For example, armed with the proper credentials, the hacker can then call up a bank teller on the phone and order sums of money be transferred from our hacked customers′ accounts to his own where he can subsequently withdraw the funds. This is commonly the case with SQL injection attacks.
Finally, some hackers are after remote control of your computer. If your program opens a connection to the Internet and a hacker can get your program to execute the proper system calls, that hacker can turn your program into a remote terminal into your system. From there, the hacker can download his own program onto your machine, and from then on you are said to be owned.
Perhaps the hacker wants access to your accounts, where he can steal money, or maybe he just wants your computer itself. This is the case with groups of owned computers that make up what is known as a botnet.
But how does this work? Your bank program has a very limited interface. It asks the user for his account number, his name, and the amount of his deposit. Nowhere does it say, “Would you like to take over this computer?” or “What extra code would you like this computer to execute?”
The two most common hacker tricks that you must deal with in your code are code injection and buffer overflow.