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.