Botnets

S. Korea Cyber Attack Crashes Navigation Devices. Time to fuzz your GPS?

South Korea suffered a major cyber attack yesterday. The origin of the attack seems to be China at the moment, but that is far from being definite.

I happened to be in one of the (several) cyber security operation centers, by pure coincidence. I had a chance to see events unravel in real time. Several banks have been hit (including the very large shinhan bank) and a few broadcasting channels.

The damage is hard to assess, since it’s now in everyone’s advantage to blame the cyber attack on anything from a system crash to the coffee machine running out of capsules. Budget and political moves will dominate most of the data that will be released in the next few days.
It’s clear, however, that the damage substantial. I reached out to a few friends in technical positions at various MSPs and most had a sleepless night. They’ve been hit hard.

The most interesting part of this incident, in my opinion, was a report on car GPS crashing while the attack was taking place. I haven’t seen a news report about that yet, and I couldn’t personally verify it (as I mentioned, I was stationary at the time, watching the frantic cyber-security team getting a handle on a difficult situation) but this is making rounds in security forums and a couple of friends confirmed to me that their car navigation system crashed and had to be restarted, at the exact time the attack was taking place.

The most likely explanation is that the broadcasting companies, who send TPEG data to the GPS devices (almost every car in Korea has a GPS device, almost all get real-time updates via TPEG), had sent malformed data which caused the devices to crash. This data could have been just a result of a domino effect from the networks crashing, or it could have been a very sophisticated proof-of-concept by the attacker to see if they can create a distruption. Traffic in Seoul is bad even on a normal day; without GPS devices it can be a nightmare.

Which brings up an interesting point about fuzzing network devices. TPEG fuzzers have been available for a while now (beSTORM has a TPEG module, and you can easily write your own TPEG fuzzer). The difficult part is getting the GPS device to communicate with the fuzzing generator; this is something the GPS developer can do (but probably won’t) but it is also possible for a government entity to do the necessary configuration to make that happen, given the proper resources or simply by forcing the vendors to cooperate.

The choice of the attacker to bring down the broadcasting networks might be deliberate: other than knocking TV and radio off the air (an obvious advantage in a pre-attack strike) the broadcasting networks control many devices who rely on their data. Forcing them to send malformed data to crash a variety of devices can have interesting implications. If I was a little more naive, I would predict that this will push governments around the world to focus more on fuzzing to discover these kind of vulnerabilities before they see their adversaries exploit them. But in the world we live in, they will instead throw around the phrase “APT” and buy more “APT detection products” (an oximoron if I’ve ever heard one). Thank god for APT, the greatest job saving invention since bloodletting.

An detailed analysis of the attack here:
http://training.nshc.net/KOR/Document/virus/20130321_320CyberTerrorIncidentResponseReportbyRedAlert(EN).pdf

Flame on!

I have been reading about the new Flame (aka Flamer, aka sKyWIper) “supervirus.”

[AAaaaarrrrrrggggghhhh!!!!!!!!  Sorry.  I will try and keep the screaming, in my “outside voice,” to a minimum.]

From the Telegraph:

This “virus” [1] is “20 times more powerful” than any other!  [Why?  Because it has 20 times more code?  Because it is running on 20 times more computers?  (It isn’t.  If you aren’t a sysadmin in the Middle East you basically don’t have to worry.)  Because the computers it is running on are 20 times more powerful?  This claim is pointless and ridiculous.]

[I had it right the first time.  The file that is being examined is 20 megabytes.  Sorry, I’m from the old days.  Anybody who needs 20 megs to build a piece of malware isn’t a genius.  Tight code is *much* more impressive.  This is just sloppy.]

It “could only have been created by a state.”  [What have you got against those of us who live in provinces?]

“Flame can gather data files, remotely change settings on computers, turn on computer microphones to record conversations, take screen shots and copy instant messaging chats.”  [So?  We had RATs that could do that at least a decade ago.]

“… a Russian security firm that specialises in targeting malicious computer code … made the 20 megabyte virus available to other researchers yesterday claiming it did not fully understand its scope and said its code was 100 times the size of the most malicious software.”  [I rather doubt they made the claim that they didn’t understand it.  It would take time to plow through 20 megs of code, so it makes sense to send it around the AV community.  But I still say these “size of code” and “most malicious” statements are useless, to say the least.]

It was “released five years ago and had infected machines in Iran, Israel, Sudan, Syria, Lebanon, Saudi Arabia and Egypt.”  [Five years?  Good grief!  This thing is a pretty wimpy virus!  (Or self-limiting in some way.)  Even in the days of BSIs and sneakernet you could spread something around the world in half a year at most.]

“If Flame went on undiscovered for five years, the only logical conclusion is that there are other operations ongoing that we don’t know about.”  [Yeah.  Like “not reproducing.”]

