Last Updated: 2013-01-27 00:51:59 UTC
by Scott Fendley (Version: 1)
If you look over the ISC diaries from the past few years, you will find a sizable number which discuss some vulnerabilty or another involving SSH. Recently, I have seen a number of security issues involving SSH that has caught my attention. The first two are the recent announcement of the Barracuda backdoor earlier this week, and that malware authors have been targeting Linux with backdoored SSH daemons meant to steal account credentials.
The next didn't directly involve SSH, but does shine a light on the lax controls that many organizations have toward resources that should only be accessible inside the corporate network. That Google was able to index a significant number of HP printers seems to indicate that many organizations have been slow to limit the flow of data in and out of the network.
I would assume that most security concious enterprises have taken steps to require their workforce to VPN into the organization prior to doing a Remote Desktop session, or access services containing senesitive data. I remember the pain and pushback felt as we implemented this security control in the recent past. And I remember the sob stories from IT professionals who complained that we were being unreasonable, or needed an exception to the rule. (No you do not need an exeption just because your iPad can't seem to keep a VPN connection stable, while you are doing video editing over an RDP connection. But I digress.)
From my experience, a breach involving SSH seems to have much greater risk than that of compromising a single workstation. SSH is primarily used by systems administrators, networking engineers, and developers to access some of the most critical infrastructure in an organization. From a financial standpoint, the SFTP side of the protocol is used by many organizations to upload ACH transactions to their respective bank.
I have personally seen an uptick the amount of SSH scans, but am not seeing a surge within the DShield data as of yet. Many organizations may be protecting the inbound and outbound activity well, but the vast majority may not be. It is probably past time that the rest of us to take steps to limit the security exposures to our critical systems with regard to SSH. Blocking inbound SSH is only one piece in the puzzle.
Be on the lookout for more activity involving SSH in the upcoming months and years. Anyone else seeing an uptick in SSH activity in the past week? Or is this a localized targeted attack?
Scott Fendley ISC Handler