Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

12/2/2008
05:16 PM
David Maynor
David Maynor
Commentary
50%
50%

Hiding In Plain Sight Doesn't Work

I do a lot of penetration tests and vulnerability assessments for an assortment of business of all sizes. While doing these types of tests, I run into a lot of goofy configurations, strange setups, and wacky ideas that are an attempt by the client to improve security. The most head-scratching setup I constantly run into involves SSH on a port other than the one it is assigned, Port 22.

I do a lot of penetration tests and vulnerability assessments for an assortment of business of all sizes. While doing these types of tests, I run into a lot of goofy configurations, strange setups, and wacky ideas that are an attempt by the client to improve security. The most head-scratching setup I constantly run into involves SSH on a port other than the one it is assigned, Port 22.In recent years, a low tech, brute-forcing of user names and passwords has gained popularity because of how easy it is, so it seems to be a widely held belief among system administrators that by changing the default SSH port, they increase their level of security.

In honor of this phenomenon, I now keep a text file of the ports I find an SSH daemon running on, and the explanation offered by the administrator of how this change improves security. I won't list the explanations here, but here's the gist of their justifications: attackers will not bother launching a scan against the entire port range of a box, and a scanning tool is not advanced enough to grab service banners. Admins generally provide me with these explanations during a post assessment wrap-up meeting, and they are typically surprised that their SSH daemon running on port 65022 is listed in the report at all. It's almost like pointing out a trap door or a mirror in a magic act. This is not meant to make fun of these system administrators. In fact, I applaud anyone who actually thinks enough about security to try something new. The problem I have with this constant reinvention of the wheel is that clever little tricks like this will often get overlooked when it comes time for patching, setting up access controls, and regular maintenance.

A few months ago, I ran into a situation that epitomized why this sort of port trickery is not just bad practice, but downright dangerous. During an audit for a financial institution, an SSH server was found to be listening on a port above 10000 and was accessible to anyone on the Internet. To compound the problem, the host also ran a Web server with a custom-written PHP Web application that was vulnerable to a file-retrieval problem, which gave me access to /etc/passwd. After a few minutes, "John the Ripper" and the usernames had passwords associated with them -- allowing for an easy login for an outsider. I need to pause for a second and talk about the security setup there. The security manager was mistakenly under the impression that SSH was administratively forbidden by the corporate security policy and enforced at the firewall. Remote access is granted by requiring administrators to login through a VPN first, and then SSH to a server. When the security manager performed scans, only well-known ports were targeted. Any request by a system administrator to open port 22 to a server was denied. Soon, SSH went from port 22 to random ports above 10000, and the firewall did not stop them because the rules were written to protect the only well-known ports. The SSH port problem makes compromising the network much easier, and that server provided a foothold in the network that allowed the rest of the hosts to be compromised. Needless to say, the security manager was furious. The results of the audit very plainly showed that 32 of the 40 servers they had Internet-facing had SSH open to the world on a port above 10000. They were surprised I would waste my time scanning the entire range of ports on the server. That's like not bothering to lock your door because no one will check it.

To set the record straight, most automated SSH brute-force tools will only check port 22, moving on if it is unreachable. A directed attack -- someone who is after you or something you have -- will have time to wait. The popular tool Nmap can find open SSH servers with just the command line option "-sV." Running a test of Nmap looking for just port 22 versus scanning all available TCP ports yields a difference of about 20 seconds. Although that can add up, the dirty little secret of attackers and penetration testers is that nobody sits in front of a console waiting for the scans to complete. You start the scan and wait to get notified when it is complete. Because of this, the "time consuming" argument holds no merit. Keep this in mind: Circumventing normal operational procedures will not make you more secure, and in most cases it has the exact opposite result. If you are worried about people brute-forcing your SSH server, run some type of access control that will restrict who has access to it.

David Maynor is CTO of Errata Security. Special to Dark Reading

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Cybersecurity Industry: It's Time to Stop the Victim Blame Game
Jessica Smith, Senior Vice President, The Crypsis Group,  2/25/2020
5 Ways to Up Your Threat Management Game
Wayne Reynolds, Advisory CISO, Kudelski Security,  2/26/2020
Google Adds More Security Features Via Chronicle Division
Robert Lemos, Contributing Writer,  2/25/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
6 Emerging Cyber Threats That Enterprises Face in 2020
This Tech Digest gives an in-depth look at six emerging cyber threats that enterprises could face in 2020. Download your copy today!
Flash Poll
State of Cybersecurity Incident Response
State of Cybersecurity Incident Response
Data breaches and regulations have forced organizations to pay closer attention to the security incident response function. However, security leaders may be overestimating their ability to detect and respond to security incidents. Read this report to find out more.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-9447
PUBLISHED: 2020-02-28
The file-upload feature in GwtUpload 1.0.3 allows XSS via a crafted filename.
CVE-2019-10064
PUBLISHED: 2020-02-28
hostapd before 2.6, in EAP mode, makes calls to the rand() and random() standard library functions without any preceding srand() or srandom() call, which results in inappropriate use of deterministic values. This was fixed in conjunction with CVE-2016-10743.
CVE-2019-8741
PUBLISHED: 2020-02-28
A denial of service issue was addressed with improved input validation.
CVE-2020-9399
PUBLISHED: 2020-02-28
The Avast AV parsing engine allows virus-detection bypass via a crafted ZIP archive. This affects versions before 12 definitions 200114-0 of Antivirus Pro, Antivirus Pro Plus, and Antivirus for Linux.
CVE-2020-9442
PUBLISHED: 2020-02-28
OpenVPN Connect 3.1.0.361 on Windows has Insecure Permissions for %PROGRAMDATA%\OpenVPN Connect\drivers\tap\amd64\win10, which allows local users to gain privileges by copying a malicious drvstore.dll there.