“The file, which infects Microsoft Windows computers, has five encryption algorithms,”  [Gosh!  The best we could do before was a couple of dozen!]  “exotic data storage formats”  [Like “not plain text.”]  “and the ability to steal documents, spy on computer users and more.”  [Yawn.]

“Components enable those behind it, who use a network of rapidly-shifting “command and control” servers to direct the virus …”  [Gee!  You mean like a botnet or something?]

 

Sorry.  Yes, I do know that this is supposed to be (and probably is) state-sponsored, and purposefully written to attack specific targets and evade detection.  I get it.  It will be (marginally) interesting to see what they pull out of the code over the next few years.  It’s even kind of impressive that someone built a RAT that went undetected for that long, even though it was specifically built to hide and move slowly.

But all this “supervirus” nonsense is giving me pains.

 

[1] First off, everybody is calling it a “virus.”  But many reports say they don’t know how it got where it was found.  Duh!  If it’s a virus, that’s kind of the first issue, isn’t it?

The political risks of a DDoS

In Korea, the ruling party performed a DDoS attack, and as result the chairman and most of its officials will resign. Most likely, it will be disbanded completely.
This is probably the most severe result of a cyber attack yet. Of course, the only reason they know who to blame, is because the guy responsible for the attack admitted guilt. DDoS is all fun and games until the guy you hired to do it spills the beans.

Shaw and Spamhaus

I seem to be back on the air.

A few observations over this whole affair:

(Sorry, I’ve not had time to put these in particular order, and some of the point may duplicate or relate …)

1) I still have absolutely no idea why Shaw cut me off.  They keep blaming Spamhaus, but the only links they offer me as evidence clearly show that there is no “bad reputation” in the specific IP address that I am currently using, only a policy listing showing one of Shaw’s address ranges.

2) I got absolutely no warning from Shaw, and no notice after the fact.

3) Shaw’s spam filtering is for the birds.  Today I got two messages flagged as spam, for no clear reason I could see.  They were from a publisher, asking how to send me a book for review.  The only possible reason I could see was that the publisher copied three of my email addresses on the same message.  A lot of people do that, but it usually doesn’t trip the spam filter.  Today it did.  (Someone else with Shaw “service” tried to send out an announcement to a group.  Since he didn’t have a mailing list server, he just sent out a bunch of messages.  Apparently that got *his* account flagged as spamming.)  I also got the usually round of messages from security mailing lists tagged as spam: Shaw sure has something against security.  And at least one 419 scam got through unflagged today, despite being like just about every other 419 in the world.  (Oddly, during this period I’ve noted a slight uptick in 419s and phishing in general.)

4) Through this episode I had contact with Shaw via email, phone, “live chat,” and Twitter.  I follow ShawInfo and Shawhelp on Twitter.  On Twitter, I was told to send them a direct message (DM).  I had, in fact, tried to do that, but Shaw doesn’t accept direct messages by default.  (Since I pointed that out to them, they now, apparently accept them from me.)  They sent me public messages on Twitter, and I replied in kind.  Through the Twitter account they also informed me that error 554 is “poor reputation” and is caused by sending too many emails.  They didn’t say how many is too many.  (Testing by someone else indicated something on the order of 50-100 per hour, and I’ve never done anything near that scale.)

5) The “live chat” function installs some software on your (the client) machine.  At least two of the pieces of software failed the digital signature verification …

6) The “information” I got from Shaw was limited.  The first (phone) support call directed me to http://www.senderbase.org/senderbase_queries/detailip?search_string=70.79.166.169  If you read the page, the information is almost entirely about the “network” with only a few (and not informative) pieces about the IP address itself.  (I did, separately, confirm that this was my IP address.)  The bulk of the page is a report on addresses that aren’t even in the same range as I am.  About halfway down the right hand side of the page is “DNS-based blocklists.”  If you click the “[Show/Hide all]” link you’ll notice that four out of five think I’m OK.  If you click on the remaining one, you go to http://www.spamhaus.org/query/bl?ip=70.79.166.169  At the moment, it shows that I’m completely OK.  At the time I was dealing with Shaw, it showed that it’s not in the SpamHaus Block List (SBL) or the XBL.  It was in the PBL (Policy Block List), but only as a range known to be allowed to do open sending.  In other words, there is nothing wrong with my IP address: Shaw is in the poop for allowing (other) people to send spam.

7) The second (live chat) support call sent me to http://www.mxtoolbox.com/SuperTool.aspx?action=blacklist%3a70.79.166.169+  Again, this page showed a single negative entry, and a whole page of positive reports.  The single negative entry, if pursued, went to the same Spamhaus report as detailed above.

