ThreatSTOP CEO Tom Byrnes to Speak at 2 Events in Washington, D.C.

ThreatSTOP CEO Tom Byrnes has been invited to speak at two events in D.C.

The first will be at ISOI9 on either May 12 or 13th (TBD).  He will speak about CAPS, anonymized log sharing, and ThreatSTOP’s “Channel 42” on SIE. The CYBER-TA Anonymous Alert Publication System (aka CAPS), originally developed by SRI, has all the features required for log anonymization but has not been maintained for some years. ThreatSTOP has reached agreement with SRI to take over maintenance of the code. See our blog about this. This enables sharing of information among users, which leads to a virtuous cycle as each user becomes a detector, and is how we can move from the Wild West of the current Internet to a civilized society, without requiring centralized control or walled gardens. ThreatSTOP is a member of the Security Information Exchange (SIE) run by the Internet Systems Consortium (ISC). Through channel 42, ThreatSTOP will provide other SIE members with data from our subscribers once it has been passed through CAPS to ensure anonymity.

The second will be at Cybersecurity Strategies Summit. This is an event sponsored by Securing our eCity, a private/public partnership dedicated to the mission of helping businesses, governments and individuals learn best practices of cybersecurity and protect themselves against cybercrime.  On May 11,Tom will give a  tutorial on how small and medium enterprises need to put the policies, procedures and systems in place to protect themselves against the various threats they face.

If you are in the area, drop by and say hello, meet people and exchange ideas.   More info here.

Russian Business Network Penguins

As those who visit our home page may have noticed we have a section where we note the countries with the worst IP reputation. We divide it up between big countries and small ones and determine the relative badness by calculating the proportion of the country’s reported IP addresses that are bad.

Ukraine has been consistently the number one large country ever since we started analyzing it with about 5% or 1 in 20 ip addresses bad.  However the number one small country tends to vary considerably – we’ve had Haiti, at least one of the pacific island nations and just recently we’ve got the almost totally unpopulated continent of Antarctica.

Naughty Penguins

Naughty Penguins

This caused a certain amount of amusement inside and outside the company (thanks Paul C for the image) and I thought it might be interesting to find out what exactly the Penguins have been doing and how much.

Well it turns out to be fairly straight forward (although there is a slight bug in our calculation scheme as I had not anticipated country ip blocks of less than a /24). According to our Maxmind GeoIP database there are 4857 ip addresses in Antarctica in various dribs and drabs of mostly AS34109 but also a couple of other ASes. Unfortunately AS34109 appears to be heavily infested with the Russian Business Network and four /24s that happen to include the Antarctic addresses plus two other unique IP addresses that Maxmind puts in Antactica are a part of the RBN. 1026/4857 gets you 21% which is indeed by far the highest ratio of bad ip addresses to total ip addresses in our list.

So are the penguins really a part of the RBN? Almost certainly not. Neither are the penguin researchers or any of the other inhabitants of Antactica. Almost certainly the addresses inside AS34109 that used to be used for Antarctic research stations have now been reassigned to something else (AS34109 is the Dutch ISP CB3ROB, which appears to have nothing to do with Antarctica).

For those that may be interested, the 4 ‘Antarctic’ /24s that are in the RBN are 84.22.98.0/24, 84.22.112.0/24, 84.22.122.0/24, 84.22.125.0/24 and the two Individual nodes are 84.22.106.30 and 84.22.106.50.

Come Hear Johannes Ullrich of SANS Institute Talk

Johannes Ullrich, Dean of Faculty and Chief Research Officer at SANS Institute and founder of DShield (full disclosure: also advisor to ThreatSTOP), will give a talk on the ever-changing threat landscape and how to detect existing breaches, protect against botnets and advanced persistent threats, and safeguard your data.  It will be at a lunch and learn event jointly sponsored by ThreatSTOP and the Orange County IT Executive Round Table on April 26, at Newport Beach, CA.  Registration is FREE for qualified IT security professionals.  Come enjoy great food, learn something and connect with your peers.  For more info, go here.

Latest Adobe Zeroday – “Call Home” Blocked by ThreatSTOP

Adobe have just announced yet another Zeroday Flash etc. exploit that has been seen in the wild in emailed Microsoft Word documents. The document installs the usual sort of backdoor trojan.

According to Mila Parkour, who reported it to Adobe, something, presumably the backdoor, then attempts to call back to a dyn-dns name (liciayee.dyndns-free.com). That name used to point to 123.123.123.123 (it now seems to be pointing to local host in most public DNS systems) which is an interesting IP address. As we have said many times before, bad IP addresses are often reused and this one is no exception. When I plugged it into our IP reputation database it showed up the following (as well as the information that the IP address is in China):

First Identified Most Recently active Present in the following feeds:
2008-01-30 00:00:52
2009-07-18 17:01:32
2010-12-06 10:00:03
2008-02-06 22:00:50
2009-09-16 17:30:04
2011-04-12 00:00:11
SSH_CRACKER
Parasites, Hijackers and Spyware Domains
Russian Business Network

We can learn two things from this. The first is that this address has a history of bad behavior (SSH cracker, spyware domain etc.) and the second (and possibly more critical one) is that it has been blocked by ThreatSTOP since December as it was identified then as part of the ‘Russian Business Network‘. That means any recipient of the email whose firewall was running ThreatSTOP was protected by this zeroday – and by any other exploit that happened to try and call back to this IP address.

