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

Posted in General Security, Information Leaks on 1 December, 2009 by Alec Waters

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

Posted in General Security, Information Leaks on 25 November, 2009 by Alec Waters

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

Posted in General Security, Malware on 17 November, 2009 by Alec Waters

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?

Posted in General Security, Malware on 17 November, 2009 by Alec Waters

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

Posted in General Security, Malware on 15 November, 2009 by Alec Waters

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!

Posted in General Security, Malware on 13 November, 2009 by Alec Waters

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?

Posted in General Security, Malware on 13 November, 2009 by Alec Waters

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?

Information Escapology, part two – The Perils of Top Posting

Posted in General Security, Information Leaks on 3 November, 2009 by Alec Waters

Posting styles are a matter of personal choice; top posting is probably the most common one, possibly influenced by the design of everyday email clients. When replying to a message, software like Microsoft Outlook will put the original message below the caret, leading to an ever-growing top-posted exchange between the participants.

I’m not going incite a flame war by debating the various merits of each posting style, but I do have a word of caution.

With a top-posted conversation, it’s very easy to get into the cycle of hit-reply->type->hit-send. The context for your thoughts is the message you are directly replying to, the last one in the chain; it’s easy to lose track of what’s been said previously.

The problem comes when you introduce a third party to the conversation – how many times have you received an email like the one below that arrived in Tim’s inbox:

From: Bob, BigCorp CEO
To: Ken, BigCorp HR Director; Tim, IT Support
Subject: RE: Outlook

Tim,

Email seems really slow today. Please could you investigate as a priority.

Bob

——– Original Message ——–
From: Ken, BigCorp HR Director
To: Bob, BigCorp CEO
Subject: RE: Outlook

It’s not just you. Every message I’ve sent today has taken ages to get through.

Ken

——– Original Message ——–
From: Bob, BigCorp CEO
To: Ken, BigCorp HR Director
Subject: RE: Outlook

Is it just me, or is email really slow today?

Bob

——– Original Message ——–
From: Ken, BigCorp HR Director
To: Bob, BigCorp CEO
Subject: RE: Outlook

That’s true, but he’s better at his job than the other two are at theirs. Perhaps we should cut his salary as well as let someone go?

Ken

——– Original Message ——–
From: Bob, BigCorp CEO
To: Ken, BigCorp HR Director
Subject: RE: Outlook

Can we get rid of Brian? He gets paid twice what the others do.

Bob

——– Original Message ——–
From: Ken, BigCorp HR Director
To: Bob, BigCorp CEO
Subject: RE: Outlook

Possible candidates:

Sue, from design.
Tim, from IT.
Brian, from marketing.

Ken

——– Original Message ——–
From: Bob, BigCorp CEO
To: Ken, BigCorp HR Director
Subject: Outlook

Things aren’t looking good. We’re going to have to let some people go. Any thoughts on who?

Bob

It’s perhaps a silly example, but you get the idea. Bob and Ken’s focus has shifted from their company’s impending doom to a technical matter, and they’ve inadvertently disclosed to Tim far more than they intended to. The “top post by design” nature of their email clients has caused them to lose awareness that this email exchange is getting longer and longer and is containing more and more information.

The next time you receive an email with RE: in the subject line, scroll down and see how far the rabbit hole goes. The next time you send a reply, make sure you know exactly what you’re sending. Otherwise you’ll end up on the receiving end of Tim, Sue and Brian…

Securitas Vigilantiae Instantis Praemium

Posted in General Security, NSM, Why watch the wire? on 28 October, 2009 by Alec Waters

The inner title page of MI5’s authorised history shows one of the Service’s past logos, bearing the motto: “Securitas Vigilantiae
Instantis Praemium”, intended to mean “Security is the reward of unceasing vigilance”. This seems to me to be as good a motto now as it was seventy years ago.

An enterprise has numerous tools at its disposal to control what happens on its infrastructure. Some examples are technical controls (such as port filtering, or blocking access to certain types of website) and non-technical controls (such as Acceptable Use Policies, violation of which could lead to disciplinary action).

