Officer Brings Security Flaw To Army's Attention; Army Threatens Him With Jail If He Talks About It
from the good-deeds-won't-go-unpunished,-not-in-this-man's-Army! dept
It's a common, but regrettable, reaction. Person A discovers flaw in computer security. This is brought to the attention of Persons B-whatever. Person A is threatened, bullied, fined, expelled, etc. for daring to highlight a potentially damaging security issue. In extreme cases, some even throw the highly-flawed CFAA at the person, accusing them of hacking, "exceeding authorized access."
Why? Who knows? Apparently nothing fixes a security flaw faster than acts of intimidation and the resultant bad press. The US Army presumably holds the power to actually shoot the messenger, but thankfully, it didn't take things that far.
A soldier was made to sign a non-disclosure agreement by the US Army after pointing out a security flaw which allowed accounts on shared PCs to be accessed without proper authentication…While I can almost see the rationale for this action (don't talk about this until we can fix it), it's severely undercut by the fact that the US Army a) had no intention of fixing it and b) had previous knowledge of the flaw's existence.
Army staff authenticate on shared computers on bases and in the field using Common Access Code (CAC) smart ID cards. On completing a session the card is removed from the reader and the session should be terminated. However, it appears that the logoff process is often slow and can easily be cancelled by the next user, who can then continue to access the system under the previous user's account.
The issue has been known about for over two years, with one Army lieutenant who spotted it facing all manner of troubles when he tried to report it to senior staff. Having been told that the problem was too tricky to fix, he was then allegedly made to sign a non-disclosure agreement and told he could face imprisonment if he broke it.I guess the Army figured it could just wait it out. Maybe the system would mend itself, using some sort of nanobot AI or something. I'm pretty sure I read something in Omni about in back in '81... In the meantime, it applied the most minute of Band-Aids to the problem.
Others who pointed out the flaw to superiors were faced with silent inaction.
A statement issued by senior Army IT security staff after the problem appeared in the news has advised soldiers to be more careful when logging out of shared PCs.Right. Because that "be careful" statement works so well at libraries, schools, offices… basically anywhere anyone shares computers. Of course, most shared computers won't have access to information that could potentially pose a threat to a nation's military if it made it out into the wild. The Army seems to somewhat feel this non-solution might be inadequate, so it's applying another set of "be careful" Band-Aids in a way only a large government entity can: with handbooks and motivational posters and weeklong events.
In response to the problem they are planning an “Information Assurance/Cybersecurity Awareness week” in October as a follow-up measure to their new handbook, released last February, which stresses the importance of individual responsibilities to protect information. According to Lundgren, the handbook “augments current policy, training, and inspection processes and aims to raise awareness and change culture.”I'm guessing the effectiveness of this program will be in the 0% range. It's tough to get anyone to care about an issue you can't be bothered to fix, no matter how many reminders clog up soldiers' inboxes or how many commanding officers read the mandatory "IA/CA Week" announcement in a low, perfunctory monotone.
And once again, we're back to the crux of the issue: the Army won't fix the problem. It doesn't seem impossible or even extraordinarily difficult. There is the matter of scale, which does complicate things, but refusing to tackle the root problem means the hole in the system will remain open and exploitable, no matter how many soldiers are forced into signing NDAs or threatened with jail time or bored to death by "awareness" presentations.
Considering the recent NSA leaks, you'd think the Army would be hammering away at the problem with alacrity, rather than throwing updated policies and freshly-printed handbooks at its personnel.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: army, gag order, nondisclosure, security, security through obscurity
Reader Comments
Subscribe: RSS
View by: Time | Thread
Seems to me that it takes some kind of data loss/compromise event to get any of these "IT personnel" (and I use the term loosely, sarcastically even) to even think about fixing the problem.
If that's the incentive they need to implement better security, then why help them?
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re:
FTFY.
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
They are already attacking the problem with the tools they know the best.
[ link to this | view in chronology ]
Re:
Engineers tend to react the other way, someone who points out a problem is the hero who allowed the problem to be fixed so operations work better.
Unfortunately, bureaucrats tend to be in authority over engineers, most places.
[ link to this | view in chronology ]
It's not a problem if nobody knows about it!
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re:
It's not a problem if nobody knows about it!
Very much a sad but true statement. They go so far as outlaw their own people from knowing what everyone else already knows, even though that action pretty much guarantees failure.
However, having experienced this issue myself (the abnormally slow and long period of time for a system to lock after removing a smart card,) it isn't something the Army can easily fix. The problem is Microsoft's and ActiveCard's. Microsoft has the capability of locking the computer on smartcard removal built into Windows, and it has the option to lock the system, or log the user off. The problem isn't when the lock the system option is used, but when the log the user off option is used (which is used for shared systems.)
Instead of Microsoft/ActiveCard doing the right thing, which is to lock the system, and then process the log-off of the user, it just goes through the standard log-off, which may take some time because running applications are terminated and user data is saved. And if any application asks the user a question (like, do you really want to quit without saving your document?,) the system may sit in a much longer than usual stuck state. If the user is impatient and leaves before this process is completed, then someone else can interrupt the process and continue on using the system.
There are really two ways to fix this problem, and both will require active participation from Microsoft/ActiveCard. The first would be to perform the "log on as different user" capability built into the OS when the user removes their CAC. By doing so, the user is still logged in, and their applications and data are still safe, but the system will allow another user to log in and receive a new session (this is limited in Windows, and since the original user is still running applications and using data, may slow down the system if a couple people are logged in.) Or, Microsoft/ActiveCard could change the software so that upon immediate removal of the card, the system is locked, and the user is logged out in the background.
I doubt the Army has enough clout to fix this themselves.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
I've sat in meetings with Microsoft in which a Microsoft engineer has told us, straight faced, that we don't buy enough of their product to mean anything to their bottom line (even though we apparently have enough clout to have a couple Microsoft-paid engineers working at our facility and with us on a regular basis.) They wouldn't move when we pointed out their software was broken, and we ended up having to write our own software to cover up their failure to fix their software (which they ended up using and pushing out to all their customers.)
Nope, unless the Army levels a couple buildings in Redmond Washington, or takes their business elsewhere (either of which are highly unlikely,) Microsoft will still view them with the same disdain it views all of its other customers.
[ link to this | view in chronology ]
Re: Re: Re: Re:
1. Microsoft delivering buggy software to Army facilities.
2. Army leveling buildings on Microsoft campus.
Who will win? Or will we all win?
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re:
I'd prefer to scratch the whole program entirely and save the money altogether. Why throw good money out with bad.
Implementing a simple Linux based system would be far easier than trying to wring water out of a stone. CAC works with Linux, albeit not as easily, and it wouldn't take too much money to dump Windows and ActiveCard and throw a little at the contractors to come up with what is needed using Linux.
Unfortunately, even with acquisition rules changing to enforce open-source in the selection process, it is still really difficult for open-source to get any sort of traction in government (mainly because it is seen as a free, and thus unsupported, operating system.)
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re: Re: Re: Re: Re: Re:
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Re: Re:
So, a software fix is out of the Army's hands. There is a security fix though, and I'm serious about this even though I'm smiling, change the procedures to force the person logging off to wait until log off is complete. I am assuming that they are using an OS version previous to Windows 7 where this problem is a lot more annoying.
Attempting to hide the problem is horrible security because it is precisely the people you need to worry about who will also end up knowing about it. They could immediately execute each person who found out but that still wouldn't solve the security problem.
[ link to this | view in chronology ]
Re: Re: Re:
Better to just make sure people are aware of workarounds and what to watch out for. If I saw someone run to a station where the user had to rush to a CO's beck and call, I'd be very suspicious of that individual. All because I read an earlier comment that (probably) pretty much sums up the flaw.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
The Army should know better than to use Windows...
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
You'd be surprised. Recent efforts have been put into place to mandate the latest OS's and for the most part, the longest pole in the tent is usually running Windows 7/Windows 2008R2 (very few are pushing for Windows 8.) The problem has always been the program of records, which tend to take forever since engineering is done by a committee and they don't want to break anything by moving to a new OS without testing to make sure everything works exactly the way it worked on the old OS. And then, there is the ton of paperwork, studies, quick-look reports, mandated engineering documentation nobody will ever look at, and security and accreditation processes that turn a simple operation into a 6 year process.
It is still on par with a snail on a cold winter's day, but usually without the molasses part (unless that is used to keep the engineers happy.)
[ link to this | view in chronology ]
Re: Re: Re:
On a slightly different note, It's going to be interesting watching the lawsuits when XP officially becomes unsupported next year. Especially after the first remote OS vulnerability is found.
[ link to this | view in chronology ]
Re: Re: Re: Re:
What lawsuits? Who will be sued? Microsoft is not obliged to support its products forever any more than any other company - and they support their operating systems a lot longer than Apple does. Alternatively, perhaps you might like a ten year old version of Linux - if you could find one. Have you tried firing up ten year old games? Some of them have been patched, but others just refuse to run on Windows 7 or Windows 8. Is that the game publisher's fault? Fine, sue EA. Good luck with that, you couldn't even get your money back if you bought Sim City and found it didn't run in the first few weeks it was out.
Sorry Arthur, but your comment makes absolutely no sense.
[ link to this | view in chronology ]
Re: Re: Re: Re:
[ link to this | view in chronology ]
Re:
[ link to this | view in chronology ]
Re: Re:
The sad part is that the people doing the screening probably don't know all that much more either so how can they be expected to screen?
[ link to this | view in chronology ]
I don't see anything wrong with applying a common sense workaround until it gets fixed. I can only imagine the hell involved in trying to change the software in thousands of military PCs.
[ link to this | view in chronology ]
Re:
Two problems with that statement jump right out at me. First, thay have known about the problem for two years - even for the US military, that is not an adequate response time. Second, if there is a common-sense approach to work around it, you don't silence people - you educate them.
[ link to this | view in chronology ]
Re:
Imagine you are a lower enlisted soldier. You are at the beck and call of NCOs and Officers. Immediate obediance is stressed, for good reason. You may be punished for responding in any way other than instantly. You are working on a computer and your boss yells for your presence. Do you:
A) Remove your CAC card and wait until the computer fully logs you off before going to your commander?
B) Grab your CAC card and rush to the needs of your officer?
The first can result in punishment that could include loss of your weekend, extensive physical exercise, loss of pay and rank, or any number of other penalties depending on how the officer reacts to your slow response. The second results in an exploitable vulnerability in the entire computer system that may compromise personal information to anyone who exploits it.
This is not a viable solution.
[ link to this | view in chronology ]
Re: Re:
[ link to this | view in chronology ]
Re: Re: Re:
[ link to this | view in chronology ]
Nice Army Base here...
[ link to this | view in chronology ]
It seems there's a bug in this program.
[ link to this | view in chronology ]
Re:
The problem sounds pretty obvious so it shouldn't be necessary to hide it. If they really have a problem of large magnitude here, the solution is to inform about how to properly work around it. Therefore the "Information Assurance/Cybersecurity Awareness week" should have happened at lower scale earlier. 2 years before setting these wheels in motion seems like too large a timeframe even for uncle Sam. It sounds like some officers have been far too snappy to hand out warnings, punishments and NDAs while forgetting to move the information up the chain to the right people on this issue.
[ link to this | view in chronology ]
too tricky to fix?
Seems to me it would be easier to threaten and intimidate the developer into issuing a hotfix than it would to threaten and intimidate every system user that tries to speak up and say "Um ... hey guys?"
[ link to this | view in chronology ]
Re: too tricky to fix?
[ link to this | view in chronology ]
Re: Re: too tricky to fix?
And they will never get fixed, because the don't officially exist.
[ link to this | view in chronology ]
Re: too tricky to fix?
[ link to this | view in chronology ]
"A soldier was made to sign a non-disclosure agreement by the US Army after pointing out a security flaw which allowed accounts on shared PCs to be accessed without proper authentication… "
I mean, I know soldiers have no rights whatsoever and can be intimidated into doing anything a superior wants... but it just seems backwards.
Like going to the press and spilling all your secrets, then mumbling "uhhh... off the record, right?"
It's not like hospitals happily perform surgery on you, leaving you crippled for life, then say "hey, we fucked up, so can you please sign this that says you're giving us permission to perform this risky operation that fucked you up?"
Actually, scratch that, I suspect those are probably more real than I think...
[ link to this | view in chronology ]
Been in the business to long, LOGIC SUCKS
Iv been around computer way to long..
MANY corps put backdoors into products to HELP IN FIXING THEM..
The IDEA that placing backdoors that OTHERS CANT FIND into a product, only gives access to OTHERS. thinking that there ISNT another person out there thats AS SMART AS YOU, is stupid logic.
there have been GREAT products made. and there were PROBLEMS with it...The Person that set it up, LEFT/QUIT/DIED/Got pissed off... Could do anything with the set up, or FORGET THE PASSWORD.. and the only thing you could do? START OVER..NEW hardware or a TOTAL RESET of the hardware(not good)..
[ link to this | view in chronology ]
NDA's
[ link to this | view in chronology ]
Re: NDA's
[ link to this | view in chronology ]