• (cs)

    I hope to hear soon that the company's database was successfully hacked and that a few of those smug executives lost their jobs.

  • SarcasmFTW (unregistered) in reply to AMerrickanGirl

    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.

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

  • Ahruman (unregistered)

    TRWTF is the random chunk of CSS attached to the word “colossal”.

  • mo (unregistered)

    I just don't want to believe this story...

    (But I do anyway)

  • lyml (unregistered)

    the real WTF is the american date system, two point seventyfive should have been what he said

    CAPTCHA: tristique

  • (cs)

    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.

  • (cs)

    "Joe briefly wondered if he looked half ..." Who's Joe?

  • Sean (unregistered) in reply to lyml
    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.

  • (cs)

    Good story. And good writing.

  • JC (unregistered)

    Someone has multiple personality disorder, Spot the Jim turning to Joe then back to Jim mid-story.

  • (cs) in reply to mo
    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.

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

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

  • Marc B (unregistered)

    "Their impregnable system had just been impregnated." Classic, I can't wait to use that line.

  • (cs)

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

  • (cs) in reply to Sean
    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.

  • Certified Coward (unregistered) in reply to kastein
    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...

  • Lev (unregistered)

    He should've sold the secret to someone. Depending on his own malice, hackers or one of the clients.

  • (cs) in reply to danixdefcon5
    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

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

  • Julius Caesar (unregistered) in reply to Sean
    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.

  • 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. :-(

  • Julius Caesar (unregistered) in reply to Sean
    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?
  • Steve H (unregistered) in reply to Michael

    Presumably it's Generic Government Agency, invented for the sake of the story

  • 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!)

  • (cs)

    Nice story! :D

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

  • (cs) in reply to Ahruman
    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; ....

  • Kerio (unregistered) in reply to rsynnott

    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?

  • Kerio (unregistered) in reply to rsynnott
    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

  • (cs) in reply to rsynnott
    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.

  • (cs) in reply to Kerio
    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.

  • darkmage0707077 (unregistered) in reply to Michael
    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!

  • (cs) in reply to AMerrickanGirl
    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.

  • nobody (unregistered)

    How about if they just add a password instead:

    psql -d secret-database password:

  • (cs)

    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.

  • (cs) in reply to wee
    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.

  • (cs)

    This comment is protected form malice.

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

  • CynicalTyler (unregistered) in reply to Satanicpuppy
    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.
  • 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..

  • (cs) in reply to wee
    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...

  • ricecake (unregistered) in reply to clickey McClicker
    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.

  • I'm Lost (unregistered) in reply to Julius Caesar

    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.

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

  • SteveO (unregistered) in reply to BobB
    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 />
  • SteveO (unregistered) in reply to kastein
    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".

  • (cs) in reply to Sean
    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.

  • Lev (unregistered) in reply to I don't see it..
    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.

Leave a comment on “Curiosity, Ignorance, Malice”

Log In or post as a guest

Replying to comment #237597:

« Return to Article