1
votes

A month or so ago my website was hacked. My host doesnt keep very good logs, so I don't know what specifically was accessed. The hacker claimed in our IRC that he used some kind of RCE (remote code execution) but refused to elaborate. Whatever he did, he uploaded an obfuscated php script to the site and assumed control of the database where he then made himself an admin user on the site.

The framework I use is called kusaba, version 0.9.3. The previous versions have had several reported exploits, which were patched in this release.

Well, one site, written in Spanish, talked of an exploit (below), but I can't make it work unless I am doing it w

https://translate.google.com/translate?sl=auto&tl=en&js=y&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fvammm.wordpress.com%2F2012%2F09%2F07%2Fkusaba-x-0-9-3-0day-xss%2F&edit-text=&act=url

I posted the given code into an html doc, inside script tags, and accessed the page online. Nothing. Tried accessing the direct link, below, which also does nothing.

http://postherwin.com/threadwatch.php?o=addthread&board=\%27%29%3B%22%3E%3C%2Fa%3E%3Cscript%3Ealert%28document.cookie%29%3B%2F*a*%2F%3C%2Fscript%3E%3C!--

Given the parameters above, how was he able to upload the shell? How can I prevent it?

2
It looks like an XSS where someone harvested the document.cookie for users using that URL (with the session ID), which was then used to impersonate that user (session fixation) and apparently gain access to your system (including filesystem).Jared Farrish
Im not sure how that works, would they have needed access to my desktop, or is that something they can do remotely?user3175451
If they had access to your desktop you'd know it because your desktop background would have been changed to a lot of dongs.Josh KG
You should read on it, if you want to understand it. This series is good about the concepts (although it deals in Django). And no, it doesn't have anything to do with your desktop (I'm 99.9% certain).Jared Farrish
Looks like kusaba is pretty vulnerable - google.co.in/?gws_rd=ssl#q=kusaba+vulnerabilityraidenace

2 Answers

1
votes

Even if it wasn't the unrecorded threadwatch.php vulnerability that you mentioned in your question, the attacker could have used the following exploit. CVE-2008-5663:

Multiple unrestricted file upload vulnerabilities in Kusaba 1.0.4 and earlier allow remote authenticated users to execute arbitrary code by uploading a file with an executable extension using (1) load_receiver.php or (2) a shipainter action to paint_save.php, then accessing the uploaded file via a direct request to this file in their user directory.

Kusaba 'paint_save.php' Remote Code Execution Vulnerability

Kusaba 'paint_save.php' Remote Code Execution Vulnerability

Kusaba is prone to a remote code-execution vulnerability because the application fails to properly sanitize user-supplied input.

Exploiting this issue allows attackers to cause the application to execute arbitrary code within the context of the webserver.

Kusaba 1.0.4 is vulnerable; other versions may also be affected.

Kusaba 'load_receiver.php' Remote Code Execution Vulnerability

Kusaba 'load_receiver.php' Remote Code Execution Vulnerability

Kusaba is prone to a remote code-execution vulnerability because the application fails to properly sanitize user-supplied input.

Exploiting this issue allows attackers to cause the application to execute arbitrary code within the context of the webserver.

Kusaba 1.0.4 is vulnerable; other versions may also be affected.

The solution is the same in both cases:

The vendor released fixes to address this issue. Please see the references for more information.

So my recommendation is to use a version of Kusaba later than 1.0.4.

The threadwatch.php vulnerability appears to be another sanitization problem. The framework fails to correctly sanitize or output encode the data stored into the database. This means that when a valid user then accesses the system, an XSS attack can happen (e.g. sending your cookies to the attacker or installing a keylogger into the website for your session).

It is not clear from the details regarding the threadwatch.php vulnerability how Remote Code Execution was achieved, but since there are other ways the attacker could have achieved this as I have detailed above it is a moot point - you should upgrade to a fixed version of the framework.

0
votes

From the sound of it, you've been locally hacked. My advice, change all passwords, you need to have a password with 1 or more capital letters, 1-2 numerical letters, and 1-2 special characters such as 1-0 with the shift button. !@#$%^&*()_+. That right there is the best security you can buy. Otherwise, you're left open to be used. Many pre-made scripts have very visible errors. There many security measures that could've been made. Honestly, learn how to code. 99% of questions asked are over-shown. Brute force may work some of the time, but you're forced to wait when it comes to smart Americans.