Making sense of the results of the net-entropy experiment

The rest of the net-entropy saga is listed here, but to briefly recap, net-entropy is a tool that can be used to profile the level of “randomness” of network traffic. High entropy traffic like this is usually either encrypted or compressed in nature, and I’m definitely interested in knowing about the presence of the former on my network. I’ve been using net-entropy as a general purpose “randomness detector”, something that the author didn’t really have in mind when he wrote it.

However, drawing meaningful conclusions from the results gathered can be tricky (this is nothing to do with net-entropy itself, and everything to do with the way I’m using it backwards to generically detect randomness). Some of the observed high entropy traffic will definitely fall into the “encrypted” category, like SSH and Remote Desktop. Other stuff will definitely be of the “compressed” flavour, like RTMP on port 1935.

Once this kind of low-hanging fruit has been pruned, the analyst is left with a whole load of unknown high-entropy traffic. If net-entropy’s presence is to be of any value at all when deployed this way, we have to try to make sense of the residual data in some way or another.

One tactic is to fire up Sguil and use its full-content capture to extract and examine each of the unknown high-entropy streams in turn. This is massively labour intensive, but some of the time you’ll find something interesting like HTTPS on a non-standard port (the certificate exchange at the start of the conversation is in clear text, giving you a clue). Most of the time however, you’re left looking at unintelligible garbage. Unsurprising really, given that it’s likely to be either compressed or encrypted…

Given that protocols like SSH, RDP and RTMP can most usually be identified by their port numbers alone and what’s left is unreadable junk, how are we to derive value from these other indicators from net-entropy? I can think of a couple of ways:

• Session contextualisation
• Session profiling on the basis of session duration and frequency, etc

Putting a high-entropy session into context isn’t too labour intensive, and sometimes pays dividends. Let’s say net-entropy has spotted a session from 1.2.3.4:25333 to 4.3.2.1:3377; the full-content capture is unreadable garbage, and the port numbers offer no clues. If we ask the question “was there any other traffic involving 1.2.3.4 and 4.3.2.1 at the same time”, we might get a hint. In this instance, there was a connection from 1.2.3.4:16060 to 4.3.2.1:21, which looks like an FTP command session judging by the port number. When we examine the full-content capture for this session, we can see passive FTP at work:

227 Entering Passive Mode (4,3,2,1,13,49).

The last two numbers denote the port that the client should connect to to transfer a file. Doing the maths, we see that (13 * 256) + 49 = 3377, so we can be pretty confident that our high-entropy traffic in this case was a file transferred over FTP.

If context can’t be established however, all is not lost – we can look at other attributes of the traffic.

A lot of the high-entropy traffic that we see is bound for random ports on IP addresses all over the world, and most of it is related to peer-to-peer apps. In the case of Skype, high-entropy TCP traffic is usually signaling traffic to SuperNodes. Traffic to a given SuperNode  will occur little-and-often for a long period of time until one of the two endpoints goes offline, so net-entropy will be sending you alerts all day long for that specific destination. However, you certainly can’t say for sure that traffic matching this profile is definitely Skype (it could be a keylogger phoning home at regular intervals, for example). As such, examination of the little-and-often class of high-entropy flow doesn’t usually yield any definitive conclusion.

What is definitely interesting is where you have many high-entropy flows to the same destination address and port in a short period of time. We have detected the following by taking this “clustering” approach:

• HTTP on a non-standard port, serving up images (most image formats are compressed, and thereby have a high-entropy signature). As an example, some of the images in search results here come from port 7777. Someone browsing this site will trigger many indicators from net-entropy in a short space of time that refer to this port.
• HTTP proxies. Again, the high-entropy traffic is most commonly as a result of images being transferred.
• SSL/TLSv1 on port 8083, which turned out to be traffic to a SecureSphere web application firewall.

Clusters like this are most easily detected by eye by means of visualisation. The following image is from one of my Cisco MARS reports, and shows a cluster of traffic to port 8083 in orange:

