Tag Archives: SSH

Malware Uses Linux Systems as Proxies

A Trojan horse (defined) is compromising Linux systems by exploiting poorly implemented SSH (Secure Shell)(defined) remote access. Many are already compromised systems first have a new account created with a notification to the Trojans authors providing the details of the system enabling a remote connection. The Trojan then installs the Satanic Socks Server utility to set up proxy server (defined) for use by the attackers or any individual they chose to connect to your system (very likely for a fee). More information on this threat is available here and here.

How Can I Protect Myself from This Threat?

If you are an administrator of Linux servers/workstations you should ensure remote SSH access uses a strong authentication mechanism. If this access is not required, strongly consider disabling SSH access.

To check if your Linux system has already been compromised, you can list the user accounts from a Linux system using the commands below. If you locate any suspicious accounts, you can delete them. I will also provide other useful commands below:

cat /etc/passwd
: this will list the name of user accounts
grep :0: /etc/passwd : will find accounts with the string “”:0″” within them (accounts with root privileges)

crontab -l -u root : display cron jobs (defined) scheduled by root and any other UID 0 accounts

Attackers often schedule jobs that include backdoors on the machine guaranteeing the attacker return access to the system.

The above commands are particularly useful if you already know the outputs of these commands when your system is working fine/as expected. You can then compare those known good outputs to the current output to more easily determine if your system has been compromised.

If you find a rogue/unknown user account; you can delete it using the following command:

userdel -r [account name]

where [account name] is the name of the user account that you wish to delete.

I hope that the above information is useful to you in protecting your Linux systems against this threat.

Thank you.

OpenSSH Releases Further v7.2 Security Update

On Wednesday of last week OpenSSH released version 7.2p2 which corrected a security vulnerability due to X11 forwarding (defined) commands not being correctly sanitised that could have allowed information disclosure.

Why Should These Issues Be Considered Important?
This vulnerability could have allowed an attacker that had already compromised an existing users account on a Linux system to carry out the following (usually not permitted) actions:

  • allow limited information leakage
  • file overwrite
  • port probing
  • generally expose xauth(1) which was not written with a hostile user in mind, as an attack surface
  • allow the circumventing of key or account restrictions such as sshd config or ForceCommand, authorized keys command=”…” or restricted shells (defined)

Further details of this vulnerability are provided by OpenSSH here.

How Can I Protect Myself from This Issue?
Please upgrade to OpenSSH version 7.2p2 (the most recent version at the time of writing) to resolve the security issue mentioned within this post. You can install this update by using your Linux package manager to download the necessary files for your version of OpenSSH. Steps to do this for popular Linux distributions are provided on the “Protecting Your PC” of this blog.

Thank you.

ThreatPost: OpenSSH Implementations with X11forwarding Enabled Should Heed Recent Security Update

OpenSSH Releases v7.2 Security Update

On the 29th of February OpenSSH released version 7.2 of OpenSSH which further hardened it against the Logjam attack (by increasing the minimum modulus size supported for diffie-hellman-group-exchange to 2048 bits) as well as incorporating changes initially made available in mid-January with version 7.1p2

Why Should These Issues Be Considered Important?
Further hardening OpenSSH against Logjam is important for the reasons detailed in my previous blog post on that attack.

With version 7.1p2, experimental support for client-side (where a client is the name given to computer/device being used by a person to access a server) roaming support was disabled to resolve a high severity information disclosure issue. Roaming is the name given to the ability to resume an SSH (Secure Shell, defined) connection from where it left off should a client become disconnected suddenly.

While this issue is not easy to exploit (further details provided below in the heading “How Can I Protect Myself from These Issues”) it had the potential to allow an attacker who had compromised a legitimate SSH server to obtain the credentials (username and password) of the user attempting to access the server. If the attacker controlled server had SSH private keys stored in it’s memory the attacker could have also compromised further SSH accounts.

3 other low risk security vulnerabilities detailed in the release notes were also resolved within version 7.1p2. For version 7.2, the above mentioned roaming code was removed and 2 further security issues detailed in the release notes were resolved.

How Can I Protect Myself from These Issues?
The means of authentication to the SSH server prevents the exploitation of the information disclosure issue mentioned above (fixed in version 7.1p2) by means of a man-in-the-middle attack (defined). While you are working to deploy the patch for this issue, for versions 5.4 of OpenSSH and higher the roaming code can be disabled as follows (source):

  • adding ‘UseRoaming no’ to the global ssh_config(5) file
  • or to user configuration in ~/.ssh/config
  • by passing -oUseRoaming=no on the command line

Please upgrade to OpenSSH version 7.2 (the most recent at the time of writing) to resolve all of the security issues mentioned within this post.

Thank you.