Now it’s a good thing to run AV and update your Flash when a patch is released and so on, but none of these tools can protect against all zerodays – in fact by definition they won’t protect – so having an orthogonal protection mechanism is a good idea. IP reputation is precisely this orthogonal view of the problem and ThreatSTOP can get you protected in about an hour.

ThreatSTOP and IPv6

Since the Internet is nearly out of IPv4 addresses, people are finally getting serious about using IPv6. As people start deploying IPv6 we will find new bugs and loopholes that crooks can exploit. Holes like this one that mean that a bot on a network could act as the “man in the middle” for everyone else nearby.

The good news is that, assuming the bot uses the existing IPv4 infrastructure to contact its controllers, an IP reputation service such as ours will block it just as it will block any IPv4 “call home”.

But this is probably the limit for most current IP reputation services and is why there have been various claims that IPv6 kills IP reputation. Fortunately ThreatSTOP was designed to handle IPv6 so we are unaffected (indeed anyone who would like to be an IPv6 beta tester is welcome to contact us).

Let me illustrate two additional cases where ThreatSTOP’s patent pending mechanisms function in a mixed world. In the case where the enterprise as whole has moved to IPv6 and it is its upstream provider that does the IPv4-IPv6 mapping ThreatSTOP can still work as we can serve up our IPv4 blocklists in IPv6 formats quite easily. So long as we are told of the IPv4-IPv6 mapping used we can simply provide an IPv6 DNS response with the appropriate maps (similar to the way that the MITM attack linked to above works).

Secondly, as more and more of the Internet runs IPv6, we will start to see native IPv6 malware hosts. The reason why people say that IPv6 kills IP reputation is twofold, first, that endpoints are 128 bits long, and that is an unmanageable number to blacklist individually, and second that users get assigned address spaces that are larger than the entire current Internet. If you use IP reputation the way it’s done by DNSbls and others, this does, indeed, mean that the method is unlikely to work, because the number of potential /128 addresses an attacker can use is sufficiently large that they will always be able to find one that isn’t listed. However, due to the way V6 addresses are assigned, a single end-user is unlikely to have a full /128 address. More likely they will have a /64 (or perhaps a /56). Any of the unmasked addresses can change without effect on the IP route, and so, all you need to filter on is the network, instead of the host, address. The problem for current IP reputation services is that they have no concept of netmask in their query or response mechanism.

If an IP reputation service just did a straightforward change from IPv4 (A record) address to IPv6 (AAAA record) then they won’t provide useful blocking information. However ThreatSTOP is able to transmit both the address and mask – it is the same way that we do geo-blocking (blocking say the PRC or Ukraine) – so our subscribers are able to block all IPv6 addresses assigned to a particular host with a single record.

ThreatSTOP is looking forward to IPv6 – we see it as an opportunity, not a challenge – and we built our service to be ready for it from day 1.

The RSA spearphish attack and IP reputation

There is a very interesting blog post by Uri Rivner of RSA where he gives details of the recent attack on RSA’s SecureID system. Near the bottom of it he mentions that three domains were identified as being connected with the attack:

Good[DOT]mincesur[DOT]com | up82673[DOT]hopto[DOT]org | www[DOT]cz88[DOT]net

Since ThreatSTOP is an IP reputation system I naturally plugged the IP addresses that these domain names resolve to into our threat database.The first two came up blank (although the second one turns out to be hosted at amazon which is interesting) but the third one popped up as being a member of the “Russian Business Network” (it also turns out to be an IP address in China). Indeed it has been one for some time, having first popped up on that list in December last year.

Had RSA run ThreatSTOPon its firewalls and included the RBN feed then whatever part of the attack used this particular domain would have been blocked and logged. Had RSA decided to use ThreatSTOP as a feed for its SIM/SEM or similar then this IP address would have been flagged immediately. Either way the likelihood is that the attack would have been detected a lot sooner and probably far less damage would have been done.

It is also interesting to note that all three domain names have short lived TTLs (typical for domains using dynamic DNS services), however some additional research indicates that while the other two names have sometimes moved, this one has consistently resolved to the same IP address for some months. Hence I feel quite confident in my claim above that had RSA been a ThreatSTOP subscriber they would have detected this attack a lot sooner.

 

Blocking the LizaMoon ips

One thing we often note is that many bad IP addresses are recidivists. One day they are seen doing one bad thing, a week later they do something different. A good example are the various IP addresses implicated in the current LizaMoon SQL injection attack. Almost all the addresses were already known to us – in the ‘Russian Business Network’ feed at least – and some had quite a considerable history. Hence ThreatSTOP subscribers could have been protected against this attack, however not every ThreatSTOP subscriber will be using a block list with the RBN feed in it so we have also added the addresses to Emergency Feed which is downloaded by all our subscribers.

This SQL attack is also instructive for how the large number of domains reported by websense reduce to just a handful of IP addresses (in total just 6 with 2 more acting as final droppers after a redirect). This is typical in our experience and shows yet again why it is better to block IP addresses rather than domain names.

For those interested the 8 IP addresses are:

194.28.44.190, 91.220.35.151, 91.213.29.182, 95.64.9.18, 109.236.81.28 and 91.217.162.45 in the original attack plus the following two 46.252.130.200 and 84.123.115.228.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: