(In)Security at DHS

So I've taken an interest in social media recently.  To that end, I am very interested in the recently released list of keywords that DHS looks for when monitoring the Internet for terrorist and other "National Security" events.  I downloaded the Analyst Desktop Binder (redacted) and started reading through it. In addition to search terms, I'm always interested in what information can be pulled out of these sorts of things.

Single sign on (but not the way we like):
DHS uses a single sign on for its people to access one of their systems.  Now this appears to be a video system that does something with DirectTV, but still... really?  Oh, by the way, it uses HTTP instead of HTTPS.  Of course, I can't pick on HTTP vs. HTTPS when they use a single shared account.

Training DHS users to accept untrusted SSL certificates:
There's a reason for CA chains.  I've heard it has something to do with certificate trust.  The US Government has been horrible about this through the years. When I was in the Army, I always had to ignore certificate errors to get any work done.  Apparently the trend continues at DHS.  Basically, if you want to use the system, you should accept the invalid certificate for all sessions.  Man in the middle attack anyone?  Seriously, this is just bad systems administration.  Distribute the trusted root cert to all of your clients so they trust this cert and won't be vulnerable to MITM attacks.  Better yet, understand that you are TRAINING YOUR USERS to be vulnerable to future MITM attacks.

Save your password anyone?
So, as a penetration tester, I can't tell you how discouraging it is when someone forgets to save their passwords.  I mean, I have to actually work to pivot throughout the network.  Pen testers: never fear.  DHS's custom applications offer the option to save the user's password.

Now in all fairness to DHS, their manual does inform users that saving the password is a bad idea since it poses a potential security risk.  I have two questions then:

1. Why is the option still there when they know it's a security risk.
2. Why restrict the warning to the manual when you could also put it on the GUI?

Of course, the sane thing to do would be to enable PKI logins or some such that didn't require a password at all, but in lieu of that, don't let users save the passwords.  Crappy idea all the way around.

In case you were curious how this situation could get any dumber, take a look at the other highlighted text.  You can assign a profile, something like "Mobile".  Whoa.  WTF?  There's a custom DHS application that serves some sort of sensitive information (sensitive enough to require a login) and you're using it on a mobile device?  Oh, and by the way it saves your passwords too.  Awesome.  I'm sure the security wizards at DHS have ensured full disk encryption on those mobile devices though so there's nothing to worry about.

Parting thoughts:
If you work for a government agency, don't forget that anything you write down is subject to a FOIA request (that's how this was released).  The government can't hold back stuff that makes you look dumb, just stuff that compromises national security.  Remember: if you'd rather the public (me) didn't blog about your bad procedures, don't write them down.  Or better yet, get some better procedures... for all of us.

Jake Williams
@MalwareJake
Join me at the SANS DFIR Summit July 9-10 in Austin, TX.
Awesome speakers, great community, and DFIR NetWars!
Use promo code CSRgroup10 for 10% off your registration.