Comment On Curiosity, Ignorance, Malice

Jim B. stared wistfully in the mirror at the wrinkles near his eyes and the few stray gray hairs that he’d accumulated over the last six months. On the way back to his desk, he stopped by his friend Mike's desk. “Point three six,” he said as he banged his head against Mike's cubicle wall. “Point three six.” [expand full text]
« PrevPage 1 | Page 2 | Page 3Next »

Re: Curiosity, Ignorance, Malice

2009-01-06 11:05 • by AMerrickanGirl
I hope to hear soon that the company's database was successfully hacked and that a few of those smug executives lost their jobs.

Re: Curiosity, Ignorance, Malice

2009-01-06 11:12 • by SarcasmFTW (unregistered)
237561 in reply to 237558
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.

Re: Curiosity, Ignorance, Malice

2009-01-06 11:25 • by my name is missing (unregistered)
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.

Re: Curiosity, Ignorance, Malice

2009-01-06 11:27 • by Ahruman (unregistered)
TRWTF is the random chunk of CSS attached to the word “colossal”.

Re: Curiosity, Ignorance, Malice

2009-01-06 11:29 • by mo (unregistered)
I just don't want to believe this story...

(But I do anyway)

Re: Curiosity, Ignorance, Malice

2009-01-06 11:31 • by lyml (unregistered)
the real WTF is the american date system, two point seventyfive should have been what he said

CAPTCHA: tristique

Re: Curiosity, Ignorance, Malice

2009-01-06 11:34 • by snoofle
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.

Re: Curiosity, Ignorance, Malice

2009-01-06 11:34 • by Adriano
"Joe briefly wondered if he looked half ..."
Who's Joe?

Re: Curiosity, Ignorance, Malice

2009-01-06 11:36 • by Sean (unregistered)
237571 in reply to 237567
lyml:
the real WTF is the american date system, two point seventyfive should have been what he said

CAPTCHA: tristique


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.

Re: Curiosity, Ignorance, Malice

2009-01-06 11:42 • by Zecc
Good story. And good writing.

Re: Curiosity, Ignorance, Malice

2009-01-06 11:45 • by JC (unregistered)
Someone has multiple personality disorder, Spot the Jim turning to Joe then back to Jim mid-story.

Re: Curiosity, Ignorance, Malice

2009-01-06 11:45 • by kastein
237574 in reply to 237566
mo:
I just don't want to believe this story...

(But I do anyway)


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.

Re: Curiosity, Ignorance, Malice

2009-01-06 11:48 • by Kanazuchi (unregistered)
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....

Re: Curiosity, Ignorance, Malice

2009-01-06 11:55 • by Michael (unregistered)
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.

Re: Curiosity, Ignorance, Malice

2009-01-06 11:59 • by Marc B (unregistered)
"Their impregnable system had just been impregnated." Classic, I can't wait to use that line.

Re: Curiosity, Ignorance, Malice

2009-01-06 12:08 • by BobB
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...

Re: Curiosity, Ignorance, Malice

2009-01-06 12:16 • by danixdefcon5
237581 in reply to 237571
Sean:
lyml:
the real WTF is the american date system, two point seventyfive should have been what he said

CAPTCHA: tristique


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.
I say "January 5" in English as well, however I write 5/1 because I'm used to writing full dates, where 5/1/2009 makes sense, but 1/5/2009 doesn't.

Bleh, I now use the ISO standard anyway: 2009-01-05.

Re: Curiosity, Ignorance, Malice

2009-01-06 12:19 • by Certified Coward (unregistered)
237582 in reply to 237574
kastein:
(snip)
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.


I hope you verified his identity? He could as well be an social engineer...

Re: Curiosity, Ignorance, Malice

2009-01-06 12:30 • by Lev (unregistered)
He should've sold the secret to someone. Depending on his own malice, hackers or one of the clients.

Re: Curiosity, Ignorance, Malice

2009-01-06 12:31 • by Capt. Obvious
237584 in reply to 237581
damoxdefcon5:
I say "January 5" in English as well, however I write 5/1 because I'm used to writing full dates, where 5/1/2009 makes sense, but 1/5/2009 doesn't.

I say January 5th, 2009, so 1/5/2009 makes sense to me.

That said, for all filenames, I prefer YYYY-MM-DD. Screw the people in the year 10,000

Re: Curiosity, Ignorance, Malice

2009-01-06 12:32 • by darkwing (unregistered)
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...

Re: Curiosity, Ignorance, Malice

2009-01-06 12:36 • by Julius Caesar (unregistered)
237586 in reply to 237571
Sean:
lyml:
the real WTF is the american date system, two point seventyfive should have been what he said

CAPTCHA: tristique


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.
Exactly. Therefore TRWTF is to teach a children to say 8/22 in the first place.

Re: Curiosity, Ignorance, Malice

2009-01-06 12:39 • by Bombay Mix (unregistered)
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. :-(

Re: Curiosity, Ignorance, Malice

2009-01-06 12:40 • by Julius Caesar (unregistered)
237588 in reply to 237571
Sean:
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.
Uh, BTW do you realize that September 22nd is the same as 9/22?

Re: Curiosity, Ignorance, Malice

2009-01-06 12:41 • by Steve H (unregistered)
237590 in reply to 237576
Presumably it's Generic Government Agency, invented for the sake of the story

Re: Curiosity, Ignorance, Malice

2009-01-06 12:44 • by Kerio (unregistered)
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!)