Something “worth looking at” will usually be quite clear from an image like this.

The approach I’ve taken with net-entropy has yielded neither precise nor definitive results (which certainly isn’t a complaint about net-entropy itself – it was never designed to be used the way I’m using it). But, I’ve discovered things that I’d never have known about without it, so I reckon I’ve come out on top!

‘Twas the night before D-DoS

The festive season is upon us again, so I hereby present a yuletide tale of the age old battle between Good and Evil…

 

‘Twas the night before D-DoS, when all through the net
Not a rootkit was stirring, no activity yet.
The victims were chosen, the criminals dared
To hope cash from extortion soon would be theirs.

The targets were nestled all snug in their nets,
Protected from dangerous POSTs HEADs and GETs.
Their NSM sensors, all fed from a Tap,
Kept watch for traffic they knew should be zapped.

When into my inbox there arrived a stern warning,
“Give us your cash, or we’ll DoS you by morning.”
Away to the helpdesk I flew like a flash,
Afraid that my website soon would be trashed.

My lack of response to the blackhat’s demands
Caused him to issue the fatal commands.
Sitting alone in his t-shirt and jeans,
With his tower PC, and eight LCD screens.

Then his dusty old keyboard went clickety-click,
His army of trojans heeded his nick.
More rapid than torrents his botnets they came,
And he whistled, and shouted, and called them by name!

“Now Gumblar! now Koobface! now Storm Worm and Ozdok!
On, Clampi! On, Pushdo! On, Cutwail and Rustock!
Use all your ports! Fear no firewall!
Now DoS away! DoS away! DoS away all!”

As dry leaves before the wild hurricane fly,
Packets were inbound, my bandwidth sucked dry.
So back to the helpdesk in panic I flew,
Only to find that they were DoS’d too!

And then, in a twinkling, I heard through the panic
A cry from the desk of a worker less manic.
As he drew on his pad, his colleagues turned round,
Listened intently to what he had found.

“I know this sounds crazy,” he said through the din,
“I can disrupt the botnet, attack from within”.
“I’ve seen it before, in a film with a spy“,
“’send spike’ is the answer; the trojans will die!”

His eyes-how they twinkled! his dimples how merry!
As he hammered away on a keyboard from Cherry.
He pictured the blackhat – alone, unaware -
“Attacking my botnet? Surely no-one would dare!”

The end of a pen he held tight in his teeth,
It leaked ink that encircled his mouth like a wreath.
He sent spike on its way, and sat back from his desk,
Hoping to neutralise botnets grotesque.

He was chubby and plump, was our evil blackhat,
But his face turned to horror, he froze where he sat.
His botnets revolted and cackled with glee,
Changing his wallpaper to pictures of goatse!

He spoke not a word as the bots went to work,
They emptied the bank accounts held by this jerk.
Their final accomplishment was rather extreme -
They framed him for felonies and called in the SWAT team.

The blackhat defeated by our Hero so gallant,
Away to the pub they went – drink to his talent!
But I heard him exclaim, ‘ere he drove out of sight,
“Happy Christmas to all, and to all a good-night!”

Information Escapology, part five – Careful with That Proxy, Eugene

Back here, I claimed that when presented with a login box web users would blindly enter whichever set of credentials came to mind whether they were relevant or not. It turns out that I had failed to dig deeply enough into the evidence, and was displaying a little bit of defensive avoidance – had I dug deeper and looked at the timings of the authentication exchange and the authentication scheme in use, I’d have seen that nothing of the sort was going on. I’ll put on the dunce’s cap and spend the rest of the lesson facing the wall in the corner of the classroom.

However, the truth is perhaps more interesting. It’s not the user leaking information, their proxy server does it for them without their knowledge.

Part four of this series was written after we noticed failed type 3 logons appearing in the Security event log of an IIS webserver. These log entries were a byproduct of the webserver serving up “401 Unauthorized” messages to visitors, which ties up nicely with what’s written here:

Windows logs logon type 3 in most cases when you access a computer from elsewhere on the network. One of the most common sources of logon events with logon type 3 is connections to shared folders or printers. But other over-the-network logons are classed as logon type 3 as well as most logons to IIS.

The webserver shouldn’t really have been serving up the 401s at all – there was a slight glitch in the site related to a script responsible for producing the CSS for the page being viewed. Its URL looks a bit like this:

http://www.example.com/scripts/mycss.aspx?param1=value1&param2=value2

Under certain circumstances, some clients (later determined to be proxies) would try to access the page like this:

http://www.example.com/scripts/?param1=value1&param2=value2

“mycss.aspx” is missing, so this URL is effectively a request for a directory listing (albeit embellished with parameters) and would normally result in a “403 Forbidden” message. So why the 401s? The scripts virtual directory has the default settings under Directory Security:

…but the “read” permission has been removed; it only allows “Scripts and Executables”:

So when the proxy asks for the URL with mycss.aspx missing, it’s really asking for a directory listing of a directory with no read permissions. This check apparently takes precedence over the check for the “directory browsing” permission, and it causes IIS to want the user to authenticate despite the fact that anonymous access is allowed. Only Integrated Windows authentication (IWA) is configured (since this is specified by default) so this is what IIS will ask the client to do.

What we have here is a situation where Integrated Windows authentication will be invoked, albeit unintentionally. However, this oughtn’t cause any problems for two reasons:

1. Integrated Windows authentication does not work through proxies
2. Integrated Windows authentication will, by default, only be attempted for sites that are in IE’s “Local Intranet” zone

However, certain proxies do Clever Tricks to make IWA work. BlueCoat, for example, uses a redirect to a “Virtual URL” in the Local Intranet zone to trick IE into performing an IWA exchange (see here under “For TRANSPARENT proxies”, and here). A BlueCoat configured like this (when visiting the site described above) will show the user a login box, but not before it has completed an IWA exchange and left the user’s username, machine name, and domain name in the Security event log on the webserver. There is nothing the user can do to prevent this information being leaked.

Surely nobody configures their proxy like this though? The whole reasoning for IWA only working for sites in the Intranet Zone is to prevent exactly this kind of leak from happening. Well, we’ve seen proxies behaving like this from all sorts of places:

• A city council
• A school
• A multinational corporation
• A telecoms giant favoured by Jedi Masters (Yodaphone, or something…)

Not all the proxies concerned are BlueCoats, and not all BlueCoats exhibit the same issue (so it looks like it’s down to the configuration of each individual proxy). If you want to see if your own proxy is leaking, I’ve set up a testbed here. If you’re happy to potentially leak your Windows login name, your machine name and your domain name, click the link, dismiss the login box without entering anything, and drop me a line with your proxy’s public IP address. I’ll let you know if you’re leaking.

Information Escapology, part four – Ask, and ye shall receive

One of the websites we monitor has a teeny problem, in that there is something somewhere on it that that causes the users to see a spurious “401 Unauthorized” message. Tracking down and removing the problem is straightforward, so I don’t want to write about that. I want to write about what the users do when this happens.

The site in question isn’t anything particularly elaborate – it’s public access, and there are no user accounts or login boxes at all. The users are merrily browsing away, when all of a sudden they hit the part of the site that raises the spurious 401s. The net result in this specific case is that the browser starts the HTTP authentication process, and a login box is presented to the user.

Now, what do users do when they see a login box? Despite the fact that this site has no user logins whatsoever, they do what they are conditioned to do…

…which is to type in their username and password.

There is no reason for them to do this. They just seem to see the login box that is a byproduct of the unintentional HTTP authentication process, and type away. They don’t have any credentials for this particular site (because there aren’t any), so they just go ahead and try whichever set comes to mind (Windows login credentials, mostly).

