• OldCoder (unregistered) in reply to Julius Caesar
    Julius Caesar:
    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?
    Nah. His months start at zero.
  • 5|i(3_x (unregistered) in reply to Chahk
    Chahk:
    This comment is stupid.

    You can't protect form [sic] malice! Bwahahah!

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

    Um, yeah. That's what locks do. They secure doors.

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

    Fully Qualified Domain?

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

    Um, yeah. That's what locks do. They secure doors.

    It's a bad analogy, but he's basically right. If the attacker has command line access to the system sufficient to control the database, you're probably screwed.

    Encryption helps in the following circumstances:

    1. Your backup tapes get stolen.
    2. Your hard drive gets stolen.
    3. An attacker uses SQL injection to copy the database.

    It will not help if an attacker has control over your system. At that point they have access to whatever methods you're using to encrypt/decrypt your data, and you're basically screwed.

    A better analogy would be trying to lock a prisoner in a cell that can only be opened/closed from the inside.

  • JesFine (unregistered)

    9/25 = .36

    If he's not careful, he might accidentally stay an extra month.

  • 01001001011101000010011101110011001000000110110101100101 (unregistered)

    Reminds me of a recent issue I had with a vendor's web component. The component has an XSS bug, and I showed the vendor how with a little javascript tacked onto the end of a URL when the page returned the URL was included in the vendor's javascript, and thus the javascript in the URL would run. This way a hacker could get access to cookies or whatever..... The vendor's response was basically "well, you shouldn't put that javascript in the URL there"

    Yeah, I'll be sure to let our site's hackers know that....

    CAPTCHA: nisl (Soccer fans?)

  • Tom (unregistered)

    Best guess on FQD: Fully Qualified Designation? The full name of the organization to boot him if said hacker did manage to get in, perhaps.

  • (cs) in reply to lyml
    lyml:
    the real WTF is the american date system, two point seventyfive should have been what he said

    CAPTCHA: tristique

    Thanks for fulfilling my prediction that some boring twit would say that.

  • Blogger (unregistered) in reply to Julius Caesar
    Julius Caesar:
    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?

    Perhaps he's a Java Coder....

  • (cs) in reply to I'm Lost
    I'm Lost:
    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.

    LOL. You are even more boring. Do you have any jokes involving the number of rods per hogshead?

  • Me (unregistered) in reply to Steve H
    Steve H:
    Presumably it's Generic Government Agency, invented for the sake of the story

    Uh-oh....the GGA again.....

  • Intentionally Left Blank (unregistered) in reply to Satanicpuppy

    [What security vulnerability?]

    1. That he was able to gain root when he was a normal user of the system?
    2. That "...he was on a team building a security system that was responsible for keeping ne’er-do-wells out of data belonging to nine-figure financial companies and an array of three-letter government organisations..."
    3. That the 'vendor' was not following the government standards on security and Jim was? (See section 15.2.1.1 at: http://www.niap-ccevs.org/cc-scheme/cc_docs/CEMV3.1R2.pdf )
    4. There are systems/ways to guard against malice? (See the most secure commercially available OS: http://www.ghs.com/products/safety_critical/integrity-do-178b.html )
  • (cs)
    Their impregnable system had just been impregnated.
    Actually, that should read, "Their impregnable system had just been pregnated."

    My apologies if somebody's already said it. I didn't read all the comments before responding, thereby breaking my own rule.

  • Anonymous (unregistered) in reply to SteveO
    SteveO:
    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 />

    Perhaps their computers at the time had no usb ports. I doubt a usb stick is much use for transferring data when there's nowhere to stick it. (hmm maybe I should rephrase that)

  • Mr.'; Drop Database -- (unregistered) in reply to clickey McClicker
    clickey McClicker:
    Government (intersection) Contract = Lowest bidder
    intersection = ∩
  • nobodyfamous (unregistered)

    What company was this? This sounds like excellent whistle-blower material. Presumably since they're working with three-letter agencies, they're dealing with information about you and me and everyone you know. IMO, they should be outed.

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

    I did, in fact. I emailed him logs of script kiddies boasting about their owned hosts at a .gov email address and the host that was causing the trouble was shut down within half an hour. Also, I'm not exactly an easy take social engineering wise... and most idiots on IRC trying to social engineer people are easy to detect. Also, someone was already using the host to IRC from and packetflood people with (that time, it was a few hundred mbps coming from a fourth-level lanl.gov host), it's not like it could really make things any worse.

    Kerio:
    come on, give us a hostname or an ip address they deserve the shit they'll get
    ... I'm sorry, are you retarded? Why did you even ask?

    also, for those asking what FQD means - FQDN means fully qualified domain name, so it's not that most likely, and based on the tone of the article, the acronym was made up on the spot to poke fun at the governmental way of doing things. I swear, some people wouldn't know deadpan humor, or for that matter even sarcasm and satire if they were hit in the face with it :D

  • Michael (unregistered) in reply to kastein
    kastein:
    also, for those asking what FQD means - FQDN means fully qualified domain name, so it's not that most likely, and based on the tone of the article, the acronym was made up on the spot to poke fun at the governmental way of doing things. I swear, some people wouldn't know deadpan humor, or for that matter even sarcasm and satire if they were hit in the face with it :D

    Thanks - it hits me now ;)

    I was convinced there was a deeper meaning in this acronym so I went on search to understand what I'm laughing on, but it seems that wasn't necessary ;)

  • (cs)

    Oddly enough (or maybe not), one of the news headlines today is this: Data Breaches Booming.

  • HonoredMule (unregistered)

    Please, please tell me that this company has been charged and convicted of criminal negligence and has closed its doors.

  • (cs) 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? 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.

    Bearing in mind that this started with an exploit to get root, he's probably not guarding against internal sysadmins.

    Also the impression I get from "they'd just have to" is that they wouldn't even need to get root to access the database. If that doesn't strike you as a WTF then please never work at the same company as me.

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

    Let me try to detail why database encryption is important. First, though, we need to define what it is. You do not place the DB on an encrypted volume, and you do not encrypt the DB files themselves. You encrypt specific fields in DB, say Social Security or Credit Card numbers. If, for some reason, you need to index on these values, then it becomes significantly more complicated, but that's largely irrelevant to this discussion.

    The short of it is that yes, you do incur a performance hit, but the DB server itself doesn't need to be responsible for the en/decryption - this can be done elsewhere, such that, if it makes sense for the data, different fields can be encrypted with different keys. That's probably not likely in this scenario, but the important part is that the decryption keys can be stored anywhere - including in encrypted form that the system admin does not have the password to. So yes, you can encrypt the database and foil a user that has gained root access.

    So there is one reason - you CAN foil a hacker that has gained root privileges. Another is for the same reason that you encrypt off-site backups. In a SAN or RAID system, you lose drives all the time. In most cases, the bad drives are shipped off-site to a third party company that has provided you with your replacement disk under contract. Though the entire database is not represented on a single drive from a RAID array, complete records most likely will exist. Should a malicious user intercept that disk, or should it be refurbished and placed back into distribution, your data is placed at unnecessary risk. For most businesses, this risk is vanishingly small, but for government agencies and financial institutions the risk can be unacceptable. To be sure, many agencies will destroy the disk rather than ship it off-site, but it is likely cheaper to implement encryption than it is to absorb the cost of failed disks in a data center.

    Additionally, it protects against physical theft, which bypasses the need for root access. The government may place systems housing secure data at remote locations - embassies or military bases - that do not enjoy either the level of physical security or reduced threat of physical theft domestic systems do. It is unlikely that the most sensitive data would be placed at these locations, but there would likely be a need for some sensitive data to be available.

    Lastly, if the database is encrypted, it helps protect against SQL injection type attacks. If someone manages to (via an exploited cookie as mentioned in the article, for example) inject a "SELECT * FROM TableName" query, they get only a minimal amount of usable data. The most important bits come back garbled.

    Now, all of this assumes that the application is designed correctly. If they do simply encrypt all of the fields with the same password, and the password is stored in an init script (as opposed to a valid user login) or worse, unencrypted in the database itself, then most of these benefits are lost. So I re-iterate: if done correctly, encrypting the database provides significant security benefits.

    And you are correct - defending against the sysadmin is probably silly - even if the keys to the database are protected from him, as you show there are other ways of obtaining them if you have the access and trust typically placed in the sysadmin, but the primary goal of database encryption does not include protection from the sysadmin, though making him work for access - thus preventing "casual" browsing of it - is a handy side benefit.

  • Essayist (unregistered) in reply to Ifni

    It doesn't take long for the soliloquies to start.....

  • (cs)
  • (cs)

    That ".36" nonsense managed to turn a neat little WTF into nothing but an incredibly lame joke with an excruciatingly long setup.

  • Peter (unregistered)

    The obvious solution is to just sell this information to competitors/foreign countries/whatever when he leaves.

  • anon (unregistered)

    If I worked there I'd be a little stressed about the lack of rigour from my colleagues. But seeing as though I nor any one of us work there, I fail to see why anyone gives a wtf about it. Why get so angry when it has absolutely no effect on your life whatsoever?

  • Vlad (unregistered)

    Right... after a project lead suggested to use a third-party script, deployed on a third-party server, in our internal financial web page, I kind of suggested not to, and spent 3 days adopting it (it's opensource); for which I was rewarded by "performance improvement plan" ("what could have been done in 30 minutes, took him 3 days"); ok, I talked to our network security people... I really thought they were interested in preventing this kind of solutions... they were not.

  • blunder (unregistered) in reply to Code Dependent
    Code Dependent:
    Their impregnable system had just been impregnated.
    Actually, that should read, "Their impregnable system had just been pregnated."

    My apologies if somebody's already said it. I didn't read all the comments before responding, thereby breaking my own rule.

    What to some is a funny joke, to others makes a whooshing sound.

    • Confucius
  • Vlad (unregistered) in reply to Kerio

    Try 127.0.0.1

  • rgz (unregistered) in reply to operagost

    Ironically, I predicted one childish anglophone would knee-jerk ad hominems at that comment. Though if you aren't a native anglophone my prediction is only 75% correct.

  • Edward Royce (unregistered)

    Hmmm.

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

    Hah!

    I got around that by having so much debt that anybody who stole my identity would -pay me- to take it back!

  • (cs)

    What would Kirk do?

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

    Hey, hey! Don't forget insurance companies.

    Actually, my group in my ins comp employer IS encrypting fields as noted...

    Only problems:

    -Server without https capability uses security-through-obscurity instead to protect confidential data (no interest in my idea of replacing fixed-key replacement algorithm with something key based like... AES)

    -most systems still have no encryption

    -Some of the encrypted fields' only values are 'Y' or 'N' (suggestion of using salt was dismissed)

    -Only 1 cobol module can see the key but all programs (& by extent programmers) can call that module.

    -No procedure exists to change keys if the "hidden" one is compromised. (Changing keys would make all existing encrypted data inaccessible)

    Clearly, the greatest risk is from programmers. Luckily, there is absolutely no chance of any programmer ever exploiting one of these bugs... despite the WTF-driven programmer turnover rate.

  • rycamor (unregistered)
    “But if they wanted to get to the database, they’d just have to do ‘psql –d xxxxxx-db-name’ and they’re in. Like I said, we can’t protect against malice!”

    Jim briefly wondered if he looked half as horrified as Mike did at that moment. “You… didn’t encrypt the database?!”

    I call BS:

    1. A security company smart enough to use PostgreSQL but too dumb to care about security even in the slightest. Fishy.

    2. WTF does encryption have to do with it? Rather it looks to me like someone used the default PostgreSQL authentication scheme, which allows local (from the unix shell) logins without password. I guess I can see that happening, even though the fix is one line in pg_hba.conf, but...

    3. Exactly WHAT is J. Random Web User doing in the Unix shell anyway? Until we get to the bottom of this, that is TRWTF.

  • Anonymous (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? I suspect what Paul meant (or actually said) was 'we cannot guard against malice by system administrators'.
    I fully agree. This is the only sensible comment in the whole thread, I think everyone else (including Jim) is missing the point of what the real engineers were saying.
  • Yanman.be (unregistered) 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.

    This is thedailywtf.com. If there were layoffs, it'd be Jim.

  • (cs) in reply to Anonymous
    Anonymous:
    I don't see it..:
    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'.
    I fully agree. This is the only sensible comment in the whole thread, I think everyone else (including Jim) is missing the point of what the real engineers were saying.
    Ah, but you can (well, partially). Partition the administration into two (or more) parts and use encryption suitably to make sure that admins of one part (like the database) can't get enough information to get anything confidential. Simple.

    Of course, that just means that there must be another part (perhaps the business logic engine) where the admins can get the info if they want. But the name of the game is really about reducing the exposure surface. (Of course, the sane approach involves vetting the admins and then not treating them like felons, but we know that many firms don't hold with this whole sanity business...)

  • jimicus (unregistered) in reply to rycamor
    rycamor:
    3. Exactly WHAT is J. Random Web User doing in the Unix shell anyway? Until we get to the bottom of this, that is TRWTF.

    Irrelevant - you don't need a Unix shell to do damage at root level, you just need some means of accessing data. In any case, the word "cookie" doesn't necessarily prove it's a web application.

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

    No, really - Month/Day/Year IS A WTF. Somehow I find Day/Month/Year to be better structured way of representing the date. Anyway, I realize that people who use Month/Day/Year are the same people who measure their height with "FEET".

  • James M (unregistered)

    Sadly HR kept the end date stored in a similar format, and stopped paying him on April 11th

  • grammernazee (unregistered) in reply to Zylon
    Zylon:
    That ".36" nonsense managed to turn a neat little WTF into nothing but an incredibly lame joke with an excruciatingly long setup.
    Agreed. Even a true geek wouldn't "store" a date as a decimal number. Apart from anything else, 0.36 could be 4/11 or 5/14 or 8/22 or 9/25 or 10/28 (and yes, I'm sad and not busy enough, and had time to work them all out!). Either he's a git, or this story is lame, or both. Oh and also, of course US date format is dumb; it's not "boring" to point that out - it's just one of the joys of not being 'merican, and not having to write things backwards. Mind you, the German language is equally daft "zwei-und-zwanzig", what's that all about?!
  • Uhh (unregistered) in reply to Anonymous

    I cannot agree. I mean, working in a bank, it would be a complete nonsense (and many techies would be sipping martinis in tropical islands instead of working) if sysadmins would have full ability to alter account information.

    Sysadmin job needs ability to run, maintain and configure the system, but for a secure sysem it should never mean ability to gain full access to the secure data stored on these systems, to get encryption keys of other users, to change anything without that change being logged securely; to do major alterations without four eye principle, etc.

    One random example of such measures - there are simple commercial offerings for high security systems to store sensitive data (say, encryption keys for debitcard PIN checking) where full root access (not needed for any regular tasks, but system setup or reconfiguration) works only together with two physical keycards that need to be inserted in the system - and which are not available to the sysadmins, but requires presence of two different trusted officers.

    If the idea of securing the company against any employee fraud seems nonsense, well, then your security is not serious. 99% of companies don't need serious security, of course, but here the whole point was that the customer presumably did actually need serious security.

  • imu (unregistered)

    94 comments and nobody's picked out the zinger.

    Mike was so nice to get Jim a beanbag, but he put it on his desk, when Jim likes to bang his head against the cubicle wall.

    He's worked for gov't too long - good idea, bad implementation.

  • (cs) in reply to blunder
    blunder:
    What to some is a funny joke, to others makes a whooshing sound.
    • Confucius
    ...obviously.
  • (cs) in reply to operagost
    operagost:
    I'm Lost:
    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.

    LOL. You are even more boring. Do you have any jokes involving the number of rods per hogshead?
    Two in each eyeball and one for his neck! B'dm-tssh!

    (Sorry I can't remember the start of the joke. Probably something to do with a rod being the same as a perch. I believe the Americans have a similar joke using poles <get garment="coat" />.)

  • Chelloveck (unregistered) in reply to danixdefcon5
    danixdefcon5:
    Bleh, I now use the ISO standard anyway: 2009-01-05.

    I do this too. Pisses my wife off; she prefers the American way because "that's how everyone does it". (We are in the United States, btw.)

    Maybe we need to start an "Americans for Sane Date Formats" advocacy group...

  • Ed (unregistered) in reply to slinger

    You only like Day/Mo/Year because you're used to it. Since it is backwards from the universal standard of most significant digits first, it is equally inferior to year/month/day as any other date format.

    BTW I see the flaming retards are still posting captchas in their comments. Next time call up your mom and tell her what your captcha was instead of wasting forum space with your inane irrelevancy.

  • clickey McClicker (unregistered) in reply to Mr.'; Drop Database --
    Mr.'; Drop Database --:
    clickey McClicker:
    Government (intersection) Contract = Lowest bidder
    intersection = ∩

    Yeah, um, I embarrasingly didn't know how get that character or I would have. Now I can copy "∩" from you post. Do you have the symbol for union too?

    That's what I get for using DOS, yea that's it, I'm using DOS, I can't be lame if i blame someone else :)

Leave a comment on “Curiosity, Ignorance, Malice”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article