Sophos Cloud Optix
The IEEE, the world’s largest professional association for the advancement of technology, has joined the ranks of the enbreached, following an exposé by Denmark-based Romanian computer scientist Radu Dragusin.
Dragusin stumbled across publicly readable uploads on the IEEE’s FTP server. Bad enough on its own, but a veritable security disaster for the IEEE.
Seems the organisation was using its upload server as a drop location for log files from the websites ieee.org and spectrum.ieee.org (its online magazine).
According to Dragusin, the logs recorded the details of nearly 400,000,000 HTTP requests.
These 400 million log entries included about 400,000 login requests containing the usernames and plaintext passwords of nearly 100,000 unique users.
Unfortunately, the log files were world readable.
When running an upload server, here are some things to consider:
- A world writable upload directory is OK. But make sure it isn’t world readable too.
- Don’t add passwords to your logfile. They’re supposed to be a shared secret between the user and your authentication backend, so they don’t belong anywhere else.
- Consider getting rid of FTP altogether. The uploads can be sniffed. Look at SFTP (or just scp) instead.
As Chester and I argued in Chet Chat 98, “If something is worth encrypting, it’s worth encrypting properly.” And if it’s worth encrypting, it’s worth encrypting all the time.
It’s not just worthwhile to encrypt Personally Identifiable Information (PII). It’s your moral (and in an increasing number of jurisdictions, your legal) duty.
As for Dragusin: by his own account, he got caught up in an agony of indecision.
Dragusin acquired the IEEE’s log data on 18 September 2012. “For a few days,” he writes, “I was uncertain what to do with the information and the data. On September 24, I let them know, and they fixed (at least partially) the problem.”
But his uncertainty didn’t prevent him rushing to register his vanity name-and-shame domain, ieeelog.com, on 19 September 2012.
(OK, maybe it was someone else – the registration record is behind the WhoisGuard shield of proxy registrant Namecheap.com, operating out of a serviced “suite” in Los Angeles.)
Nor did it prevent him grabbing and processing 100GB of log data he knew wasn’t supposed to be accessible. Nor preparing from it a raft of colourful maps and charts showing victim counts (and only counts, I must point out) by city worldwide, by email provider, by web browser, and by password.
How is this bad?
It probably isn’t. But it’s more of a “don’t be evil” outlook than one of “actually be good”.
As Dragusin points out, the log data had been publicly available – whether anyone had accessed it or not – for at least a month. On 24 September 2012, he finally informed the IEEE, who closed the hole, By 25 September 2012, IEEE had performed a password reset and notified affected users.
Perhaps another week didn’t matter?
We shall probably never know, but if Dragusin had told the IEEE at once, those dates could have been 19 September and 20 September.
Perhaps another week did matter?
Of course, that would have probably robbed Dragusin of any novelty in his funky charts, and of his moment of fame. And, as a respected triumvirate of security researchers – Charlie Miller, Alex Sotirov, and Dino Dai Zovi – insisted back in 2009, “No more free bugs.”
It’s worth pondering. “Would we all have been better served if Dragusin had told IEEE on the day he found the treasure trove?”
I don’t have the answer – but if you think you do, please leave a comment below!
Oh, while we’re on funky charts: here’s something to look out for when you’re processing IP geolocation records.
See those 302 IEEE members who live in the Atlantic Ocean?
It’s not a cluster of engineers from one of the offshore parts of Guinea Ecuatorial, nor from São Tomé e Príncipe.
It’s where the Greenwich meridian crosses the Equator. Zero degrees East, Zero degrees South.
Simply put, unless the delegates at a scientific conference on board a conveniently-placed Atlantic cruise ship were geekily showing off (at satellite data rates), it’s dud data.
–
I really didn't get what your conclusion is?
Please decrease the bla-bla stuff, you are not writing a novel. 🙂
I hear you. I've reworked the article a bit. I hope that helps.
I've put my advice about upload servers into a more obvious bulleted list. I've turned my not-really-a-conclusion implicit question (about the overall ethics of Dragusin's delay in telling IEEE) into an explicit one. And I've relegated some of the bla-bla stuff – the bit about "watch out for lat-long=0,0 in geolocation data" at the end – into a sort-of detached postscript.
(As for "writing a novel" – I know SMS and Twitter have trned brvty into art 4m, but 600 words a _novel_? I don't know whether to be flattered or perturbed.)
you said "A world writable upload server? Maybe. But never world readable." i assume you made a typo; if the files are writeable they are readable too.
Not for an FTP server – write permissions are set independently to read permissions.
By "world writable upload server", I mean that anyone can upload files to it. (Maybe they need to sign up for an account; maybe not. But my idea here is that it's some kind of public facing service.)
Thereafter, there are three main possibilities, two of which are responsible configurations, as far as I can see, and the last of which is an accident waiting to happen:
1. No-one can download anything. Not even files they uploaded themselves. (They've already got a copy, after all. So if you're running some kind of file submission system such as a print shop, not an archival service such as a cloud backup, this makes perfect sense.)
2. You can download files, but only if you originally uploaded them.
3. Anyone can download anything. (World-readable. A big security risk, but ideal if you're running an anonymous file sharing site and unregulated exchange is your goal.)
Sophos's own web server, for example, offers a malware sample submission form which operates in mode 1 above. It's world writable but *not* world readable. Anyone can upload files, which are then sent to SophosLabs. But there's no download function at all. We don't offer to keep your malware online so you can retrieve it later if you lose the originals 🙂
I don't know what OS you're using but read and write are separate attributes on the many I'm familiar with and the two I know intimately
Paul, like I said in a tweet directed to you, IP geolocation is unreliable. For example, on the USA map, Wichita appears with a big red circle. This is because the IP is geolocated in USA, but without city or state information, so it is put in center of the country.
Also, googling around I found [redacted] a listing of log files from more than one year ago, suggesting things might be even worse. [URI redacted]
Great article!
Radu Dragusin
Thanks.
The IP geolocation bla-bla was just a bit of fun. I've run across it myself constructing spam source and dodgy website maps. You're always likely to end up with a most unlikely bright spot a few hundred nautical miles off the coast of Ghana. That's not "unreliable", it's simply wrong – a missing data point that ended up as "zero,zero" – a valid if unlikely reading – rather than "unknown".
People – you, me, loads of others – love to make geolocation maps at excruciating levels of detail, because they look really cool. Why put me on a world map "in greater Sydney" when you can put me at One Elizabeth Plaza, North Sydney – and adapt my pixel location to reflect that I'm on the 11th floor, in the North Eastern corner, currently sitting rather than standing?
Yet we know that our data is unreliable – sufficiently bogus, in some cases, to put New Yorkers in Wichita and people from who-knows-where in the middle of the Atlantic ocean.
It's one of the things that I dislike about geoIP data. It's mostly accurate enough to be a privacy and surveillance nightmare, but it's also inaccurate enough to lead to egregious mistakes. And on that cheery note, I bid you farewell 🙂
Never mind the 302 in the sea. How about the 221 in Nigeria !
Is that weird? Nigeria is the most populous country in Africa, has a big oil (sci/tech) industry, and is Anglophone.
Now, if the number in Nigeria had been 419, *that* would have been weird.
I love your geeky humor and informative writing style. Things are never static in your world!
Sadly, as an IEEE member for decades, this doesn't surprise me. IEEE is an academic organization, with impeccable credentials for reliable journals and conferences, managed, edited, and refereed by volunteers with the highest credentials.
But the websites have always been a disaster. I have always dreaded the occasions when I've had to search their website for an article or specification. A search engine which failed to return results for detailed queries forcing the user to make an overly broad query and page through page after page of results delivered 10-at-a-time. Opaque logon and account screens. Slow, plodding servers serving huge, ponderopus web pages. These are just the beginning.
I've never understood why IEEE didn't find some really good web academics and form a committee to adress their own website.
I've hit across publicly available sensitive information in the past – What I did was to inform the company pretty much immediately, wait until it's all sorted out, and only then write about it – http://blog.irrelevant.com/2011/07/data-breach.ht… – I got a thank you off them, and hopefully they'll be a bit more careful with out data in future!
While both numbers are beyond the "one, two, and many" concepts, there should be some editorial consistency between numbers with a difference on the order of 10 to the third.
"According to Dragusin, the logs recorded the details of nearly 400,000,000 HTTP requests.
These 400,000 log entries included the usernames and plaintext passwords of nearly 100,000 unique users."
Which was it? Hundreds of millions (400,000,000)? or Hundreds of thousands(400,000)?
Or was there perhaps 1000 HTTP requests per log entry? If so, that was not clearly explained.
Of course, the main point is that the usernames and passwords were in plain text.
Oops. Thanks for spotting – I have updated the article.
There were 400,000,000 HTTP log entries, of which 400,000 were login requests, with each user appearing on average 4 times over the period for a total exposure of 100,000 users.
In other words, over the period, you might assume roughly:
* 100,000 users logged in
* 4 times each
* And accounted for 1000 HTTP requests per login session (HTML, CSS, images etc.)
Sounds about right.