- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
I hope to hear soon that the company's database was successfully hacked and that a few of those smug executives lost their jobs.
Admin
I think I worked with your software at my last job, working for one of those TLA government agencies.
I wish I could of taken some of the code away from that job, there was a lot of "inventive" coding.
Admin
Security by stupidity, sigh. I recently worked for a company which handled millions of health care claims, yet all of their database and server passwords were known by everyone in the company and never changed, and with no audit trail no less. When I complained the CTO said "we trust out employees". Lol.
Admin
TRWTF is the random chunk of CSS attached to the word “colossal”.
Admin
I just don't want to believe this story...
(But I do anyway)
Admin
the real WTF is the american date system, two point seventyfive should have been what he said
CAPTCHA: tristique
Admin
Between the banks, brokerages, credit card companies, military, government and companies like this, it's amazing that we all haven't been identity-thefted into oblivion.
Admin
"Joe briefly wondered if he looked half ..." Who's Joe?
Admin
I've been raised saying "January 3rd" or "September 22nd" all my life therefore it's natural to write 1/3 or 8/22. If I had been raised to say "the 3rd of January" or "the 22nd of September" then I'd probably write 3/1 and 22/8 as well.
Admin
Good story. And good writing.
Admin
Someone has multiple personality disorder, Spot the Jim turning to Joe then back to Jim mid-story.
Admin
you and me both... it's just plain depressing how bad most company's security is.
I always wondered how hackers were able to get into "secure government systems" until I worked on some of them at an internship and met NASA network security engineer on IRC (for what it's worth, he was one of the few clued people at his site and I heard all sorts of horror stories about his idiot co-workers). He ended up as my default point of contact to report to whenever I found some script kiddie using an exploited .gov machine.
Admin
It's like that time they told me that to get one from system to the next in our product, they'd be passing an unencrypted request string. When I found out that the passwords in the database weren't even encrypted, I asked them why that was. The project manager's response? "Why would we want to do that?"
Incidentally, yes, we are a government contractor....
Admin
By the way, what means FQD? I haven't ever heard this acronym. Google also isn't very useful and Faerie Queen Doll makes no sense.
Admin
"Their impregnable system had just been impregnated." Classic, I can't wait to use that line.
Admin
I remember one secure facility I had went to confiscated my CDs (audio) because they could transport data. Oddly enough the USB stick at the time sailed right through...
Admin
Bleh, I now use the ISO standard anyway: 2009-01-05.
Admin
I hope you verified his identity? He could as well be an social engineer...
Admin
He should've sold the secret to someone. Depending on his own malice, hackers or one of the clients.
Admin
That said, for all filenames, I prefer YYYY-MM-DD. Screw the people in the year 10,000
Admin
I wonder how much of the WTF is because the clients are small. By the "order of magnitude" metric, a nine-figure financial firm is relatively small, without a huge security budget. There are plenty of small gov't agencies of the same caliber.
Now, if we were talking about 12-, 13-figure companies, or more, that would be a different story...
Admin
Admin
Man that's depressing as hell.
Even more depressing is that things like this happen all the time at a certain market leading security multinational. It's not been unknown for management to dismiss root password changes (unchanged for years), as unimportant when senior sysadmins leave on bad terms. :-(
Admin
Admin
Presumably it's Generic Government Agency, invented for the sake of the story
Admin
come on, give us a hostname or an ip address they deserve the shit they'll get
captcha: uxor - not very related (ha, related as in a wife - i made funny joke!)
Admin
Nice story! :D
Admin
Hold on, an encrypted database? Certainly you want authentication, and login from controlled areas, but encrypted? Is this common? I can see it just about COULD be done (at least for data; NOT indexes), but it seems like a lot of overhead for dubious benefit.
Admin
I like the white on white h2 tags on the main page better. At least this is how it looks in firefox.
This might be the problem - .Home_ArticleSummaryContainer H2 { color: #FFFFFF; margin: 0px; font-weight: normal; ....
Admin
when you are a pow4h government agency, there's no limit to the security you can get
well, apparently there's no security, either :(
would the performance really decrease by storing a relational database on a truecrypt disk?
Admin
sorry, i meant to quote this
Admin
This got me thinking as well. In fact, I'm leaning toward calling BS on this story. Jim turns to Joe, who wants to show incredulity that an entire DB isn't encrypted? A security company that doesn't take security seriously?
I don't buy it.
Admin
I don't think he meant "store the actual tables on an encrypted volume". As far as performance, I don't think it'd to terrible. Not great. I think it'd be kinda dumb, though. I can't imagine clustering it, for one thing. Fault tolerance would be non-existent, for another.
The whole point of something like truecrypt is that it has to ask you to type in a passphrase when it starts; storing it in a file or whatever defeats the entire purpose of using it to begin with. So how would your DB come back up after a reboot? What happens if the truecrypt process exits abnormally? Where's your data at that point? Where's the stuff that was in the middle of being inserted? Can you even rollback a transaction when the entire DB is housed on an encrypted volume? What happens with a disk error?
I think he meant encrypting data within the DB itself. each column holds gibberish which is encoded/decoded as it's stored/accessed, that sort of thing. There'd be major overhead with something like that.
And don't assume that gov't agencies have powerful hardware. That's budget-driven, which means it's politically driven. And some places have hardware retention guidelines, so you can't just got replacing a rack of machines because your new, poorly-designed DB-backed system is running at glacial speeds.
Admin
Actually, considering how messed up this story is, it could be accurate: maybe they believe that MAGIC will protect them from the Big Bad Hackers!
Admin
Right. Because it'd be the executives, not the guys who were hired to secure it. And not the full timers, no. It would be the contract employees.
This from years of experience: COVER YOUR ASS when you find problems like that. Let the entire world know. You cannot raise a big enough stink, and you CANNOT let yourself be soothed by morons who don't care.
I got stuck in a similar situation once, and I raised enough hell that they basically banned me (I was a contractor) to this tiny niche system that was the sum total of my contracted responsibility. And when the fit hit the shan, my little system was the only one that didn't get compromised, and during the massive inquiry, I could pull out reams of documentation that I had not only brought the massive glaring flaw to the attention of everyone who was claiming they had no idea it existed, but that I'd been censured for it.
Never worked for that company again; they hired 6 guys to make changes to the system I'd built rather than bring me back in...Probably cost them 5 times as much, but I "told on" everyone, instead of sticking to the accepted story, so I was persona non grata.
Basically, the only good way out is to quit, unless you're in a position to make an institutional change.
Admin
How about if they just add a password instead:
psql -d secret-database password:
Admin
Seconded about encrypting the data in the database. Security through layers. If someone does "steal" the database, any sensitive information should be encrypted. Any data that will only be confirmed rather than used (such as a password) should be one-way hashed. With salt.
If I look at a db, I shouldn't see this: username password Alex JimIsJoe
I should see:
username password Alex $KKSJUhlkjjsd88&Shk12kjdF#
If overhead is a concern, the trick is to make sure you only encrypt the data that would actually make a difference if it got out. Names usually aren't all that sensitive (unless they're protecting something like a list of field operatives...). Social insurance numbers, health conditions, credit card information-- that stuff gets encrypted. Ideally, that data is also the least accessed data, so you don't have to "overhead" it too much.
Admin
It can be either way actually, though you'd be more likely to use an encrypted file system rather than a third party program like truecrypt. And there is a measurable performance hit regardless: the more data encrypted, the larger the hit.
For most systems it's enough to encrypt the data that would screw you if it got released: usually SSNs and CC numbers. That's a good mix of speed and security. You can also encrypt everything and put a low security "Snowflake" table out in the open, containing only unencrypted non-critical data. That'll give you speed for queries, and allow you to do index-specific queries on the encrypted database.
The best rule of thumb is to not store any sensitive data that you don't absolutely have to. I set up an ecommerce site for this company once, and it got exploited due to a bad password change, and some stupid restrictions being lifted (I'd set up the database to allow only local connections, and to use low privilege users for all reporting functions.) They opened up remote connection from ANYWHERE (gah!) and started using the admin user for everything.
So the database got ripped off, and they called me in a panic to figure out what to do. I said, "Tell 10,000 people that you lost the last 4 digits of their credit card number." I didn't even store it encrypted. If you don't keep it, it can't be stolen.
Admin
This comment is protected form malice.
Admin
If I remember correctly this is almost always true(barring politicing and kickbacks)
Government (intersection) Contract = Lowest bidder
The lowest bidder is often the lowestbidder for a reason. They suck and can't get work because of the magnitude of suck.
But remember: The goventment can tax their way out of any problem. So what is measly database security? Just a solution not supported by a tax opportunity, yet.
Also...I write dates 6 Jan 2009. No confusion or accidental "unit conversions." People ask if I'm in the military because they apparently use that format. I tell them no and it's nice to be paid well too.
Admin
Admin
I've been in a situation where a management decision was, umm, "interesting" in the light of what I found.
Imagine an electricity utility. They need an exact map DB of where cables lie in the ground. You zap that, the lights won't go dark immediately but will dim over a few months as they won't know what to fix where. Losing this data is thus not a NOW crisis but is a creeping disaster.
Imagine the map DB server and software management outsourced. Company enters the MAIN company network (yup, no segregation), gets into the production server and starts messing around with the map DB "cleaning up some duplicates". Yes, I said production. Such a thing as "test" wasn't provided, only a backup server whose backup functionality was a question as well as the system wasn't even half as resourced as production. Someone eventually decides that maybe direct access isn't a good idea, so bars access to that server from the firewall.
Couple of days later, a maintenance request gets fulfilled without any request for access. On query (WTF) it emerges they simply went to the backup system and hopped over (we're still not segregated here). No discussion, no talk, no request - they basically just hacked their way around an admittedly limited solution. Oh, need I mention these clowns had and insisted full root on the systems despite a clear absence of need for this?
This is where I got the job of having a look at the security of this whole mess.
Analysis of what the supplier does during access: mess around with the DB, generates heaps of duplicate records and then delete them. No version tracking, no revision docs (no idea what the next version does or fixes), no access controls or logs, and no indication that such access is at least done from a kosher network, by kosher people managing access credentials in a clean way. Oh, and no copy of their contract to be found anywhere! Eventually the segregation happened, and the job ended, but not before I found out why management had chosen this vendor.
They has chosen this company because they were also used to manage the maps for another company, ..
.. a nuclear reactor based power plant.
And no, I didn't make this up (I wish). It's been a while that my mouth dropped open by itself but this lot managed it. And I'm very glad I'm nowhere near that nuclear plant. And very glad that job has long been behind me, because we were not allowed to brief the nuclear plant on this due to customer confidentiality - which has kept me up for more nights than I care to remember..
Captcha "illum" - yeah, it was surely enlightening..
This is the primary disadvantage of security work - sometimes you find out things you really, really didn't want to know..
Admin
Buy it. Financial systems are old tech, usually. I imagine the bit that they left out was that the breach would have had to happen inside the local network, which of course is impossible because you'd have to breach the umpteen jillion dollars worth of company mandated cisco security appliances, which would never ever happen. Or, you know, an employee could do it (inconceivable!)
Behind that wall, you'll have some klunky systems that were put together 20 years ago, and have been piecemeal updated ever since. Little standardization, inadequate security, long term employees who haven't updated their skills since Carter was president...
Admin
Regardless, I also use ISO-8601 date format whenever I can.
Admin
Yeah, like the Fourth of July?
Anyway, when the Americans I work for make fun of the way the rest of the world writes the date, I ask them to write the date, which they do mm/dd/yy, than ask them to write it backwards, in which they do yy/mm/dd.
Admin
I'd lay Jim off. Exactly what sort of attacker is he trying to defend against? I suspect what Paul meant (or actually said) was 'we cannot guard against malice by system administrators'.
Encrypting the database would probably quarter performance for no gain. If they've already got shell access, there's no reason they cannot look at the initialisation scripts to find the decryption key rendering it moot anyway.
If they can modify files on the database server they have full access. You cannot guard against a malicious admin - don't even try, you'll only annoy them. They are responsible for the data, not you.
For all you know, a rogue admin has made a SAN snapshot and done any and all kinds of brute force attacks in an isolated virtual machine - and there's nothing you can do to detect this.
Long story short: I'm not seeing the 'security vunerability' that Jim thinks he found. It's like complaining that if a home owner removes the lock to his front door, the door is no longer secure.
(And an encrypted file system? There's a good chance that an attacker would still see the data via the mounted encypted volume - so they wouldn't even have to decrypt it! And obivously encryption doesn't protect against SQL injection.)
If an admin really went malicous, they'd just stick a key logger on everyone's machines rather than bothering with this, anyway.
Admin
Admin
Now if the script kiddie lives in Norway, then THAT'S a problem. We can solve this by putting a post-it note on each box saying "Please do not hack if not a U.S. citizen".
Admin
Admin
Don't forget about modifying the cookie.