Friday, May 27, 2005

 

Probing into KKForum

By jellyfish & 00z1b00z1

You can download this document as a PDF here

mirror1 mirror 2 mirror 3


It has been a while since KKforum fell into our prey, and it has been a while that we have been meaning to write this documentation. We had to “hack” it as a consequence of them posting pictures of our friends and family without consent and we wanted to remove the photos. Photos seem to be shared by a perverted bunch of youngsters who seem to be blind to the ethical and moral implications of posting pictures – often portraying nudity, often of underage teens – and then discussing and commenting on them with profanity and more often rude remarks.

We decided to write this document, not to brag about it but rather as a demonstration of how some Maldivian sites fail miserably in having solid code – really. We also intend to expose and make aware the Maldivian community of the need for secure programming. The current trend in Maldives toward digitization has resulted in many a websites – both government and public – that provide services of various sorts. The developers need to take extra care to avoid the web applications being subjected to attacks from malicious individuals that could cause real harm. Data modification and data deletion are a very real threat. In the growing reliance on computers for business operations, this is not something that is acceptable. We hope this document does some good, be it motivating some of you to double check your applications and locking down the code or be it that this entertained you.

Initial Entry

KKforum relies on WebWizForum for their forum software. The version in use is quite old and bug ridden. However, that was not the entry point – it did not need to be. The KKforum site is hosted on the same server as that of the groupkk.net website, which acts as the homepage for the GroupKK bunch that runs the KKforum site. The GroupKK site has a news section along with a scattering of relatively useless, mostly-not-working features such as an “e-directory” and “name search”. A quick scan of the site showed that it was flowing with SQL injection possibilities. Now, take our word when we say the possibilities were numerous. Almost all of the programming they had was open to SQL injection. Blame this on ignorance or laziness, whichever makes you feel good.

Let us start off with a clean example.

http://www.groupkk.net/news.asp?NID=5694242987

The first of things we noticed was the ASP code. The news probably comes from a database and the NID=5694242987 bit probably points to an entry in the database with that ID. So we decided to check for injection possibilities and lazily replaced the “5694242987” bit with “sds” – our preferred random key sequence.

Here is the URL now and what it spit out.

http://www.groupkk.net/news.asp?NID=sds


Whoa! SQL error! So the database is Microsoft SQL Server, the error kindly tells us. So we messed around for a bit and then decided to download the WebWizForum (www.webwizforums.com) software to check out the database structure. We wanted to find the table that stores the authentication details, i.e. the username and password crap.


Elevating access

Soon we had the table name for authentication details identified as tblAuthor. Now, knowing the table structure made it even easier – we did not have to iterate through table structures to find the ones we need. As a next step, we wanted administrative access to the forum. This was for the simple reasons that we can delete posts and change the behavior of the forum (we can allow more types of files to be uploaded!).

We could get the password hash for the “administrator” by injecting SQL into the URL from the news script.

http://www.groupkk.net/news.asp?NID=570636702237%20union%20all%20select%20'1','2','3',Password,'5'%20FROM%20tblAuthor%20where%20Username%20like%20'administrator'

Notice the weird set of characters? Yes, “2EB510DD71A442FC489800F6A329986893B14528” happens to be the password for the user “administrator”. Then again, knowing this “hash” (call it an encryption) does not do much for us. Decrypting it would be fun. We would have access to the forum using their password! A quick look at the WebWizForum code reveals that this would not be easy. They have a custom hash generation function and we loathe ASP, so we decided to skip the steps for decrypting the password entirely. We’ll take another route.

This another route meant setting our own password for administrator. This was of course possible because we could successfully inject SQL and the user the scripts were running with would have write access too. Hold your horses; you can not just change the password to anything you want! The password is a hash and the forum login code will probably be comparing the database password hash with a hash of the password provided by us on the login page. Of course this wouldn’t be a problem at all. All we have to do is inject a valid hash of a phrase we know.