Putty 0.67 Security Update Released

Yesterday an update to the open source Putty SSH client (Secure Shell, defined) for Windows was released (bringing it to version 0.67) resolving a high priority security issue and to “defend against malicious other processes reading sensitive data out of its memory” by setting it’s process ACL (defined) more restrictively.

This update also fixes other software bugs and it’s executable files and installer are now digitally signed (defined) using Authenticode. Full details of the changes in version 0.67 are available in the changelog.

The updated version is available for download from this page. Please ensure to only download Putty from the previously provided link since tampered versions have previously been made available in an effort to spread malware.

If you use Putty, please update as soon as possible to benefit from the security fixes version 0.67 includes as well as the general software bugs that were also addressed.

Thank you.

Juniper Issues Emergency Security Updates For VPN Devices

On the 17th of December Juniper Networks released a security advisory which detailed 2 critical security issues (these have been assigned 2x CVE numbers (defined) within their NetScreen devices which offer VPN (Virtual Private Networks) (defined) access. Juniper have released emergency security updates to address these issues.

Why Should These Issues Be Considered Important?
The first issue assigned CVE-2015-7755 could allow an attacker to remotely access your Juniper VPN device using SSH or telnet. They could do so by accessing your device using either of these protocols. They will then receive a logon prompt however due to this issue they can enter any username and since the password has been publically disclosed they would then obtain access to your device with the highest privileges available. This is an extremely serious backdoor (defined) that an attacker can easily exploit.

The second vulnerability designated CVE-2015-7756 could allow an attacker who can capture your VPN network traffic to decrypt that encrypted traffic and read all of it’s contents. In addition, there is no means of detecting if this second vulnerability has been exploited.

Juniper NetScreen devices using the operating system versions mentioned below have been confirmed to have been affected by these issues:

The first issue mentioned above (the administrative access issue) affects the following versions of ScreenOS (the operating system that powers these Juniper devices):

ScreenOS 6.3.0r17 through 6.3.0r20

The VPN decryption issues affects ScreenOS 6.2.0r15 through 6.2.0r18 and 6.3.0r12 through 6.3.0r20

Finally, there are theories with compelling evidence of how this backdoor code came to be present within Juniper’s products in the first instance. The definitive answer does not appear to be completely clear at this time. If you wish to read more on this aspect of these security issues, please find below further references:

Juniper Finds Backdoor That Decrypts VPN Traffic by Michael Mimoso (Kaspersky ThreatPost)
Juniper Backdoor Password Goes Public by Michael Mimoso (Kaspersky ThreatPost)
Juniper Backdoor Picture Getting Clearer by Michael Mimoso (Kaspersky ThreatPost)
On the Juniper backdoor by Matthew Green (John Hopkins University)
Who were the attackers and how did they get in? by Jeremy Kirk (IDG News Service)
CVE-2015-7755: Juniper ScreenOS Authentication Backdoor by H. D. Moore (Rapid7)
“Unauthorised code” on Juniper firewalls gives attackers admin access, decrypts VPN traffic by Graham Cluley (writing on behalf of BitDefender)

How Can I Protect Myself From These Issues?
As directed within Juniper’s security advisory if you are using the affected Juniper devices within your corporation or small business, please apply the necessary updates as soon as possible since these issues are very serious. Download links for these updates are provided within the above mentioned security advisory. Juniper also supplies additional best practice within that advisory.

SNORT IDS/IPS (defined) and Sagan (an open source log analysis engine) rules to detect the first issue (administrative access) being exploited are provided in Rapid7’s blog post. That blog post also contains advice if you are having an issue installing the updates to address these issues.

Thank you.

Note: I am currently working on more upcoming content for this blog. Since this will be my final post before the 25th of December I wanted to wish you and yours a safe and very Merry Christmas / Happy Holidays. I will return later this week with more blog posts.

Thanks again.

Very Large Number of Routers/Modems/Internet Gateways Contain Non Unique X509 Certificate and SSH Keys

In the late November the security firm SEC Consult released details within a blog post of their findings after they had conducted scans of many thousands of embedded devices from almost 70 manufacturers. These devices were found to contain X.509 certificates (defined) and SSH (Secure Shell, defined) private keys (from the public/private key pairs namely Asymmetric Encryption (defined)) which were shared among other similar devices from other manufacturers.

Why Should These Issues Be Considered Important?

If an attacker was located within the same network as one of these embedded devices they could perform a man-in-the-middle attack (MITM, defined) allowing them access to any sensitive information e.g. passwords that are being transmitted on the network at that time.

SEC Consult found that approximately 4 million devices are affected by this issue.

A remote attack (i.e. from an attacker not located within your network namely the wider Internet) is far more difficult to conduct and would require the capabilities discussed within the paragraph titled “What is the impact of the vulnerability?” of SEC Consult’s blog post.

For the full list of affected manufacturers of these devices, please see the paragraph titled “Which vendors/products are affected?” of SEC Consult’s blog post and the “Vendor Information” section of this US CERT article. Finally, for affected Cisco devices, a list of affected device models is provided here.

How Can I Protect Myself From These Issues?
For the end users (consumers) who have purchased or have been provided these devices by their ISP’s (Internet Service Providers) there is no action that can be taken to resolve these issues. Since the vulnerable keys are embedded within the firmware of these devices they cannot easily be updated. In some instances however, an update is possible.

If you own a device manufactured by one of the affected vendors (obtained from the lists linked to above) I would follow US CERT’s advice of contacting the vendor to ask if an update for your device will be made available. You can link to SEC Consult’s blog post and US CERT’s advice if the vendor wishes to seek clarification on the issue/vulnerability you are referring to.

For anyone affected by this issue I hope that the above information is of assistance to you. Thank you.

Cisco Releases Scheduled Security Updates For IOS and IOS XE

Earlier this week Cisco released security updates to address authentication bypass and denial of service (defined) security vulnerabilities within Cisco IOS and IOS XE.

Why Should These Issues Be Considered Important?
The SSHv2 RSA authentication bypass vulnerability could allow an unauthenticated remote attacker to obtain the access privileges of the logged in user or the privileges of the Virtual Teletype (VTY) line which could be admin privileges. The attacker would however need to know a valid user name and possess a specifically crafted private key. The only workaround to this issue is to disable RSA based SSHv2 authentication.

Meanwhile a vulnerability in the processing of IPv4 packets that require Network Address Translation (NAT) and Multiprotocol Label Switching (MPLS) services could allow an unauthenticated remote attacker to cause your Cisco IOS XE device to stop functioning (namely a denial of service attack. The attacker would only need to send the device a specifically crafted IPv4 (defined) packet.

This flaws affects the following products:

  • Cisco ASR 1000 Series
  • Cisco ISR 4300 Series
  • Cisco ISR 4400 Series
  • Cisco Cloud Services 1000v Series Routers

Separately 2 vulnerabilities in the IPv6 snooping feature from the first-hop security features in Cisco IOS and IOS XE Software could also cause a denial of service issue. For an attacker to exploit the insufficient validation of IPv6 ND packets they would only need to send it a malformed IPv6 packet. For the second flaw, the insufficient Control Plane Protection (CPPr) against specific IPv6 ND packets an attacker would need to send a large amount of specifically crafted IPv6 ND packets to a vulnerable device.

For the vulnerabilities involving the processing of IPv4 and IPv6 (defined) packets, no workarounds are available (apart from disabling the IPv6 snooping feature) to mitigate the 2x IPv6 flaws until the appropriate security updates are installed.

The remaining vulnerabilities affect any Cisco device running IOS and/or IOS XE. As you can see, only the access bypass issue is likely to pose a challenge to a determined adversary, all other issues discussed above could potentially be easily exploited.

How Can I Protect Myself From These Issues?
Within the Cisco security advisory you can use the link provided to access the Cisco IOS Software Checker to determine if your Cisco IOS device is vulnerable to these issues. This security advisory also provides the links to the individual advisories for each vulnerability which contain the steps to install the appropriate updates.

Thank you.

OpenSSH Releases v7.0 To Patch Security Issues

OpenSSH has released v7.0 of their popular SSH implementation. This version resolves 2 issues (1x use-after-free (defined) and 1x privilege separation weakness) in the portable version of OpenSSH and 2 further issues in the standard version.

Of the 2 remaining issues, one is a fix for the issue that I previously discussed regarding how keyboard-interactive logins can be used misused to brute-force your password. The remaining issue involves resolving an issue that could allow local attackers to write arbitrary messages to logged-in users.

Another change in this new release of OpenSSH is that this release also resolves the Logjam security issue by rejecting 1024-bit diffie hellman key exchanges.

You can install this update by using your Linux package manager to download the necessary files for your version of OpenSSH. Steps to do this for popular Linux distributions are provided on the “Protecting Your PC” of this blog. Additionally this FAQ (from the OpenBSD website) may be of assistance.

If you use OpenSSH, please install the appropriate update when you can. If OpenSSH is installed on a critical production system or systems that contain your critical data, please back up your data before installing this update in order to prevent data loss in the rare event that an update causes unexpected issues.

Thank you.

OpenSSH Potentially Vulnerable To Password Brute Force Attack

Update: 13th August 2015:
OpenSSH has released v7.0 which addresses the issue discussed in this post.

In late July a security issue with the most widely used SSH (Secure Shell, defined) implementation namely OpenSSH for Linux based systems was documented on the Full Disclosure mailing list. SSH uses port 22, TCP (see Aside (below) for a definition) or UDP (see Aside 1 of this post for a definition).

The issue involves the now less used method of keyboard-interactive login (where you type your password using a keyboard when prompted by the server). Many SSH sessions today are set up using automated secure connections (since they are automated no person is present to type the password). Instead public key cryptography (asymmetric encryption) allows you to verify your identity to the server as follows:

In order to do this, you initially create 2 keys a public and a private key. You send the public key to the server. When you wish to log into that server it will send a challenge (a cryptographic nonce) encrypted with the public key that you previously provided. You then use your private key to decrypt that nonce, re-encrypt it with your private key and send it back. The server then uses the public key to decrypt what you have sent. This verifies to the server that you do indeed possess the correct private key and are authorized to use the server. Guides on how to set up this feature are provided here and here.

Why Should This Issue With OpenSSH Be Considered Important?
On some OpenSSH installations especially FreeBSD systems have keyboard-interactive authentication enabled by default. When this is the case, you can specify via command line parameters to OpenSSH to allow for example 10000 individual keyboard devices to try to respond to the password being requested by the server you are attempting to access. This means that you will have 10000 attempts to guess the password of the server. This would allow you to execute a brute force attack to try to obtain the password.

If the password is quite weak, 10000 attempts will be more than enough to obtain/guess that password. The server does only allow you (by default) to have 2 minutes for the “login grace time” to allow you to enter your password, thus the attack would also be limited to this time, however 10000 guesses within 2 minutes is possible. When the password is obtained an attacker can then use your server with the same level of access that you have for any purpose they wish.

What is TCP?

Transmission Control Protocol (TCP) is a connection oriented transport protocol within the larger TCP/IP ((Internet Protocol) suite which provides reliable data transmission (due to error checking and re-sending of packets corrupted or not received) and preserves the order of packets that are transmitted from a source device to a destination device. TCP/IP is a suite of protocols that provides worldwide connectivity between the devices that make up the Internet.

With TCP the connection between 2 devices must be set up and torn down. This in contrast to UDP that provides a connectionless data transmission service.

How Can I Protect Myself From This Issue?

While OpenSSH 6.9 is currently available, the upcoming version 7.0 does not appear to include revised default settings to eliminate the issue discussed above. The above suggestions should keep you safe from this potential brute force attack.

Update: 13th August 2015:
OpenSSH has released v7.0 which addresses the above issue discussed in this post.

Thank you.

Cisco Comms Software and Security Appliances Use Default Credentials and Keys

In late June and early July this year Cisco released security updates for its Unified Communications Domain Manager Software, Cisco Web Security Virtual Appliance (WSAv), Cisco Email Security Virtual Appliance (ESAv), and Cisco Security Management Virtual Appliance (SMAv) devices to resolve their use of default passwords and SSH keys. Such default keys/credentials are not uncommon as mentioned in my post detailing SAP’s use of a default encryption key for their HANA database. It should be noted that Cisco is not the only vendor to have used default SSH (Secure Shell) keys.

When the Unified Communications Domain Manager Platform Software is installed a fully privileged account is created by default and the password to access this account is the same for all software installations. If the password was obtained by an attacker, they could remote and anonymously connect to the system running this software via SSH and take complete control of that system (since the default account created has root privileges).

A similar default SSH key was found to be in use within the above mentioned Cisco security appliances. Just as detailed above an SSH key is present on all of these appliances by default. Again if this key was obtained and used by an attacker, they would have complete control of your Cisco security appliances. Fortunately both of these classes of issues for Cisco products were discovered by internal security testing and not by attackers leveraging them before they were patched/fixed.

Update: July 13th 2015: The Cisco security advisory for the relevant Cisco security appliances mentioned below clarifies (within the “Details” section) that the static SSH keys stored within the Cisco security appliances are the private keys. Since SSH uses asymmetric cryptography if an attacker obtains the private key they can impersonate the security appliance and decrypt communications among these appliances. The attacker would need to use a man in the middle attack (MITM, MITM defined) in order to decrypt the communications.

How Can I Protect Myself From These Issues?
If your company uses any of the above mentioned Cisco products, please follow the directions within the Cisco security advisories mentioned below to resolve these critical vulnerabilities:

Multiple Default SSH Keys Vulnerabilities in Cisco Virtual WSA, ESA, and SMA
Cisco Unified Communications Domain Manager Default Static Privileged Account Credentials

As mentioned in this news article Cisco have resolved such flaws in the past and the potential for attack/exploitation is very real since the exploit framework Metasploit has exploits for similar flaws and firms such as Rapid7 are building libraries of known SSH keys.

Thank you.