Developers vs Security Scans

As this diary post as SANS by Bojan reminds us, developers cannot and should not rely soley on Security Scans to ensure their application is secure. If you're used to kicking off a scan after you've completed your code such as HP Web Inspect, CAT.NET, Acunetix, Qualys, Nikto, Nessus, or whatever your tool of choice ... please don't forget there is SO MUCH MORE to TEST!

Your business logic you write in various areas of code such as Authentication and Authorization are just as critical. The recent MS14-034, plus the Authenticator flaw Bojan talked about both could've been prevented with simple Unit Testing, Fuzzing, and Business Testing. Validate your input, make sure all desired test cases including boundaries, outliers, etc. work. For example, check max int, min int, 0, negative values, null values, empty string, missing parameters, etc. Validate your conditionals and if statements work. Fuzz in some random data and see where your application breaks. You need to be able to handle all data at all times gracefully and properly. And write your code to fail closed, meaning if it doesn't match any of your criteria (your else statement or default case) then you deny access.

Dig into that code and protect your application!

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

The Assembly Behind MS15-034

Recall I previously blogged about the MS15-034 DoS vulnerability that could blue screen a Windows Server with a simple HTTP request.

Mike Czumak of securitysift.com blogged about the Assembly code behind that Http.sys vulnerability and I thought it might be interesting to attempt to explain a bit of the Assembly language code screenshot in that article.

First here is the code from the article. If you scroll down I'll walk through it line by line.

Unpatched
move ecx, [esi+4]
move eax, [esi]
cmp edx, ecx
jb short loc_6EEF9

loc_6EEF9:
   sub eax, edi
   sbb ecx, edx
   add eax, 1
   adc ecx, 0
   mov [esi], eax
   move [esi+4], ecx


Patched
move ecx, [esi+4]
move eax, [esi]
cmp edx, ecx
jb short loc_6F112

loc_6F112:
   push esi
   push 0
   sub eax, edi
   push 1
   sbb ecx, edx
   push ecx
   push eax
   call _RtlULongLongAdd@20 ;
   test eax, eax
   jl short loc_6F184


First, in both the patched & unpatched version there are 4 lines of code that end with a jump.

move ecx, [esi+4]
move eax, [esi]
cmp edx, ecx
jb short LABEL


First recall that assembly used "registers" to store values for quick use. Registers like 'edi' and 'esi' are index registers used to walk yourself through the stack, arrays, as a pointer, etc. Second recall that registers like 'ecx' and 'edx' and 'eax' are general purpose registers used for doing your mathematics, comparisions, and storing temporary values, etc. Now in this case the first 2 lines are "moving values from the stack into your general purpose registers". Note that in this scenario 'eax' is the upper Range Header value in the MS15-034 vulnerablity (Recall: 18 – 18446744073709551615). In this case 'eax' would have 18446744073709551615 in it. Next is a 'cmp' operand which performs a comparison of the 2 general purpose registers. If edx < ecx then it sets the 'Carry Flag' to true. This is determining if there are any more values to check. The last line is the 'jb' (jump if below) operand which basically says that it will jump if that 'Carry Flag' is true of if edx < ecx. So it jumps to our label that contains the vulnerable code.

loc_6EEF9:
   sub eax, edi
   sbb ecx, edx
   add eax, 1
   adc ecx, 0
   mov [esi], eax
   move [esi+4], ecx


Now in the unpatched 6 lines of code above, it's basically subtracting your lower range header (edi or 18) from your upper range header value (eax or 18446744073709551615). It's also doing an 'sbb' or subtract with borrow on those counters so it'll know how many tests it has yet to perform. Then is does an 'add', setting eax (our upper range header value or 18446744073709551615) to eax + 1. Here in lies the problem! There is an overflow condition that can happen here. The next line of code is an 'adc' which add with carry and keeps those counters moving. Then the final 2 'mov' commands 'move the values of eax and ecx back onto the stack' (just as they were before the function started).

loc_6F112:
   push esi
   push 0
   sub eax, edi
   push 1
   sbb ecx, edx
   push ecx
   push eax
   call _RtlULongLongAdd@20 ;
   test eax, eax
   jl short loc_6F184