User psychology aside, from an NSM perspective we can harvest quite a bit of information. If the website is using IIS and is set up to use Integrated Authentication, we’ll be able to see (from a full-content capture) the user’s username, their machine name and their Windows domain name. If it’s set up to use Basic authentication, we’ll be able to see their username and password. If we can somehow make different parts of the site use both of these authentication schemes we’ll have the whole lot, plus of course their IP address from the web server logfiles.

It’s an interesting way to take a phishing trip!

Information Escapology, part three – Clippy’s Revenge

In the Good Old Days, the clipboard was a simple thing. Highlight some text, copy, paste it somewhere else. These days it’s a little more comprehensive – if you copy some text, there’s a good chance that the text’s attributes will get copied as well. This may or may not be of consequence, depending on where you paste it.

I came across an email recently where the sender had copied two cells from Excel and pasted them into Outlook along with a question. The stuff pasted from Excel looked like this, all nicely formatted in a table, just as if it were two cells in a spreadsheet:

Policy 6gX1

All business units MUST implement Policy 6gX1

It doesn’t tell me much about the super-secret Policy 6gX1, but the clipboard has preserved the Hyperlink properties of the first cell. Ignoring the fact that WordPress has knackered the link (don’t bother clicking it), here is what it actually was:

<a href=”file:///C:/Documents%20and%20Settings/j.bond/Local%20Settings/Temporary%20Internet%20Files/Project%20Rattlesnake%20verysecret.xlsx#%27Guidance%20Notes%27%21AB23″>Policy 6gX1</a>

What can we tell from this:

• The sender is using Windows XP/Server 2003 or below, belied by the “Documents and Settings” folder
• The sender’s Windows logon account is called j.bond
• Policy 6gX1 is related somehow to Project Rattlesnake
• They’re using a later version of Excel (xlsx extension vs. xls)
• “Project Rattlesnake verysecret.xlsx” is in the IE cache directory, indicating that it’s available for download somewhere
• “Project Rattlesnake versyecret.xlsx” has a sheet in it called “Guidance Notes”
• The “Guidance Notes” sheet is quite large, because the link refers to cell AB23.

Not entirely earthshattering information, but something like this could just provide a social engineer with enough additional context and terminology to establish a credible pretext.

Take care with the clipboard; who knows when Clippy will exact his vengeance!

How cz32ts determines if your site is vulnerable to SQL Injection

cz32ts will append some SQL to a URL given to it by its C&C server at 205.209.143.94, and will fetch the results. It then phones home the results of its mischief like this:

C&C: +OK LINK-SERVER READY
cz32ts: CMD PUTLINK http://some.victim.url?sql=goes&after=this InjectAsp:YES
C&C: Finished.

It’s the InjectAsp:YES that denotes a successful SQL Injection vulnerability assessment. Given the appended SQL described in this post, cz32ts is looking simply for:

|number|

…in the page handed back by the server under test. If this pattern appears anywhere on the page, it will report InjectAsp:YES to the C&C server. Even error reports are sufficient, because they indicate that the injected SQL was executed and that the server is ripe for exploitation:

[Microsoft][ODBC SQL Server Driver][SQL Server]Conversion failed when converting the varchar value ‘|98|’ to data type int.

If you’ve been paid a visit by cz32ts, it’s probably a good idea to replay its requests (based upon the parameter string in your web server’s logfiles) and check the responses for the pattern |number| – if it’s there, you’ve got a vulnerability that needs addressing. A vulnerability that the bad guys know about already!

TL32Sn – feeder for cz32ts?

TL32Sn does Google searches. cz32ts performs tentative SQL Injection reconnaissance. Both are controlled by the same server.

Perhaps TL32Sn’s role in life is to build a list of URLs for cz32ts to try? Perhaps the “inurl” part of TL32Sn’s query represents a fingerprint search for known vulnerable web apps? Once it’s done the Google search and has got a list of results (shortened by the presence of the seemingly irrelevant keyword), does it phone these home to 205.209.143.94 for cz32ts to check out later on?