8) At the time, both initial pages, if followed through in terms of details, led to http://www.spamhaus.org/pbl/query/PBL164253 giving, as the reason, that “This IP range has been identified by Spamhaus as not meeting our policy for IPs permitted to deliver unauthenticated ‘direct-to-mx’ email to PBL users.”  Again, Shaw’s problem, not mine.  However, that page has a link to allow you to try and have an address removed.  However, it says that the “Removal Procedure” is only to be used “If you are not using normal email software but instead are running a mail server and you are the owner of a Static IP address in the range 70.79.164.0/22 and you have a legitimate reason for operating a mail server on this IP, you can automatically remove (suppress) your static IP address from the PBL database.”  Nevertheless, I did explore the link on that page, which led to http://www.spamhaus.org/pbl/removal/  Again, there you are told “You should only remove an IP address from the PBL if (A) the IP address is Static and has proper Reverse DNS assigned to your mail server, and (B) if you have a specific technical reason for needing to run a ‘direct-to-MX’ email service, such as a mail server appliance, off the Static IP address. In all other cases you should NOT remove an IP address from the PBL.”  This did not refer to my situation.  Unfortunately, THESE TWO PAGES ARE INCORRECT.  If you do proceed beyond that page, you get to http://www.spamhaus.org/pbl/removal/form  This page does allow you to submit a removal request for a dynamic IP address, and, in fact, defaults to dynamic in the form.  It was only on the last part of the second call, when the Shaw tech gave me this specific address, that I found this out.  For this I really have to blame Spamhaus.

9) In trying to determine if, by some weird mischance, my computer had become infected, I used two AV scanners, one spyware scanner, and two rootkit scanners.  (All results negative, although the Sophos rootkit scanner could have been a bit clearer about what it had “found.”)  Of course, I’ve been in the field for over two decades.  How would the average user (or even a security professional in a non-malware field) even know that there are different types of scanners?  (Let alone the non-signature based tools.)

Shaw Cable security (lack-of) support

As noted, Shaw is not very helpful with spam.  I’ve been getting spam from Marlin Travel, and from a band of people selling recuriting seminars, for a number of years.  I have been reporting this spam (to Shaw, and their supposedly automated spam filters) on at least a weekly basis for years.  Occasionally they deign to mark one of the messages as spam, but not on anything like a consistent basis.

Spam filtering is not transparent.  You can turn it on, or off.  You can have the spam go to the bit bucket, or get flagged.  There are no other options, and you have no information on how it works (or doesn’t).  (Heck, Vancouver Community Net [formerly Free-Net] does better than that.)

On my non-support call with Shaw, the agent did correctly identify the IP address I am (currently) using.  I have no idea when last it was switched.  Looking it up on senderbase is not supremely informative: there doesn’t seem to be any information on the address itself, other than the fact that it’s not in the SpamHaus Block List (SBL) or the XBL.  It is in the PBL (Policy Block List), but only as a range known to be allowed to do open sending.  In other words, there is nothing wrong with my IP address: Shaw is in the poop for allowing (other) people to send spam.

Meantime I have confirmed that, as I already knew, there is nothing malware or spam related on my machine.  Nothing that MSE detects.  Nothing that Vipre detects.  Nothing that Spybot detects.  At the moment I’m running the Sophos rootkit detector, and F-Secure’s Blacklight.  They haven’t found anything either.  I am, of course, morally certain that Shaw was lying to me about the possibility, but, unlike them, I’m not arrogant enough not to check.  I was right: they are idiots.  And, with their non-support, have cost me a lot of valuable time checking a clean machine.  (Plus not providing the Internet service I’m paying for.)

“Extrusion Detection”, Richard Bejtlich

BKEXTDET.RVW   20101023

“Extrusion Detection”, Richard Bejtlich, 2006, 0-321-34996-2,
U$49.99/C$69.99
%A   Richard Bejtlich www.taosecurity.com taosecurity.blogspot.com
%C   P.O. Box 520, 26 Prince Andrew Place, Don Mills, Ontario  M3C 2T8
%D   2006
%G   0-321-34996-2
%I   Addison-Wesley Publishing Co.
%O   U$49.99/C$69.99 416-447-5101 800-822-6339 bkexpress@aw.com
%O  http://www.amazon.com/exec/obidos/ASIN/0321349962/robsladesinterne
http://www.amazon.co.uk/exec/obidos/ASIN/0321349962/robsladesinte-21
%O   http://www.amazon.ca/exec/obidos/ASIN/0321349962/robsladesin03-20
%O   Audience a+ Tech 3 Writing 2 (see revfaq.htm for explanation)
%P   385 p.
%T   “Extrusion Detection:Security Monitoring for Internal Intrusions”

