Quantcast
Channel: 懒得折腾
Viewing all articles
Browse latest Browse all 764

BadStore.net

$
0
0

BadStore.net

BadStore is a purposely broken web application simulating an on-line store. It’s meant for security peeps who are interested in learning more about web application security and more importantly circumventing it.

It comes as a downloadable Virtual Machine and is available at: badstore.net. Unlike other similar vulnerable applications this one doesn’t have a predefined goal such as finding a certain file or exploiting a specific service.

This is what i found…

SQL Injection

The first form that comes up on the BadStore.net website is the Search bar. Adding random input like asd makes it go crazy and dump the actual SQL query:

SELECT itemnum, sdesc, ldesc, price FROM itemdb WHERE ‘asd’ IN (itemnum,sdesc,ldesc)

Testing for SQL injection by searching for a tick (‘) makes things even worse. Since it breaks the SQL syntax in throws very detailed error:

DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ”” IN (itemnum,sdesc,ldesc)’ at line 1 at /usr/local/apache/cgi-bin/badstore.cgi line 207.

This means the user input is passed unfiltered to the SQL statement. In most cases, and given the location of the input in the query, there is not much that can be done with this vulnerability, unless multiple queries are allowed, which is not the case. But it’s always nice to have a proof of concept attack working so my first attempt was:

1’=’1’;–