Re: Curiosity, Ignorance, Malice

2009-01-06 12:46 • by zolf
Nice story! :D

Re: Curiosity, Ignorance, Malice

2009-01-06 12:47 • by rsynnott (unregistered)
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.

Re: Curiosity, Ignorance, Malice

2009-01-06 12:48 • by DaveE1
237596 in reply to 237565
Ahruman:
TRWTF is the random chunk of CSS attached to the word “colossal”.


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; ....

Re: Curiosity, Ignorance, Malice

2009-01-06 12:49 • by Kerio (unregistered)
237597 in reply to 237594
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?

Re: Curiosity, Ignorance, Malice

2009-01-06 12:51 • by Kerio (unregistered)
237598 in reply to 237594
rsynnott:
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.


sorry, i meant to quote this

Re: Curiosity, Ignorance, Malice

2009-01-06 12:52 • by wee
237599 in reply to 237594
rsynnott:
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.


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.

Re: Curiosity, Ignorance, Malice

2009-01-06 13:01 • by wee
237600 in reply to 237597
Kerio:
would the performance really decrease by storing a relational database on a truecrypt disk?


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.

Re: Curiosity, Ignorance, Malice

2009-01-06 13:10 • by darkmage0707077 (unregistered)
237601 in reply to 237576
Michael:
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.


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!

Re: Curiosity, Ignorance, Malice

2009-01-06 13:20 • by Satanicpuppy
237602 in reply to 237558
AMerrickanGirl:
I hope to hear soon that the company's database was successfully hacked and that a few of those smug executives lost their jobs.


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.

Re: Curiosity, Ignorance, Malice

2009-01-06 13:22 • by nobody (unregistered)
How about if they just add a password instead:

psql -d secret-database
password:

Re: Curiosity, Ignorance, Malice

2009-01-06 13:25 • by halcyon1234
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.



Re: Curiosity, Ignorance, Malice

2009-01-06 13:32 • by Satanicpuppy
237605 in reply to 237600
wee:
Kerio:
would the performance really decrease by storing a relational database on a truecrypt disk?


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.


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.

Re: Curiosity, Ignorance, Malice

2009-01-06 13:32 • by Chahk
This comment is protected form malice.

Re: Curiosity, Ignorance, Malice

2009-01-06 13:33 • by clickey McClicker (unregistered)
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.

Re: Curiosity, Ignorance, Malice

2009-01-06 13:34 • by CynicalTyler (unregistered)
237608 in reply to 237602
Satanicpuppy:
Basically, the only good way out is to quit, unless you're in a position to make an institutional change.

Agreed. I think there truly are "no win scenarios". This is our Kobayahi Maru. Sometimes a corporation gains so much momentum on the path to their own destruction that no single outside force (and only certain internal forces) can right its course. The best you can do is make sure you don't become the target of litigation, so again CYA.

Been there..

2009-01-06 13:42 • by You-do-not-want-to-know (unregistered)
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..

Re: Curiosity, Ignorance, Malice

2009-01-06 13:48 • by Satanicpuppy
237612 in reply to 237599
wee:
rsynnott:
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.


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.


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...

Re: Curiosity, Ignorance, Malice

2009-01-06 13:55 • by ricecake (unregistered)
237614 in reply to 237607
clickey McClicker:
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.

I don't see how "January 6, 2009" (or even "Jan 6, 2009") has any more potential for confusion than "6 Jan 2009", unless the other person doesn't speak English and doesn't know what "Jan" or "January" are.

Regardless, I also use ISO-8601 date format whenever I can.

Re: Curiosity, Ignorance, Malice

2009-01-06 14:04 • by I'm Lost (unregistered)
237618 in reply to 237588
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.

What security vunerablity?

2009-01-06 14:08 • by I don't see it.. (unregistered)
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.

Re: Curiosity, Ignorance, Malice

2009-01-06 14:09 • by SteveO (unregistered)
237621 in reply to 237579
BobB:
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...

<ROAROFLAUGHTER />

Re: Curiosity, Ignorance, Malice

2009-01-06 14:16 • by SteveO (unregistered)
237622 in reply to 237574
kastein:

<snip>
...whenever I found some script kiddie using an exploited .gov machine.

I just had an epiphany - since .gov machines are ultimately paid for by taxpayers, then taxpayers should have access to those machines. Thus, "lax security" is merely our government allowing us to use the hardware we actually own.

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".

Re: Curiosity, Ignorance, Malice

2009-01-06 14:16 • by DaveK
237623 in reply to 237571
Sean:
lyml:
the real WTF is the american date system, two point seventyfive should have been what he said

CAPTCHA: tristique


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.
What makes sense for speaking does not necessarily make sense for writing.
I doubt you ever pipe your speech through "sort", for example.
Mixed-endian notation may not be an inconvenience in some circumstances, but it is in others.

Re: What security vunerablity?

2009-01-06 14:24 • by Lev (unregistered)
237625 in reply to 237620
I don't see it..:
I'd lay Jim off. Exactly what sort of attacker is he trying to defend against?


Don't forget about modifying the cookie.
« PrevPage 1 | Page 2 | Page 3Next »

Add Comment