Disclosure notices that some company, some website, or some server has been compromised are growing in numbers. But there is something rather disconcerting in these notices that have been bothering me for quite some time, which has prompted me to write about it.
The recent Adobe breach, coupled with a forensic audit I just completed that really sent my mind racing down the path I’m about to share with you. Although there are disclosures that something has been breached, the notices are always lacking information – specifically, details.
Now, I understand the need for keeping some things in security close to the chest – so to speak – but there’s a looming, unforeseen threat in not fully disclosing. That threat is a possible further breach of untold proportions when we practice non-disclosure of the details.
Take for example the Adobe breach. We were told that there was a compromise on the server which allowed access to the source code of the Adobe products and usernames and credit card information of users. But little was said about the source code access.
One might think that the source code could simply be the programming code that makes the actual Adobe product what it is – what makes it function. But Adobe, like many other self-updating software also has a component in it that pushes updates to its users. Java, Microsoft products, and many, many more software providers do this on a regular basis.
Let’s take a walk on the wild side of my brain for a minute:
Let’s pretend I’m a hacker and I break into Oracle or Microsoft (pick anyone you’d like). I gain access to the source code which includes the programming code that allows the updates to be pushed to users. What do you suppose I could do with that code?
I could use it to push an update of my own, couldn’t I?
I could create a horrible, malicious malware that makes ransomware look like an amateur coded it. Or, I could make a small update that would implant a backdoor, rootkit, or some other method of access into the users system. And if you think that isn’t possible, look at how long Flame and Stuxnet went undetected!
I’m growing extremely concerned about the need for secrecy in disclosing.
In the original blog post regarding the breach, Adobe published a link to locking down ColdFusion. In the ColdFusion 10 Lockdown Guide, there are slightly over 56 pages of recommendations for securing installations of ColdFusion including one that creates a dedicated and restricted user for IIS server installations. How many of the server admins that might be reading this post have done that?
But it’s not just the server admins that need to worry in this situation. What about average users of Adobe products? How does the average Joe or Jill consumer know that the update notice they’re getting on their device is from Adobe? Or Java, or Microsoft for that matter?
Nearly 8 months ago, I had a client contact me that he had received a Java pop-up that there was an update available. When he downloaded the update, it was anything but a legitimate update. Unfortunately, he did not save any of the files or forensic data so I could review what happened and how it was done. But that one, single incident was brought back to mind when I read about the Adobe source code breach.
Microsoft is also notorious for its non-disclosure in patches and updates. The nebulous “may give a remote hacker access to….” Or, “could cause an elevation in privileges…..” statements tell us nothing about what’s being orchestrated. What if, disclosing the full details could lead a security researcher to find another, potentially more dangerous flaw?
The malicious powers that be will always have the inside track of what vulnerability is accomplishing what end. It’s the system admins, general users, and security professionals who don’t have the time to scour hacker forums for details that suffer. We’re put at a direct disadvantage by not knowing the details with full disclosure.
As for the Adobe breach, I’m recommending to all my students and clients to go directly to the Adobe page to download the latest version of the software and not to trust the update function at this point in time. I personally do the same with Java updates. If the pop-up tells me there’s an update, I go straight to the Oracle website and get it.
A little healthy paranoia can be a good thing. Especially when we’re being left in the dark even when there’s been disclosure. A philosophy I recommend that all administrators, technicians, and security professionals adopt now, rather than later.
About the Author: Debbie Mahler (@DebbieMahler) is the CEO of Internet Tech Specialists. She’s an online instructor for Ed2go, a division of Cengage Learning and a global education provider. She teaches Introductory and Advanced PC Security courses for all English-speaking colleges and universities.
Editor’s Note: The opinions expressed in this and other guest author articles are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.
- Security is a Process, Not a Destination: Have You Given It Your All?
- How Target’s Point-of-Sale System May Have Been Hacked
- Why the Target Breach Might Be Even Bigger: Big Data Means Big Breach
- Stolen Target Credit Cards and the Black Market: How the Digital Underground Works
The Executive’s Guide to the Top 20 Critical Security Controls
Tripwire has compiled an e-book, titled The Executive’s Guide to the Top 20 Critical Security Controls: Key Takeaways and Improvement Opportunities, which is available for download [registration form required].
Definitive Guide to Attack Surface Analytics
Also: Pre-register today for a complimentary hardcopy or e-copy of the forthcoming Definitive Guide™ to Attack Surface Analytics. You will also gain access to exclusive, unpublished content as it becomes available.
Title image courtesy of ShutterStock