When you’ve only got a limited amount of time during a penetration test you want to get the best bang for your buck so I created a python script that will go and check for default usernames and passwords on certain models of printers. Below is the python script.

Usage:  at the command line type the following

So this script takes two arguments, 1) A list of IP’s you’ll want to test against, 2) Name of an output file where successful attempts are logged. If you’re having troubles running the script read my other post about running a python script. The output.txt will contain a list of IP’s that the script was able to log into. There are three variables that you’ll have to modify for your particular printer model that you are trying to scan for on your network, they are listed below.

Username and password variables should be obvious, simply put in the default username and password of the printer on your network. The only thing you’ll have to change in ‘theurl’ variable is the last quoted string. In my case it was ‘/index.html’, in your case it could be ‘/auth/login.html’. Variable ‘theurl’ builds the http request used to log into your printer’s web interface. A full example is below.

This script is doing nothing more than trying to log into the web interface of a printer, that’s it. So the script is not limited to printers, it can be used against any web application that takes a username and password. Although this script can be used against any web application there is a limitation.  This script authenticates to the printer using Basic Access Authentication. There are three main ways to authenticate to a web application.

1. HTTP Basic Access Authentication
2. HTTP Digest Access Authentication
3. HTML Form-based Authentication

So this script will not work if your web application (printer in this case) is using the second or third option. How would you know which one your printer or web application is using? Turns out OWASP has a nice write up on how to test which type of authentication your web application is using. Turns out that no one really uses one and two because they are not as secure as HTML Form-based Authentication wrapped inside SSL. Of course some printers use Basic Authentication because they are poorly built. Basic Authentication actually passes your username and password essentially in plaintext, the only way it tries to hide your username and password is by base64 encoding them which is easily transformed back into plaintext. I don’t want to get lost in the weeds to much but just knowing that your printer is using Basic Authentication is bad enough. Even if you set a strong username and password anyone sniffing network traffic would be able to determine your credentials.

I kicked this script over to Dave Huggins who has tons of experience developing Python applications and he quickly improved upon it by adding the functionality of IP ranges instead of a file. His enhancements can be seen below.

Happy printer hunting.

This tutorial will once again be targeting Foundstone’s Hacme Casino which intentionally has vulnerabilities built into the application. Fuzzing can focus on different types of vulnerabilities and parameters within web applications (e.g. XSS, SQL injection, queries, directory paths, etc…), although this tutorial will focus on parameters vulnerable to SQL injection. Foudstone’s documentation lets us know that the username input is vulnerable to SQL injection so we can try fuzzing it with Webscarab to find other possible injections. First we’ll try and login with the username ‘test’ and password ‘test’. This can be seen in Figure 1.

Figure 1: Trying to login

This will not log us into the application but Webscarab will capture the login process in the summary tab. Once this has happened find the login conversation in the summary tab. After you have found the login conversation simply right click and select “Use as fuzz template”, this will send the parameters and headers associated with that request / conversation to the fuzzing tab. Selection of the login request can be seen in Figure 2.

Figure 2: Send conversation to fuzz template

Now navigate to the Fuzzer tab within Webscarab. Here you’ll see all the parameters that are associated with that request / conversation. You could add parameters to the request and see how the web application reacts to different paths, value, or types. You could also delete parameters for simplicity and to also see how the application reacts with those parameters missing. Once you have determined the parameters for fuzzing you’ll need to define a fuzz source. So click on the “Sources” button beside “Start” and “Stop” within the Fuzzer tab. Here you will choose a dictionary style text file that contains parameters you want to fuzz with. I chose a SQL injection dictionary because we know the “username” field is vulnerable to SQL injections. The selection of the SQL injection dictionary can be seen in Figure 3.

Figure 3: Choosing fuzz source

In my SQL injection dictionary I have 66 items, but Webscarab does not have a limit. There are lots of SQL injection dictionaries out there, some are even dedicated towards different platforms (e.g. MySQL, MS SQL Server, DB2, etc…). I got most of my SQL attacks from Andres Andreu’s website Neurofuzz, the dictionary I pulled from can be found here. In this tutorial we won’t be trying to fuzz for XSS vulnerabilities but ha.ckers.org has a now infamous XSS dictionary which is a great resource. Once all dictionary sources are added go to the main Fuzzer tab and assign parameters a fuzz source. This can be done via a drop down menu as seen in Figure 4.

Figure 4: Drop down menu containing fuzz source