The hyphens at the end are used to indicate a comment to the interpreter and so everything following those symbols is ignored. Unfortunately it doesn’t work as expected and throws another SQL syntax error. After a bit of research it turns out that there are multiple ways of commenting text in SQL. The second attempt used the /* symbols and revealed 8 additional items including: a Bag ‘o Fud, a Magic Hat and a Security Toaster. (don’t ask)

Two more occurences of SQLi are present in the login pages, both for regular users and suppliers, and lead to a complete bypass of authentication as long as the username is known. Attempts to login as admin were successful using this input:

admin’ /*

This logs me in as the Master Administrator. On the main interface there is not much use for administrative privileges of any kind. There is nothing that I couldn’t do with a regular user, but, when playing with the action= parameter in the URL I stumbled across what looks like an admin panel by simply giving it the admin value. If this is attempted using a regular user without administrative privileges this message pops up:

Error – {Unregistered User} is not an Admin!
Something weird happened […]

Password Cracking

By far the most fun feature in the Administration Portal is the Show Current Users option which dumps the entire user database containing password hashes, full names and password hints. There is not much use in trying to crack the hashes since SQLi allows Admin logins, but any excuse to use HashCat is a good excuse. Most passwords were cracked in the first minutes but I wanted every single one. One day later and HashCat still hadn’t finished so I manually searched the remaining hashes on MD5decrypter. These were the results:

+——————————————————————–+ |      USERNAME      |          PASSWORD HASH        |  PASSWORD   | +——————–+———————————+————-+ |AAA_Test_User       |098F6BCD4621D373CADE4E832627B4F6|test         | |admin               |5EBE2294ECD0E0F08EAB7690D2A6EE69|secret       | |joe@supplier.com    |62072d95acb588c7ee9d6fa0c6c85155|iforgot      | |big@spender.com     |9726255eec083aa56dc0449a21b33190|money        | |ray@supplier.com    |99b0e8da24e29e4ccb5d7d76e677c2ac|supplier     | |robert@spender.net  |e40b34e3380d6d2b238762f0330fbd84|cheap        | |bill@gander.org     |5f4dcc3b5aa765d61d8327deb882cf99|password     | |steve@badstore.net  |8cb554127837a4002338c10a299289fb|profit       | |fred@whole.biz      |356c9ee60e9da05301adc3bd96f6b383|whole        | |debbie@supplier.com |2fbd38e6c6c4a64ef43fac3f0be7860e|helpme       | |mary@spender.com    |7f43c1e438dc11a93d19616549d4b701|luv2buy      | |sue@spender.com     |ea0520bf4d3bd7b9d6ac40c3d63dd500|got2buy      | |curt@customer.com   |0DF3DBF0EF9B6F1D49E88194D26AE243|carbondale   | |paul@supplier.com   |EB7D34C06CD6B561557D7EF389CDDA3C|BMWMotorcycle| |kevin@spender.com   |                                |             | |ryan@badstore.net   |40C0BBDC4AEEAA39166825F8B477EDB4|Shavelick    | |stefan@supplier.com |8E0FAA8363D8EE4D377574AEE8DD992E|badstore     | |landon@whole.biz    |29A4F8BFA56D3F970952AFC893355ABC|TEXAN        | |sam@customer.net    |5EBE2294ECD0E0F08EAB7690D2A6EE69|secret       | |david@customer.org  |356779A9A1696714480F57FA3FB66D4C|California   | |john@customer.org   |EEE86E9B0FE29B2D63C714B51CE54980|Disneyland   | |heinrich@supplier.de|5f4dcc3b5aa765d61d8327deb882cf99|password     | |tommy@customer.net  |7f43c1e438dc11a93d19616549d4b701|luv2buy      | |                    |d41d8cd98f00b204e9800998ecf8427e|             | |qwe]                |d41d8cd98f00b204e9800998ecf8427e|             | +——————–+———————————+————-+

After a bit of poking around the robots.txt takes me to the suppliers page where I find the following strings:

am9ldXNlci9wYXNzd29yZC9wbGF0bnVtLzE5Mi4xNjguMTAwLjU2DQo= a3JvZW1lci9zM0NyM3QvZ29sZC8xMC4xMDAuMTAwLjE= amFuZXVzZXIvd2FpdGluZzRGcmlkYXkvMTcyLjIyLjEyLjE5 a2Jvb2tvdXQvc2VuZG1lYXBvLzEwLjEwMC4xMDAuMjA=

Nothing complicated there: the equals  sign at the end means they are Base64 encoded. After passing them through an on-line decoder I end up having the supplier usernames and passwords:

+————————-+
| USERNAME |   PASSWORD   |
+———-+————–+
|joeuser   |password      |
|kroemer   |s3Cr3t        |
|janeuser  |waiting4Friday|
|kbookout  |sendmeapo     |
+———-+————–+

Cross-Site Scripting

That was all fun and games, but this site is supposedly riddled with vulnerabilities so XSS must be in there. First place to start is the search query, since when attempting SQLi I noticed it simply outputs my search terms included in the SQL query.

Now what would happen if I searched for <script>alert(“sadik”)</script>? Well that would get reflected into the following page and get interpreted by the browser like this:

Three more vulnerable fields are in the Guestbook page and one more in the Register/Login page. They all work pretty much the same way. Apart from using them to display random messages I also made them dump the cookie using the <script>alert(document.cookie)</script>input.

Dat Cookie!

Either through Reflected XSS or by using a Cookie tool I managed to get my hands on the SSOid cookie value:

YWRtaW46NWViZTIyOTRlY2QwZTBmMDhlYWI3NjkwZDJhNmVlNjk6TWFzdGVyIFN5c3RlbSBBZG1p%0AbmlzdHJhdG9yOkE%3D%0A

The give-away is the %3D at the end which is the equals sign in URL encoding meaning Base64 again. Running that through an on-line decoder gives plenty of information about the current session:

admin:5ebe2294ecd0e0f08eab7690d2a6ee69:MasterSystem Admi7G&F#p

That looks as bad as it gets when it comes to cookies, but wait it gets worse. As soon as something gets added into the shopping cart a new cookie named CartID gets created. This was the value I dumped:

1385560793%3A3%3A9104.95%3A1001%3A1002%3A1013

This is URL encoded and in plaintext looks as follows:

1385560793:3:9104.95:1001:1002:1013

The first group of numbers is the CartID, meaning that if I change that value to something else I could stumble across someone else’s shopping cart. That is not very helpful since even though it’s another cart the contents are dictated by the following values. Next is the number of current items, total value, and a list of all the product IDs. The fun part is that these values can be changed and the total price can be dropped to whatever you want just by changing the third group of numbers.

The Checkout

Now once I managed to get to the payment checkout with my “discounted” magic hat and invisibility cloak (actual items from the store) I had to give a valid Card Number. Not valid as in real, but one that at least follows the rules and has a correct checksum.

Looking at the source code for the checkout form I see this:

<form onsubmit= return CardVrfy(); […] >

That’s nice, but this is code that gets executed from my machine, which in turn means that I can do pretty much whatever I want with it, as long as it passes validation on the server side. Changing the form onsubmit action to return TRUE means that any kind of input is now accepted. So using my “legit” card number of 1234-1234-1234-1234 I can now order all the Invisibility Cloaks I need. :)

Denial of Service

Since the server is running Apache and that is always a good excuse to play with Slowloris I tried a DoS attack just to see what happens. Previously when I had tried it for demos I couldn’t take a website down only with Slowloris and had to use something like LOIC or HOIC (don’t remember which one) and even then the sites just took forever to load but still eventually worked.

This one went down COLD!



Viewing all articles
Browse latest Browse all 764

Trending Articles