Sunday, October 25, 2015

Post #12 (Or... "NXDOMAIN, NXFORSHAME!")

I am not saying this is a rare occurrence. In fact, if I were to bet, I would bet that a large portion of major ISPs engage in this particular practice in some form or another. This was, however, the first time I had seen it in action so far.

Let's start with a little definition. NXDOMAIN, as defined by RFC2308, is another name for the "Name Error" code mentioned in RFC1035. This code is defined as signifying "...that the domain name referenced in the query does not exist." So, to put this into an example, if I try to browse to "faxebool.con", when an authoritative name server receives the quest, it will flag the query with the NXDOMAIN code to signify that the domain does not exist. This flag can be handled in a number of ways, but if you want to see how Verizon handles them versus, say, OpenDNS...

As you can see, Verizon is happy to return an IP address for a domain that OpenDNS is convinced doesn't exist.

And if we look at a packet capture for these requests?

Again, Verizon's response admitting that the domain doesn't exist, but happily returning an IP anyway.

So, which of these requests can we believe? Well, both Verion and OpenDNS respond with the 0x3 code (the "Name Error" code), but the difference is that Verizon still returns an IP, whereas OpenDNS does not. The natural thing to ask now is... what on earth lives at IP 92.242.140.21? The WHOIS tool over at DomainTools supplies the following information:

IP Location United Kingdom United Kingdom Belfast Barefruit Ltd.

ASN United Kingdom AS45028 BAREFRUIT-AS Barefruit Ltd Autonomous System (registered Apr 23, 2008)

Resolve Host unallocated.barefruit.co.uk

Whois Server whois.ripe.net

IP Address 92.242.140.21

Reverse IP 12 websites use this address.

...

netname: BAREFRUIT-ERRORHANDLING

...

I did some research, and here is how Barefruit describes their business model (pulled from the Barefruit opt-out page):

"Using Barefruit for DNS and HTTP error resolution improves the user experience for the vast majority of Internet users by suggesting relevant alternatives as opposed to serving unintelligible error messages."

If you want some more information on Barefruit and their practices, check out this Wikipedia page.

If you want to see an example of the page I got when I tried browsing to "faxenool.com" while having my primary DNS server set as 71.243.0.12, take a look here.

I do not want to get into the habit of discussing opinions on this blog if at all possible, but I would at least like to show you how I found out about this practice:

The anti-virus alert that was constantly appearing on a client's machine that led me to this issue.

I sussed this issue out once I knew that the internal Lync domain mentioned in the query did not, in fact, exist, and certainly if it did exist would not be located in the UK.

Again, I am not going to state whether or not this practice should be frowned upon, but I will state that it is certainly something that a lot of people are not aware even takes place.

Oh, and in case you were courious, you can always opt out of this service by changing your DNS addresses from 71.243.0.12 & 68.237.161.12 to 71.243.0.14 & 68.237.161.14, at least in the case of Verizon. Or you could, you know, just use a DNS server not provided by your ISP.

Stay safe out there.

Saturday, October 24, 2015

Post #11 (Or... "PLZ ENABLE UR MACROSES")

This is funny. I mean, we all know that attackers often grapple with grammatical/spelling errors, but this one for some reason just made me chuckle.

We had a client receive an e-mail letting them know that a payment for $18k+ was ready for them. The e-mail had .DOC file attached. Of course, I told the client to delete the e-mail entirely from their system, but not before I was able to grab a sample for analysis.

At the time of this writing, VirusTotal shows that 0% of engines detect this sample... and this is down from our original submission of the sample. JOE Sandbox Document Analyzer shows only a 24% malicious score, and even that score is accrued from points I consider to be unimportant. So, what gives with this sample? Is it truly soooper secret?

Turns out... no, it is not. Firstly, laugh at this screenshot.

OH NOES! MAI MACROSES R DISABLED!

So, clearly the attacker can't spell. That, alone, is not a candidate for dismissing a sample, so let's do some analysis. Firstly, let's check the document's metadata with the awesome exiftool:

ExifTool Version Number : 9.97

File Name : M51ZJQOBOO138A.doc

Directory : ./source

File Size : 202 kB

File Modification Date/Time : 2015:10:22 09:55:35-04:00

File Access Date/Time : 2015:10:23 11:35:41-04:00

File Creation Date/Time : 2015:10:23 11:35:41-04:00

File Permissions : rw-rw-rw-

File Type : DOC

File Type Extension : doc

MIME Type : application/msword

Title :

Subject :

Author : IhpSPjjDqDF

Keywords :

Comments :

Template : Normal.dotm

Last Modified By : Y0er9dHL

Revision Number : 3

Software : Microsoft Office Word

Total Edit Time : 1.0 minutes

Create Date : 2015:10:22 22:45:00

Modify Date : 2015:10:22 23:19:00

Pages : 1

Words : 4334

Characters : 24704

Security : None

Code Page : Windows Cyrillic

Company :

Lines : 205

Paragraphs : 57

Char Count With Spaces : 28981

App Version : 15.0000

Scale Crop : No

Links Up To Date : No

Shared Doc : No

Hyperlinks Changed : No

Title Of Parts :

Heading Pairs : Title, 1

Comp Obj User Type Len : 32

Comp Obj User Type : Microsoft Word 97-2003 Document


ExifTool Version Number : 9.97

File Name : R4PHYGX.doc

Directory : C:/tempinst/OfficeMalScanner/OfficeMalScanner/source

File Size : 192 kB

File Modification Date/Time : 2015:04:21 09:07:34-04:00

