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

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/14/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Lock-Pickers Face an Uncertain Future Online
Seth Rosenblatt, Contributing Writer,  8/10/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-20383
PUBLISHED: 2020-08-13
ABBYY network license server in ABBYY FineReader 15 before Release 4 (aka 15.0.112.2130) allows escalation of privileges by local users via manipulations involving files and using symbolic links.
CVE-2020-24348
PUBLISHED: 2020-08-13
njs through 0.4.3, used in NGINX, has an out-of-bounds read in njs_json_stringify_iterator in njs_json.c.
CVE-2020-24349
PUBLISHED: 2020-08-13
njs through 0.4.3, used in NGINX, allows control-flow hijack in njs_value_property in njs_value.c. NOTE: the vendor considers the issue to be "fluff" in the NGINX use case because there is no remote attack surface.
CVE-2020-7360
PUBLISHED: 2020-08-13
An Uncontrolled Search Path Element (CWE-427) vulnerability in SmartControl version 4.3.15 and versions released before April 15, 2020 may allow an authenticated user to escalate privileges by placing a specially crafted DLL file in the search path. This issue was fixed in version 1.0.7, which was r...
CVE-2020-24342
PUBLISHED: 2020-08-13
Lua through 5.4.0 allows a stack redzone cross in luaO_pushvfstring because a protection mechanism wrongly calls luaD_callnoyield twice in a row.