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
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Attackers' Costs Increasing as Businesses Focus on Security
Robert Lemos, Contributing Writer,  11/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-19037
PUBLISHED: 2019-11-21
ext4_empty_dir in fs/ext4/namei.c in the Linux kernel through 5.3.12 allows a NULL pointer dereference because ext4_read_dirblock(inode,0,DIRENT_HTREE) can be zero.
CVE-2019-19036
PUBLISHED: 2019-11-21
btrfs_root_node in fs/btrfs/ctree.c in the Linux kernel through 5.3.12 allows a NULL pointer dereference because rcu_dereference(root->node) can be zero.
CVE-2019-19039
PUBLISHED: 2019-11-21
__btrfs_free_extent in fs/btrfs/extent-tree.c in the Linux kernel through 5.3.12 calls btrfs_print_leaf in a certain ENOENT case, which allows local users to obtain potentially sensitive information about register values via the dmesg program.
CVE-2019-6852
PUBLISHED: 2019-11-20
A CWE-200: Information Exposure vulnerability exists in Modicon Controllers (M340 CPUs, M340 communication modules, Premium CPUs, Premium communication modules, Quantum CPUs, Quantum communication modules - see security notification for specific versions), which could cause the disclosure of FTP har...
CVE-2019-6853
PUBLISHED: 2019-11-20
A CWE-79: Failure to Preserve Web Page Structure vulnerability exists in Andover Continuum (models 9680, 5740 and 5720, bCX4040, bCX9640, 9900, 9940, 9924 and 9702) , which could enable a successful Cross-site Scripting (XSS attack) when using the products web server.