Last Updated: 2014-05-01 17:11:53 UTC
by Johannes Ullrich (Version: 1)
Microsoft will release a special update later today (10am PT, 1pm ET, 7pm UTC) fixing the Internet Explorer vulnerability which has been used in targeted attacks recently. The vulnerability was announced late last week and affects Internet Explorer 6 and later on Windows versions back to Windows XP. The patch will be published as MS14-021 in line with the May update which is still expected for Tuesday, May 13th.
We do rate this bulletin as "PATCH NOW!" for clients. Even though many organizations started to move away from Internet Explorer as a primary browser, it may still launch in some cases and unless you are using a non-Microsoft operating system you are likely vulnerable. Even servers should apply this patch, but it is less likely that the vulnerability is exposed on a server. Microsoft downplays the risk of the vulnerability for servers by labeling it as "Moderate" due to the crippled default configuration of Internet Explorer on servers.
The patch pre-announcement does specifically list Widnows XP SP3 as vulnerable, indicating that the patch may cover Windows XP SP 3 even though no more patches were expected for Windows XP.
Overview of the May 2014 Microsoft patches and their status.
|#||Affected||Contra Indications - KB||Known Exploits||Microsoft rating(**)||ISC rating(*)|
|MS14-021||Vulnerabilities in Internet Explorer|
|Microsoft Internet Explorer
|KB 2963983||Used in targeted exploits.||Severity:Critical
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
- We use 4 levels:
- PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
- Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
- Important: Things where more testing and other measures can help.
- Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
- The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
- The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
- Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
- All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.
(**): The exploitability rating we show is the worst of them all due to the too large number of ratings Microsoft assigns to some of the patches.
Last Updated: 2014-05-01 16:38:30 UTC
by Johannes Ullrich (Version: 1)
My little "lab of vulnerable devices" is still getting regular visits from script kiddies world wide. By now, I replaced some of the simulated honeypots with actual devices, giving me a bit a more accurate view of what is happening and how attackers are distinguishing honeypots from real devices. For example, the DVR I set up with default telnet credentials is getting regularly visited and the following command tends to get executed first:
/bin/busybox;echo -e '\147\141\171\146\147\164'
The output is busybox "help" screen, followed by the characters represented by the "echo" command. The characters are represented in octal in this case.
For example, on my busybox DVR:
[root@dvrdvs /] # echo -e '\101\102\103\104\105\106'
On the other hand, the same command on my MAC or a "normal" Linux system:
$ echo -e '\101\102\103\104\105\106'
(the actual string used is a bit different but spells out a word I didn't feel comfortable posting here)
I also set up a little web based scanner to test for vulnerable DVRs. The scanner will try to connect via telnet using the common default credentials "root" and "12345". If the login is successful, the scanner will try to run "ps" to look for the "cmd.so" entry commonly associated with the litecoin miner we found recently on these devices. You can find the scanner at https://isc.sans.edu/tools/dvrtest.html . By default, it will just scan the IP address you are connecting from. If you log in, you may specify other IP addresses. Please only use against IP addresses you are authorized to scan.
And a quick update on the "honeypot fingerprinting": I am also seeing "echo -e \\x51\\x51" . But this appears to return "QQ" no matter if it is running on the DVR or a normal Linux system.