Again this was simple due to the fact we had the WebWizForum code to look at. We simply grabbed the hash generation function from the forum scripts, passed the character “a” for hashing.

Here is the ASP code for it.

<%=HashEncode("a" & "569C35")%>

By the way, the “569C35” bit is a salt concatenated to the string to be hashed. It can be found by querying the salt field of the user.

http://www.groupkk.net/news.asp?NID=570636702237%20union%20all%20select%20'1','2','3',Salt,'5'%20FROM%20tblAuthor%20where%20Username%20like%20'administrator'

Now we had the hash “28B3A24BDCB0ABD9F3D9E7D8B4BA88DC69468C60” for the character “a” as a password and it was time to replace the current administrator password with ours. Before that, we made sure we noted the current administrator password for reverting later after we are done with our play.

http://www.groupkk.net/news.asp?NID=570636702237%20union%20all%20select%20'1','2','3',Password,'5'%20FROM%20tblAuthor%20where%20Username%20like%20'administrator'


This gave us the current hash for administrator as “2EB510DD71A442FC489800F6A329986893B14528”.

With the current password hash stashed away safely, we went ahead and replaced the old with our “a” password hash.

http://www.groupkk.net/news.asp?NID=570636702237;update%20tblAuthor%20set%20Password='28B3A24BDCB0ABD9F3D9E7D8B4BA88DC69468C60'%20where%20Username='administrator'

Viola! We are in! We proceed to the login page and successfully logged in.


Furthering access

Finally! We are in. We have administrator access but that’s not all. Time to further access and do what we want. Once logged in, the “admin” link was easy to find.


Next up, we spotted the “File and Image Upload Setup and Configuration” option link that quite helpfully pointed us in the way we wanted to go.


At the file upload configuration screen, we added “ASP” to the type of file uploads allowed and saved the configuration. Ah! Mission completed. That is all we needed. We logged out. Cleaned up after ourselves by reverting the administrator password to the old one they had.

This did the trick.

http://www.groupkk.net/news.asp?NID=570636702237;update%20tblAuthor%20set%20Password='2EB510DD71A442FC489800F6A329986893B14528'%20where%20Username='administrator'

Now, all we had to do was go to any page, go to the post reply link, and upload a file using the “file attach” option in the message posting screen. The file gets uploaded and saved whether a post is made or not.

Having phun

So there it was. Next up, we uploaded a healthy set of ASP files to do all the dirty work we want.

Here is a lovely screenshot of the root folder file listing there.


Notice the “uploads” folder? That’s where the pictures, files and other stuff people attach and upload to the forum get saved. See the size? 3.01 GB!! Amazing amount of crap people have posted – mostly porn or other vulgar material it seems on inspection.

Well, KKforum, kekek!!!



The fix

The bug that facilitated all this to be done was the simple mistake of not sanitizing the input to the scripts. The user supplied strings were directly passed into the SQL queries, there by allowing the execution of malicious and revealing SQL queries. The fix to this is simple - sanitize the strings being passed to the SQL queries. A mere check to ensure the data coming from the GET request is numeric would be sufficient in this case as any other characters would be invalid to be compared against the News ID field.

This exploit can be downplayed and said to be trivial, after all it is only a stupid forum website right? Wrong! Further investigation showed that the same code was used on the Maldives Ministry of Tourism website. Imagine the damage SQL injection can inflict on the site. Changing of the texts on the site would be an utter embarrassment to the Ministry and the Government.

The code that was exploited in these cases came from Grayscale Pvt. Ltd. Tourism Ministry site code has since been fixed upon notification. KKforum still continues to proudly display, in its unprotected state, the offensive material depicting teenage girls.



Disclaimer

This document was written for educational purposes. The content here in is entirely fictional and can be considered an original work of art. Any similarity to the real world is entirely coincidental and need not make you think we know anything about computers at all.

This page is powered by Blogger. Isn't yours?