In order to prevent a parameter from being fuzzed simply leave the “Fuzz Source” field blank or delete the parameter altogether. In this case the “user_login” is the only parameter that will reiterate through the SQLattack dictionary. The next step is to click on “Start” and let Webscarab try all of your parameters within the dictionary. This means the value “test” will be replaced with values inside the SQL injection attack dictionary and new request is sent to the web server for every attack parameter inside your dictionary. The fuzzer in action can be seen in Figure 5.

Figure 5: Running the fuzzer

Notice the “Total Requests” and the “Current Request”, once the fuzzer has run through all of the parameters in the SQL injection dictionary both of these numbers will be 68. Also notice the ID number 97 on the left hand side of the table, this is the first request of the fuzzing operation. The last request will have an ID number of 164, it’s important to keep track of these request ID’s when reviewing results of the fuzzing operation. I have found myself reviewing requests that weren’t fuzzed and accidentally identified requests as not being vulnerable when in fact they were.

Once the fuzzer has made all of the requests a review of the results is needed to see if any of the attack parameters succeeded in a SQL injection. I do this simply by going back to the summary tab and opening up the first conversation of the fuzzing process. I then manually step through every conversation involved in the fuzzing operation and look for any “interesting differences” between responses. The phrase interesting differences is in quotation marks because fuzzing and looking for SQL injections is not an exact science but knowing how an application normally deals with the input will be helpful in determining what should and should not be expected in a HTTP response. Let’s take a look at some of our fuzzing conversations to get a better idea of discovering differences. Have a look at the first fuzzing request, note the value of the “user_login” parameter in the request and the value of the “Location” in the response. This can be seen in Figure 6.

Figure 6: First fuzzed conversation

Here it’s seen that the first value in the attack dictionary was actually used for the username value, good to know Webscarab is functioning properly. The top of Figure 6 shows that a POST request is sent to /account/login to check the credentials of the user, since the first SQL injection is not a valid user the response is to redirect back to the login screen. Keep in mind when looking at these conversation screen shots that the top half of the figure is the request and the lower half is the response. It can be deferred from this conversation that if an invalid username is inserted into the web application the response will be a redirect to the login screen. So when looking through the other SQL injected conversations it would be a good idea to look for a redirect to another location or an error message. It’s always a good idea to look for database error messages when trying to find SQL injection vulnerabilities within a web application. Stepping through the other conversations I notice something different, this can be seen in Figure 7.

Figure 7: SQL injection changed redirect location

Looks like on conversation 103 one of the SQL injections in the attack dictionary changed the location of the redirect to /lobby/games. Let’s throw the injection value back into the web application and see what the response may be. The request can be seen in Figure 8.

Figure 8: SQL injection request on Hacme Casino

The response to this SQL injection can be seen below in Figure 9.

Figure 9: SQL injection response (Great success!)

Looks like the SQL injection gave us access to Andy Aces’ account. This occurred because we added the phrase “or 1=1″ (which is always true) to the end of the SQL query that authenticates the users to Hacme Casino. The reason Andy Aces’ account was hijacked is because his name is the first one in the database. Guess having the last name Altman could be bad for me as well? Looking through the other conversations there appears to be another SQL injection that worked as well, this can be seen in Figure 10.

Figure 10: Another successful SQL injection

The hits just keep on coming. This may seem to easy but there are plenty of web applications out in the wild that don’t validate input and let malicious users manipulate their application and backend databases. SQL injections within a web application can be a serious vulnerability depending on the data held within the database. Had this scenario been real a malicious user could have taken over Andy Aces’ account and had his way inside the online casino.

The fuzzing functionality of Webscarab makes web application vulnerability assessment a more automated process. Manually entering all of those SQL injection attacks can take a very long time. There is a downside to the dictionary approach though, your dictionary may not be as creative as a malicious user. Some people believe that a fuzzer should generate random input and that you should try thousands of requests in order to properly test a web application. Thousands of random requests could be better but stepping through those requests to determine validity can make for a long day. Although if one were to take the random input approach Webscarab has a solution for stepping through those results, the Compare and Search functionality. I may dive into the Compare and Search functionality at a later date, these functions can really speed up the process of web vulnerability assessment. Also keep your eye open for a video tutorial of Webscarab coming soon, you could always subscribe to my feed for the latest and greatest.

Once again I hope this tutorial was helpful in showing you the great features of Webscarab, as always your comments and feedback are welcomed.

travis@home:~$ more references

Owasp Webscarab fuzzing tutorial

Rogan Dawes documentation for Webscarab

Foundstone Hacme Casino