Finally let's look at the patched version. Instead of doing that eax + 1 without a check, it does the overflow check by calling the _RtlULongLongAdd function. Now you can't call a function like that without parameters. It takes 5 parameters, so you push those 5 parameters onto the stack (esi, 0, 1, ecx, and eax). Prior to that you also update those counters to keep things moving. Finally you do a 'test' combined with a 'jl' which basically checks to see if after your addition of 2 unsigned integers, did you end up with a negative number? (if so that means you overflow, if not you're good). Thus we are now patched because we're checking and handling the case where we overflow on that eax + 1.

Hope that helps a bit, and happy patching!

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

The Unknowing Insider Threat

Most of the Phishing emails seen attempt to infect the user's workstation. For example, it might plant something that attempts to record and steal banking and user credentials. Or it might encrypt the user's files and ask for a ransom to retrieve those files. Or it might plant malware that makes the workstation part of a larger botnet. All of which is generally Remote to Local or Local to Remote (your workstation talking with the Internet).

But how about Local to Local attacks? Sending a phishing email to an employee, and if they click and open it, it launches an attack on an internal device or server?

I saw two recent blogs that mentioned that concept and thought it was worth mentioning.

First, the great Didier Stevens posted a video blog showing how simple it is to DoS a server using MS15-034 with a macro in a Microsoft Excel document. If you don't recall MS15-034, here's a quick refresher. Imagine this scenario playing out ...
1.) Login to your work computer in the morning
2.) Open your email client
3.) See an email in your inbox titled 'Health Plan Rates'
4.) Open the excel attachment in the email
5.) Get prompted to enable macros
6.) Click enable macros
7.) Unbeknown to you, the Excel macro cycles through all internal IP addresses in your company sending the MS15-034 DoS request
8.) Your IT department getting ticked off at you after they determine that several internal Windows Servers (Sharepoint, Time Tracking, etc.) crashed because of you.


Second, Mike Czumak at SecuritySift.com wrote about a deeper analysis of MS15-034. In his article, he mentioned at the bottom another interesting Shellshock attack. It lead me to consider another similar scenario except worse ... ...
1.) Login to your work computer in the morning
2.) Open your email client
3.) See an email in your inbox titled 'Star Wars Movie Trailer' from your friend
4.) Open the link in the email
5.) Start watching the Movie Trailer
6.) Unbeknown to you, the javascript on the Start Wars Trailer html page is cycling through all internal IP addresses in your company sending Shellshock attempts
7.) Your IT department gets ticked off after they determine that several of their Linux Production servers were compromised and backdoored all because you watched the Star Wars movie trailer.


Why are these attacks interesting? Well, one important thing to note is that major vulnerabilities like MS15-034 and Shellshock were almost immediately patched in your DMZ (or externally exposed devices) if your company is any good at what it does. But it's legit to think that your server teams may have taken a bit more time with your Internal servers (ones that are not exposed to the internet, such as your ERP, Intranet applications, etc.). Thus these attacks may work well after all the hype has died down on the big vulnerabilities. And if there are some internal servers that you just never got around to patching or that you were willing to accept the risk on, guess what, this type of attack might bring back nightmares now!

That human factor is a killer, huh? Phishing attacks are going to be bread and butter for attackers for a long time to come it would seem.

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

Crash 1/3 of the Internet with MS15-034?

SANS Internet Storm Center raised their Threat Level to Yellow today and with very good reason.

Netcraft says in their 2014 report that about 33% of Web Servers on the Internet were Micrsoft IIS. Can you image crashing them all with a simple HTTP request?

With some slight modifications to the trustedsec.com's python test script I was able to use it to cause a Windows 2012 Test Box to immediately Crash and Reboot. Yikes!!!!

It's also bad because on my test windows box, there were no logs (System and application, or IIS Logs) that the request even happened! The only thing I saw was after the server rebooted and you get the standard message below

That's one heck of a DoS! And it's scarier than that, because Microsoft listed this as Remote Code Execution so it's possible that even worse attacks are on the way!

In general the changes needed to the Python script above are ...
- Change the range to an exploitable value that sans mentioned like 18-18446744073709551615
- Change the attack to hit a specific file that exists like a png(it doesn't appear to work on non-existant or redirected files/pages)
- Change the attack to a for loop of multiple requests instead of 1


BOOM, CRASH

Patch and Patch fast.

I did see that somebody named Malik Mesellem (@MME_IT) pasted something similar on pastebin

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