According to the preface, this book explains the use of extrusion detection (related to egress scanning), to detect intruders who are using client-side attacks to enter or work within your network.   The audience is intended to be architects, engineers, analysts, operators and managers with an intermediate to advanced knowledge of network security.  Background for readers should include knowledge of scripting, network attack tools and controls, basic system administration, TCP/IP, as well as management and policy.  (It should also be understood that those who will get the most out of the text should know not only the concepts of TCP/IP, but advanced level details of packet and log structures.)  Bejtlich notes that he is not explicitly addressing malware or phishing, and provides references for those areas.  (It appears that the work is not directed at information which might detect insider attacks.)

Part one is about detecting and controlling intrusions.  Chapter one reviews network security monitoring, with a basic introduction to security (brief but clear), and then gives an overview of monitoring and listing of some tools.  Defensible network architecture, in chapter two, provides lucid explanations of the basics, but the later sections delve deeply into packets, scripts and configurations.  Managers will understand the fundmental points being made, but pages of the material will be impenetrable unless you have serious hands-on experience with traffic analysis.  Extrusion detection itself is illustrated with intelligible concepts and examples (and a useful survey of the literature) in chapter three.   Chapter four examines both hardware and software instruments for viewing enterprise network traffic.  Useful but limited instances of layer three network access controls are reviewed in chapter five.

Part two addresses network security operations.  Chapter six delves into traffic threat assessment, and, oddly, at this point explains the details of logs, packets, and sessions clearly and in more detail.   A decent outline of the advance planning and basic concepts necessary for network incident response is detailed in chapter seven (although the material is generic and has limited relation to the rest of the content of the book).  Network forensics gets an excellent overview in chapter eight: not just technical points, but stressing the importance of documentation and transparent procedures.

Part three turns to internal intrusions.  Chapter nine is a case study of a traffic threat assessment.  It is, somewhat of necessity, dependent upon detailed examination of logs, but the material demands an advanced background in packet analysis.  The (somewhat outdated) use of IRC channels in botnet command and control is reviewed in chapter ten.

Bejtlich’s prose is clear, informative, and even has touches of humour.  The content is well-organized.  (There is a tendency to use idiosyncratic acronyms, sometimes before they’ve been expanded or defined.)  This work is demanding, particularly for those still at the intermediate level, but does examine an area of security which does not get sufficient attention.

copyright, Robert M. Slade   2010     BKEXTDET.RVW   20101023

CAPTCHA bypassing for profit

Did you wonder what this is used for? The following FAQ may give a hint:

Hi! I want to bypass captcha from my bots. Bots have different IPs. Is it possible to use your service from many IPs?

We have no restrictions about IP: with DeCaptcher you can bypass CAPTCHA from as many IPs as you need.

In other words: Just used a Virus to break into thousands of botnet computers and now you are not sure what to do? These guys will help you take the next step and set up myspace/facebook/gmail/twitter accounts while bypassing the CAPTCHA and you can then use that to spam the world. Thank you DeCaptcher for giving the Internet such a valuable service.

Heathrow calling

Here’s a weird spam I got last night:

Hello

The route taken through Customs is mainly determined by your point of departure and whether you are bringing into the country more duty payable goods than your free allowance. For those passengers who have flown in from outside the European Community (EC), their baggage will have a white tag and they must pass through either the Red or Green channel according to the amount of duty free goods they have. Those passengers arriving from countries within the EC should use the Blue channel, and their baggage will have green-edged tag.

As part of our routine check and based on the above, we have a consignment in your name; you are advised to come to the office address below

Customs office
Terminal 3
Heathrow Airport

You are required to come with the following:
1. Your ID
2. Diplomatic Tag either white or green-edge tag.
3. Non Inspection document

Your appointment time is 10am GMT, failure to comply; we will have over the matter to Metropolitan and the FBI. I am the officer in charge of your matter.

Thomas Smith
UK Customs
Heathrow Airport

It’s weird, because it contains no advertisement, and no links. There’s nothing “encoded” in it –  it seems to be an old version of this notice.

So why would a spammer waste valuable botnet cycles on sending me the email? The only explanation I could come up with is “a boy who cried wolf” attack. You send this email a few times, and the Baysian filtering systems train themselves that this is a good email (i.e. “ham”). Most Baysian spam filtering systems have a loopback mechanism where spam email is used to train the system further, and ham email is used to teach the system what “good” email is. If this email is seen a few times and considered ham, spam filters will accept something similar to it that contains a link. That link, can be the spam or phishing attack.

Another guess is that it’s simply used to verify email addresses – you read that a scary Customs agent from Heathrow wants you in his office first thing tomorrow morning, and you quickly reply to ask what it’s about; the spammer (whose reply-to address is different than the “From”) gets a confirmation that your email address is valid, maybe with some more details like your phone number. This is a plausible explanation but it seems like too much hard work just to get some valid email addresses.
Any other guesses?