Common Apache Misconception
Thanks to fellow handler Jason for reminding me about the following common Apache misconception. This is not an Apache bug, or a misconfiguration per se. It is more an error of the operator not to read the manual.
In order to use PHP, or other modules in Apache, you typically use a configuration directive like:
LoadModule php4_module modules/libphp4.so
AddType application/x-httpd-php .php
The misconception is about the ".php" part. Many, even experienced, Apache administrators believe that this will enable the PHP module for all files ending in ".php". Close, but wrong. It will enable php for all files that contain .php. For example, test.php.1 will be parsed using php, or something.php.bak. At first, this is actually a good thing. the .bak file will not leak source code. However, the issue becomes a very bad thing if you allow users to upload files. Now it is no longer sufficient to test if the extension is .php. A users could upload test.php.gif and the file would still be parsed by PHP.
This brings me to my checklist about how to upload files:
- do not use the user provided filename, come up with your own random / artificial filename.
- upload the files into one directory only, which is outside the DocumentRoot.
- carefully validate that the mime type provided by the user matches the mime type received.
- to retrieve the file, use a wrapper page (which can then also do access control).
- establish maximum file sizes and enforce them on the server.
- avoid anonymous uploads if you can.
- use AV scanners to check the file before you allow access ot the file.
(there is a section about this in my php course).
also see: http://httpd.apache.org/docs/1.3/mod/mod_mime.html#multipleext
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute - twitter: http://twitter.com/johullrich
SSH scanning from compromised mail servers
We received two reports about an increase in ssh scanning. One of them (thanks Quentin!) correlated the sources and found that based on reverse DNS lookups, 706 out of 824 sources appear to run mail servers. We do not have any associated malware at this point, and the mail servers appear to run various SMTP daemons. If you observe a similar pattern, or better: if you mail server scans for port 22 tcp, please let us know.
Denyhost, which monitors ssh brute force attacks, detected a remarkable uptick. We do not see an uptick in our data, but we only monitor firewall logs which would not detect connects to open ssh servers.
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute http://twitter.com/johullrich
Tax Season Scams
We are entering the last few days of the US personal income tax season. The filing deadline April 15th is just about a week away. So far, it has been not to busy when it came to scams. But here a few things to watch out for:
- fake e-file websites. Only use reputable companies. I did a quick check earlier and didn't see any obvious fakes on Google, but this may change at any time.
- IRS e-mails: The IRS will never send you an e-mail asking you to go to a website to get a refund.
- malicous tax preparation software: Don't just download the next best free tax prep software package.
- and once you are all done: Make good offline backups. If you used tax preparation software, burn a couple CDs with your files and don't forget to retain a copy of the software itself so you can read the files later. Keep a paper copy. This includes supporting electronic files like account software and spread sheets that you may use to track finances.
If you come across any suspect websites, let us know.
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute http://twitter.com/johullrich
Advanced JavaScript obfuscation (or why signature scanning is a failure)
Couple of days ago one of our readers, Mike, submitted a URL to another heavily obfuscated JavaScript. It appeared very interesting so I decided to spend some time figuring out how it works. While it was not ground breaking, the attackers did show advanced knowledge of JavaScript and its uses of object access operators.
In this diary I will go through several obfuscation methods the attackers combined into one JavaScript file. For those interested in analysis, the malicious JavaScript file is still available at hxxp://84.244. 138 [dot] 55 / google-analytics/ ga.js –
be careful if you go there.
1) Usage of lists to return last values
This obfuscation method is very simple and it is used to assign a value to a variable. The attacker can use an arbitrary number of values in front which are all ignored. So, the following example:
mutae=(9e1,"it");
assigns the string “it” to the variable “mutae”.
2) Expanding the list with conditionals
The attackers further expanded the expression mentioned above with a conditional. Conditionals are simply if/then statements, all in one line with special characters such as “?” and “:”. The following is an example of such usage:
rgvij=(0.2e1>=4e1?.9075:"i"+"f");
I put special characters in red so it’s easier to see what’s happening here: the interpreter checks if 0.2e1 (which equals 2) is greater than or equal to 4e1 (which equals 40). If it is, the interpreter picks first part before the “:” character (.9075). It, of course, isn’t so the interpreter will pick strings “i”+”f” and concatenate them into “if”. Finally, this will result in the variable “rgvij” containing the string “if”. Not bad for obfuscation you’ll agree.
3) Usage of [ and ] operators when referencing objects
Those of you following our diaries here have seen the document.write() call million times already. This calls the method “write” in the object “document”. However, the same method can be called by using the [ and ] operators as well, as shown below:
document[“write”](“text to print”);
We can now easily see how this can be obfuscated with the following simple script:
a = document;
b = “write”;
c = “text to print”;
a[b](c);
Now, as you can imaging, attackers started combining all previously mentioned obfuscation techniques to make it much, much more difficult to analyze. To show one example from the JavaScript file I mentioned at the beginning:
aaa=(((0x4435,7.)>=(.61,9.12e2)?(1,4.033e3):(266,7.1e1)),((0x97<=.1?7.616e3:2.176e3),(.39<8e0?document:2032)))
All of this results in the document object being assigned to the variable aaa. Simple and effective.
You can also see why signature based scanning is doomed to fail here – there are so many obfuscation possibilities that signatures simply can’t cope with all that. Luckily, some (most?) anti-virus vendors are implementing behavior based detection or they are embedding their programs deeply into the JavaScript interpreter which allows them to scan values after obfuscation (the whole blob of code results in a document.write() call, no matter how the attackers call it).
--
Bojan
INFIGO IS
Comments