Part 2 in this series is going to focus on session ID analysis. If you are not familiar with session ID’s I’ll do a quick explanation. HTTP is a stateless protocol, so it’s equivalent to walkie talkies or CB radios. You’ll send a request and wait for a reply, you don’t have a constantly open communication line as you would with a phone. So in order to emulate this open communication the HTTP protocol uses session ID’s, commonly known as cookies. These cookies are simply agreements between you and the web application that you are who you claim to be. Once you have exchanged your cookie with the website you can then talk back and forth as long as the cookie is tied to your communication. So there’s the quick and dirty intro to session ID’s. So the next logical question is how does this session ID process work or even better how should it work? Let’s use a web mail application as an example:

1. You login to your web mail account
2. Your web mail provider sends you a “random” cookie that is tied to your login session
3. Each time you click on a new message within your Inbox your cookie is sent along to validate who you claim to be, that way you’ll get your next message and not another person’s message.

These are the basic steps. The main thing to remember is that your login credentials are tied to the session ID / cookie. So the key to keeping your conversations private is protecting the session ID and making it hard to guess. Session ID’s are similar to passwords in that regard, you always want to keep them a secret and make them hard to guess. When Webscarab analyzes the session ID it only focuses on if the session is easy or hard to guess (aka randomness). So enough with the chit chat let’s see how Webscarab analyzes session ID’s.

Once again we’re going to be analyzing the Hacme Casino web application. The login page for this application can be seen in Figure 1.

Figure 1: Hacme Casino login

So with Webscarab already running in the background I’ll go ahead and login into Hacme Casino and click on a few links. Navigating inside the application will generate requests and responses that we can later analyze. Now the login process should generate a session ID but there could be other session ID’s generated within the application that you may want to analyze as well. You could always keep an eye on the summary tab to see if you are capturing cookies. There are other ways to maintain state within a web application but cookies are the most common. When looking at the summary tab for the login process you can see that cookies are being set. This can be seen in the first conversation in the bottom row on Figure 2.

Figure 2: Login process for Hacme Casino

So the conversation with the path /account/login is setting a cookie, also the top pane has a check mark indicating that the login URL is setting a cookie as well. This is definitely a good target because we know the functionality of this session ID is to maintain my balance and gambling stats. Some session ID’s can be tough to figure out and sometimes it seems like developers set cookies for no reason. So now let’s walk through the steps to analyze the session ID associated with /account/login.

1. Log out of the current session. I can’t stress this enough, the first time I was using this feature I bumbled around for a couple of hours trying to figure out why it wasn’t analyzing the sessions. Further down in this article I’ll show you a screen shot of what it looks like when you try and analyze the session you are currently logged into.
2. Navigate to the Session ID Analysis tab >> Collection tab within Webscarab. There you will see a drop down list labeled “Previous Requests”, here you can pick a conversation from your history of transactions within the web application to analyze. We already know that we want to analyze the /account/login conversation because we saw that it was setting cookies. If you were unsure which conversation used session ID’s you could click on the “Test” button to verify if session information existed. Figure 3 shows a screen shot of me choosing the /account/login conversation for analysis.



Figure 3: Choosing conversation in Collection tab

3. After you have chosen your conversation for analysis you will then click on the “Fetch” button to start collecting session ID’s from the web server. The default number of session ID’s collected is set at 100 but you can choose more if you like. My background is math and science so I’m of the opinion that you can never have to many data points. Play with this number if you like, in my experience more samples will do a better job at producing trends and pointing out weaknesses in random number generation. The law of diminishing returns will eventually kick in though. So after you have clicked the “Fetch” button you will need to move over to the “Analysis” tab. When you first click on the “Analysis” tab it may seem like nothing is happening, this is because you need to select your session ID from the “Session Identifier” drop down list. This drop down list can be seen in Figure 4.



Figure 4: Choosing session in Analysis tab

Once you have selected your session that you are analyzing the table should begin to populate with the number of samples that you chose in the Collection tab. Webscarab takes the session ID’s found within the web application and converts them into numbers so that they can be easily parsed. These numbers are then compared to one another for predictability. Figure 5 below shows what happens when you try to analyze the current session, you’ll get zeros for both the Numeric value and the difference. This is because the session ID / cookie stays the same.



Figure 5: Analyzing current session

 

4. The fourth and final step is neatest part of the session ID analysis functionality within Webscarab, the Visualization tab. This tab creates a graph using the numbers from the Analysis tab. This will give you a quick visual representation of how weak or strong the session ID’s are. The graphical analysis of the Hacme Casino session ID’s can be seen below in Figure 6.

Figure 6: Cookies over time for Hacme Casino