TL32Sn – twisted cousin of cz32ts and NV32ts

I’ve come across TL32Sn.exe (Anubis report, VirusTotal report), which appears to be related to cz32ts and NV32ts. Aside from the similar format of the name of the executable, it shares the same C&C server at 205.209.143.94.

cz32ts used port 8998 to get a list of URLs to attack, and the same port to report the results back. TL32Sn uses port 8999 instead, and via a command called PHPGETURL retrieves URLs like this:

http://66.102.11.99/search?hl=en&num=100&newwindow=1&q=cholecystokinin+inurl:asp%3Fcontent%3D&start=300&sa=N

http://66.249.89.44/search?hl=en&num=100&newwindow=1&q=chopin+inurl:asp%3Fnode%3D&start=300&sa=N

These are Google searches which TL32Sn duly carries out (the user agent is TL32Sn.exe). There are lots more questions here:

• Why start at result #300?
• Why didn’t they say inurl:”asp?content=” instead of the less effective inurl:asp?content=
• Why are they searching for cholecystokinin and chopin anyway? The two URLs above were fetched within half an hour of one another – perhaps these words are from an ordered list of search terms?

One thing is for certain – 205.209.143.94 is at the heart of all this!

cz32ts – an interesting banana!

I think I’ve found the cz32ts executable – VirusTotal has this to say about it. What is more interesting is what Anubis has to say about it – check out the Network Activity section.

Basically, the executable goes off to a C&C server on 205.209.143.94 for a list of URLs to attack using the GETPHPURL command. It then tries to SQL inject the victim site, using the executable name as its user agent (all of the ones in my capture have i1 as the user agent, because that was the name of the executable I retrieved). Once the SQL injection tests have been carried out, it then reconnects to the C&C server to report the result of the attempt using the CMDPUTLINK command.

I have no idea how cz32ts.exe is distributed, but it would seem like the ideal thing for a dropper to pull down and set to run once on startup.

Anyone fancy shutting down 205.209.143.94?

cz32ts – evil twin of NV32ts?

There is an update to this post here.

In the past, we’ve seen various automated SQL Injection attempts bearing a User-Agent of NV32ts. It’s all a little odd, since:

• The attempts are dead easy to spot, thanks to the user agent (there’s even a Snort rule for detecting it)
• The attempts could be described as recon-only, since they didn’t seek to change anything.

Two injection attempts would be made by the attacker. The injected SQL would look like this:

%20And%20char(124)%2b(Select%20Cast(Count(1)%20as
%20varchar(8000))%2Bchar(124)%20From%20[sysobjects]
%20Where%201=1)>0

And this:

‘%20And%20char(124)%2b(Select%20Cast(Count(1)%20as
%20varchar(8000))%2Bchar(124)%20From%20[sysobjects]
%20Where%201=1)>0%20and%20”=’

These two cover the cases for vulnerable non-string and string parameters, and each case would be attached to the end of  the URL under test, after the last parameter. We’d usually see a spate of attempts in a short space of time from different source IP addresses, possibly suggesting that some botnet or other is doing all the work (possibly even Conficker).

Yesterday, we saw another run of attempts with the same pattern. A handful of source IP addresses targetted the same victim websites, each trying the same URL twice, appending the same two SQL statements as above. The only difference is the user agent – what was NV32ts has become cz32ts.

It’s still something of a mystery, though. Why use such a distinctive user agent? Why change it? What are the baddies looking for? If they’re going to go to the bother of scanning for sites vulnerable to SQL injection, why don’t they just try to inject something? Why conduct all this recon, when it would be difficult to reliably detect if you’re actually talking to a vulnerable site? Are the botmasters selling lists of potentially vulnerable sites rather than exploiting them themselves?

Any ideas?