Controls like these describe what you hope should be happening on your network, which isn’t necessarily what is happening. Controls may have been:

  • Intended, but not actually implemented at all
  • Improperly implemented
  • Removed
  • Changed
  • Circumvented (intentionally or otherwise)
  • Or they may not be as effective as you’d have hoped (anti-virus is a good example).

Implementing a control and then leaving it to its own devices doesn’t seem like a viable tactic. Rather than believing it to be effective, we need to make sure it is effective through strategies like the collection of information and the (unceasing) vigilance to detail required to extract the greatest meaning from it.

By doing this, you can verify the effectiveness of your controls. When things go wrong, you can use what you’ve collected to help you understand what happened and how you can modify your controls to help prevent it from happening again.

Without vigilance, we have our head in the sand, hoping for the best. If our vigilance is not unceasing, Murphy’s Law dictates that something Bad will happen the moment we take our eye off the ball.

“Securitas Vigilantiae Instantis Praemium” hardly ranks as catchy, but it certainly hits the nail on the head. Well, one of the nails, anyway.

Information Escapology

Posted in General Security, Information Leaks on 16 October, 2009 by Alec Waters

Any sensible IT system isn’t going to store passwords in clear text, nor will it transfer them over a network in any fashion that makes eavesdropping feasible. Yet some days I get a nice list of user passwords emailed to me, a list created without the need for keyloggers, social engineering or psychic powers. The list is created by my own users, aided and abetted by the system that’s designed to protect their passwords, not leak them. Let’s see how the password goes on its journey from the user’s brain to my inbox.

It’s Monday morning, and Joe.User hasn’t had his coffee. He sits at his keyboard and tries to get the day started:

CTRL-ALT-DELETE… joe.user… jo3i5l33t… <return> … damn, failed login… try again… joe.user… <tab> jo3i5l33t… <return> …ah, I’m in!

The failed login was due to Joe missing <tab> the first time around – the focus didn’t move from the username field to the password field, so he tried to login as a user called “joe.userjo3i5l33t” with no password.

That’s not so bad, is it? Well, depending on how hard you’re listening to your network and your level of vigilance to detail, Joe’s password is well on its way to publication:

  • Depending on the audit policy in use, Joe’s login failure as “joe.userjo3i5l33t” will leave an impression in the event log of the local machine, and also the domain controller that processed the request. The log impression will contain the composite of Joe’s username and password because that was what he typed into the username field.
  • In my specific case, the domain controller’s logs are harvested at five-minute intervals into a security event correlator wotsit (a Cisco CS-MARS, in this case). Joe’s password takes another step closer to me.
  • Every day, the MARS emails a report of failed logins to me, primarily so I can spot (albeit retrospectively) things like brute-force login attempts. Most of the time the report lists innocent login failures, but today I have a bonus – Joe’s username+password combo.

So now I serendipitously know Joe’s password, thanks to the written record that now exists in several places (Joe’s machine, the domain controller, the MARS and my inbox).

There are other flavours of this leak:

  • Sometimes a user will omit their username altogether and enter their password in the username field. The login will fail, leaving the password in a log entry. It’s quite simple to determine the username that owns the password – the chances are, the next valid login to the same workstation will be from the user in question.
  • If there is a KVM switch in use, sometimes the user uses their credentials for system A when the KVM is actually showing them system B. System B’s administrators now have a valid login to system A.

So, only our diligent security admins are seeing this, right? They’re the ones who read these reports, and they’re the guys we trust, right?

  • Server administrators will be able to see the contents of their own eventlogs.
  • If emails are stored centrally for a period of time in line with corporate policy, the email administrators can potentially find this information.
  • The screen-scraping/email-copying malware on my PC might be sending this stuff to who-knows-where.

The point is that the scope of Joe’s password leak is potentially quite large (and may even extend outside the bounds of our own enterprise). The consequences of the leak will of course depend on who sees the information and what they do with it.

A diligent, trustworthy admin will force Joe to change his password at the earliest opportunity, rendering the leak moot. An evil admin will just use Joe’s password, given that Joe is the CEO and all. Perhaps I’d like to read his emails, or open that document called salaries.xls? Hmm, I wonder if Joe habitually re-uses passwords in other places? Does he have a GMail account? Or eBay? Amazon? I’ll be back in a tick, I’ve got some shopping to do…