It appears that the session ID’s created for Hacme Casino are random or at the very least not easy to guess. Your average malicious user is going to see that the session ID’s are going to be difficult to guess, so they’ll move on and try another vector to get inside the web application. A malicious user will be looking for easy access so they will be looking for session ID’s that are very easy to guess. Figure 7 shows an application that implements session ID’s that are very easy to guess.

Figure 7: Weak cookies over time

This graph was not generated using Foundstone’s Hacme Casino but had a malicious user seen this type of graph it would be very easy for them to guess a session ID and essentially hijack that person’s Hacme Casino account. From the casino example you can see how dangerous weak session ID’s can be. Session ID’s are the “key” to someone’s account information. This is possible due to the stateless nature of HTTP. So a malicious user could hijack your account without ever knowing your username or password.

This concludes Part 2 of the Webscarab tutorial. If you have something to add or see an error please leave a comment or contact me. Part 3 is going to focus on the fuzzing functionality within Webscarab. Until then try the session ID functionality on a web application that you use often and see how weak or strong their session ID management is.

This tutorial is going to focus on Webscarab, although there are other numerous useful tools on the market (e.g. Paros, Burp). The first thing we’ll need to do is obtain Webscarab, I like to use the version signed by Rogan Dawes, which can be found here. Go to the downloads section and make sure you get the Java Web Start version signed by Rogan Dawes. The second thing we’ll need to do is start up Webscarab. By default Webscarab listens on port 8008 but this can be easily changed to any port. These settings can be seen in Figure 1.

Figure 1: Webscarab proxy settings

We’ll also need to configure our browser so that our communication is pointed through the proxy. In recent versions of Firefox the path should be Tools >> Options >> Advanced Tab >> Network Tab >> Settings. Once there you’ll need to highlight “Manual proxy configuration”, then for “HTTP Proxy” type in “localhost” and for port use 8008. You’ll also need to do this for the SSL proxy if the web application uses SSL. These settings can be seen in Figure 2.

Figure 2: Firefox proxy settings

The path to change IE settings: Tools >> Internet Options >> Connections tab >> LAN settings. Here you’ll need to check the box that says “Use a proxy server for your LAN”, this can be seen in Figure 3.

Figure 3: IE proxy settings

This tutorial is going to show how Webscarab can walk through and assess the Hacme Casino web application provided by Foundstone, Figure 4 shows the login page for this application.

Figure 4: Hacme Casino login page

I have already created an account within the application with the username “hacker” and a password of “passwd”. So with Webscarab already running in the background I am going to login to Hacme Casino. If you are on the summary tab within Webscarab you will notice requests and responses filling up rows in the bottom pane. Webscarab is logging all communication between you and the web server, this includes all images, CSS files, Javascript files, parameters, etc… The top pane of the summary tab shows you a directory structure of your history through the web application. This summary tab can be seen in Figure 5.

Figure 5: Webscarab summary tab

Now a summary of your history is neat but that only scratches the surface of Webscarab’s functionality. One of the best functions of a HTTP proxy is the ability to intercept requests on the fly or replay those requests at a later time. In order to intercept requests / responses make sure you have checked the “Intercept requests” / “Intercept responses” checkboxes in the Proxy >> Manual Edit tab. These settings can be seen in Figure 6.

Figure 6: Webscarab intercept settings

You may be wondering why you would want to intercept or repeat a HTTP request / response. The simple answer is to learn more about what a website is doing with your input (e.g. SSN, credit card, personal information). Application security folks, developers, or curious people may want to understand more about the web application they’re using. Intercepting a request / response will allow you to see and manipulate communication being sent back and forth. Application security analysts like to replay requests over and over again with different inputs to see what the application will allow as input. This will give security analysts an idea of how secure the application is. Had we intercepted the login process you would have seen the inputs for username and password being sent to the web server. A screen shot of this can be seen in Figure 7.

Figure 7: Interception of the login process for Hacme Casino

You can see in Figure 7 that Webscarab has intercepted both the username “hacker” and password “passwd”. A HTTP proxy is able to see the password even though each character was replaced by an asterisk within the application. At this point you could accept the request or manipulate the parameters. You could try to login as someone at this point even though you initially typed in a different username and password. With a HTTP proxy you could manipulate any request / response not just the login process.

This covers Part 1 of the tutorial on Webscarab. OWASP also has a great write up, called Getting Started, going over basically what I have covered here. So if you ever wanted to know more about a web application Webscarab is a great tool that can help you learn more. In Part 2 of this series we’ll analyze how an application maintains state by using the “SessionID Analysis” functionality of Webscarab.

Prerequisites:

1. Remote PC running an SSH server. Windows XP default does not come with an SSH client / server, so I recommend OpenSSH. Most Linux distributions already have installed a SSH client / server that can be used.
2. Determine which ports you are going to use? It is sometimes difficult to determine which ports you are allowed to use but most organizations are going to have port 80, 443, and most likely 22 open for communication. In this tutorial we are going to use ports 22 and 80 for our tunneling although you can use any port that is open.

Tunneling with Windows XP, IE (internet explorer), Firefox, and Putty (SSH client):

I recommend the Putty client when using XP because it’s free and easy, but you can use any SSH client. For this tutorial I will only focus on Putty. So the first step is to configure Putty for tunneling. Click on the “Tunnels” tab underneath the branch of “SSH” within Putty. There under the Source port form you will add what port will be doing all of the forwarding. I have chosen to use port 80 as most organizations allow the use of this port. You will also put in the IP address of your remote PC that is running a SSH server. You’ll also need to highlight the button that says dynamic. A screen shot of this can be seen in Figure 1.

Figure 1: Putty port forwarding configuration page

Once you have done this click the Add button, this will create the forwarded port for the session. You will notice that it puts a letter beside the port you have chosen. This can be seen in figure 2.

Figure 2: Add port and destination settings

Once you have set up port forwarding you can then go back to the main “Session” page and type in the IP address of your remote PC. You can also see that I am connecting to the remote SSH server on port 22. This could easily be changed to a port of your choosing. If your organization doesn’t allow communication on port 22 but does allow port 443 simply put 443 in the port form. If this were the case you need to make sure that the remote SSH server is listening on port 443 instead of the default 22. Once you have done this you can save your session so that you can easily connect the next time. You can see that I have named my session HTTPtunnelViaSSH in Figure 3.

Figure 3: Putty main menu

Now click open and another window will open asking for authentication credentials on the remote PC. Once connected the cursor will move down to the next line, this is the normal operation of Putty. If you didn’t input your authentication credentials correctly you will get a message stating so. A successful connection with Putty can be seen in Figure 4.

Figure 4: Successfull connection via Putty

Now once a successful connection has been made with Putty we need to configure our browser to use the SSH proxy so that all of our HTTP traffic is funneled over our secure connection. We will first configure Firefox. The actual steps to get to the “Connection Settings” within Firefox may vary depending on which version you’re running but generally the path is: Tools >> Options >> Advanced Tab >> Network Tab >> Settings. Once there you will need to highlight the “Manual proxy configuration”, then for the “SOCKS Host” use localhost. The port will be port 80 in this case because we told Putty to tunnel our connection via port 80, YMMV (your method may vary). The screen shot of this configuration can be seen in Figure 5.

Figure 5: Firefox configuration settins for tunneling HTTP over SSH

The same concept applies when configuring internet explorer. Once again the location of the “Proxy settings” for internet explorer will vary depending upon which version you are running but generally the path is: Tools >> Internet Options >> Connections tab >> LAN settings. Here you will need to check the box that says “Use a proxy server for your LAN”, this screenshot can be seen in Figure 6.

Figure 6: Proxy server settings for Inernet Explorer

You must then click on the “Advanced” tab to fill out the Socks connection form. Once again we’ll use the “localhost” as the host and port 80 for our tunnel. This screenshot can be seen in Figure 7.

Figure 7: Socks settings for Internet Explorer

Once you have completed this step you are done, just click all of the OK buttons. You should now be tunneling all of your HTTP connections to your remote PC in a secure shell, congratulations. You have now stuck it to the man, whomever that may be.

Tunneling HTTP via SSH with Linux, Firefox, and SSH:

The procedures for tunneling HTTP traffic in Linux is almost exactly the same as it is in Linux, the only exception being the SSH client. The operating systems have really nothing to do with this whole process. There are numerous SSH clients that can be used with Linux although most distributions come with a SSH client. I will be using the command line interface as oppose to a GUI interface. So using your favorite shell use the following command.

After issuing this command you will be prompted for your password. Keep in mind that you may need to be “root” in order to run this command. Unlike Putty you will be given the prompt for the remote PC instead of the cursor going to the next line. After the connection has been established just go into the settings for Firefox, as seen in figure 5, and type in “localhost” and which port you are forwarding your traffic. Once again we could have chosen any open port to tunnel out HTTP traffic. This is accomplished with the -D option within the SSH command, instead of 80 you could have chosen port 443. That’s it for Linux, you are now keeping your communications private and secure, congrats.

As always I welcome your feedback in the comments section if you have found this article erroneous or have a better solution.

References:

http://polishlinux.org/apps/ssh-tunneling-to-bypass-corporate-firewalls/, http://www.forniol.cat/?p=50