File Access Date/Time : 2015:05:28 07:29:01-04:00

File Creation Date/Time : 2015:05:28 07:29:01-04:00

File Permissions : rw-rw-rw-

File Type : DOC

File Type Extension : doc

MIME Type : application/msword

Title :

Subject :

Author : jiwdj

Keywords :

Comments :

Template : Normal.dotm

Last Modified By : Owner

Revision Number : 2

Software : Microsoft Office Word

Total Edit Time : 0

Create Date : 2015:04:21 10:34:00

Modify Date : 2015:04:21 10:34:00

Pages : 1

Words : 107

Characters : 614

Security : None

Company : SPecialiST RePack

Lines : 5

Paragraphs : 1

Char Count With Spaces : 720

App Version : 15.0000

Scale Crop : No

Links Up To Date : No

Shared Doc : No

Hyperlinks Changed : No

Title Of Parts : ,

Heading Pairs : Title, 1, Название, 1

Code Page : Windows Cyrillic

Hyperlinks : http://office365.com/

Comp Obj User Type Len : 32

Comp Obj User Type : Microsoft Word 97-2003 Document

I have, as you can see, included a second command that actually includes a sample of a .DOC file that drops Dridex, just so you can see something side-by-side. But this metadata proves nothing. Next, let's turn to the ever-useful OfficeMalScanner:

+------------------------------------------+

| OfficeMalScanner v0.61 |

| Frank Boldewin / www.reconstructer.org |

+------------------------------------------+

[*] INFO mode selected

[*] Opening file .\source\M51ZJQOBOO138A.doc

[*] Filesize is 206848 (0x32800) Bytes

[*] Ms Office OLE2 Compound Format document detected

---------------------------------------------

[Scanning for VB-code in M51ZJQOBOO138A.DOC]

---------------------------------------------

-----------------------

No VB-Macro code found!


+------------------------------------------+

| OfficeMalScanner v0.61 |

| Frank Boldewin / www.reconstructer.org |

+------------------------------------------+

[*] INFO mode selected

[*] Opening file .\source\R4PHYGX.doc

[*] Filesize is 196096 (0x2fe00) Bytes

[*] Ms Office OLE2 Compound Format document detected

--------------------------------------

[Scanning for VB-code in R4PHYGX.DOC]

--------------------------------------

Module1

Module2

Module3

Module4

Module5

ThisDocument

-----------------------------------------------------------------------------

VB-MACRO CODE WAS FOUND INSIDE THIS FILE!

The decompressed Macro code was stored here:

------> C:\TempInst\OfficeMalScanner\OfficeMalScanner\R4PHYGX.DOC-Macros

-----------------------------------------------------------------------------

Here is the funny part. For some reason, this document contains no macros. You can see what an actual malicious document returns by reviewing the second sample. So, you can now see why this document is not being flagged by scanners; it isn't malicious at all!

I am not going to state any reasons why this document began circulating the net without being completed, but I can say that whatever the reason, I certainly got a laugh out of it. That, and this seemed as good as time as any to demonstrate two tools that I am growing to love more and more every time I use them, exiftool and OfficeMalScanner.

Cheers!

Want some artifacts? The .ZIP password is prescomm.

p11_artifacts.zip

Friday, October 23, 2015

Post #10 (Or... "Oops! My Headers Leaked!")

This is simple. Very simple. But, hey, it was nice to see something other than SSL/TLS, RC4, and certificate RSA1024/SHA1 failures for once while doing PCI audit remediation.

IIS as used by OWA leaks a server's LAN IP address in HTTP headers in response to a crafted GET request if the authentication realm has not been properly set (vanilla OWA settings). From the smattering of servers I have run this against, I have to say that a good majority of them are not set properly. It is up to you to decide how useful knowing the LAN IP of a server even from behind a NAT device is, but for my part I could definitely see it coming in handy (file rigged with exploits e-mailed to someone inside the network with the server's LAN IP hardcoded into it, anyone?).

I really just pieced this together from 2 posts that I found online when remediating this issue:

http://archives.neohapsis.com/archives/ntbugtraq/2000-q3/0025.html

http://techtips.fulori.com/2014/09/windows-server-running-iis-fails-pci.html

I then just took the time to write a batch file that will ask for a domain and a port and, voila, it will connect via OpenSSL (the binaries are included in the archive). You then just paste the echoed HTTP requests into the console and allow it to get the headers. If the server is running IIS for OWA and is not configured properly, you will get the LAN IP of the server via the "WWW-Authenticate: Basic realm=" field.

The test utility in action.

So, how do we fix this? Well, I added another script into the archive in the "Fix" folder that will utilize "adsutil.vbs" to change the web services authentication realm to a string of the user's choice. If you have access to the affected server, just copy the "Fix" folder to it and run the batch script. It will stop and start web services for you and prompt you for your desired authentication realm (choose something that does not leak anything overly sensitive, such as "ACME Widget Corp." or "PRIVATE"). Once the fix has been applied, run the testing utility again and check what realm is returned in the headers. If everything went as planned, you should no longer be leaking your server's LAN IP.

Applying the fix.

Like I said, simple test and simple fix, but I wanted to create something that would make it easy for anybody to test for and remediate this issue. Plus, it was fun to do something other than disable protocols/ciphers or upgrade certificates.

Cheers!

DISCLAIMER: Run these tools at your own risk. I will not assume any responsibility for any issues, legal or technical, that arise from the use of these tools.

HTTPLANLeakTester32.zip

HTTPLANLeakTester64.zip