Libssh Authentication Bypass Vulnerability
In late October we saw a vulnerability with the authentication bypass in the server-side component of the Libssh library. Authentication could be bypassed in servers running vulnerable versions of Libssh by presenting the server with an SSH2_MSG_USERAUTH_SUCCESS message, indicating successful authentication, rather than the expected SSH2_MSG_USERAUTH_REQUEST, which requests the start of the authentication process.
The bypass was possible in Libssh version 0.6 and above, but has been fixed in versions 0.8.4 and 0.7.6 of the library. It is also important to note that servers running Libssh2 or OpenSSH are not vulnerable. Most of us need not be too concerned. Peter Winter-Smith, who discovered the vulnerability, has said "half the people on Twitter seem to worry that it affects OpenSSH and the other half (quite correctly!) worry that GitHub uses libssh, when in fact GitHub isn’t vulnerable [...] Remove GitHub and my guess is you’ll be left with a small handful of random sftp servers or IoT devices and little else!”
For more information, refer to the Ars Technica or Bleeping Computer reports.
F5 BIG-IP AFM SSH Proxy Vulnerable to Libssh Authentication Bypass
Following on from the above, F5 Networks released a knowledgebase article confirming vulnerability of their BIG-IP AFM SSH Proxy to the Libssh authentication bypass vulnerability CVE-2018-10933. F5 mentioned that “There is no control plane exposure to this issue. It is only exposed when using the SSH proxy functionality of BIG-IP AFM data plane on a virtual server.” BIG-IP AFM versions 14.0.0, 13.0.0-13.1.1, and 12.1.0-12.1.3 are listed as being impacted. There are currently no versions containing fixes listed, but F5 Networks provide the following recommendation for mitigation:
"You can mitigate the vulnerability by using password and keyboard interactive authentication as opposed to public key authentication with the AFM SSH proxy feature."
Supermicro Supply-Chain Attack Continues...
Last week we blogged about a number of US companies, including a major bank and government contractors falling victim to a hardware supply-chain attack against Supermicro. In the days following Bloomberg’s original report, confusion reigned. Many InfoSec newswires were reporting on the validity of the claims, while others were calling them into question.
An Australian InfoSec podcast, Risky Business, initially released an interview with a source that corroborated the Bloomberg piece. Shortly thereafter, Risky Business released a correction, as the source had retracted their claims. Risky Business also went on to release another podcast in which they interviewed hardware security expert Joe Fitzpatrick, a named source in the original report, who felt uncomfortable when reading the report, as all of the hypotheticals that he had discussed with Bloomberg have been reported as fact. Risky Business also attacked Bloomberg for historically inaccurate reporting in the InfoSec space.
Bloomberg has since come out with a second report claiming to have new evidence of tampered Supermicro hardware discovered inside a US telecommunications company, this time claiming that “Unusual communications from a Supermicro server and a subsequent physical inspection revealed an implant built into the server’s Ethernet connector." Risky Business again takes a look at these claims in a subsequent podcast.
Regardless of which side of the fence you sit on with respect to Bloomberg and their reporting, our advice from last week still stands:
- Supply-chain attacks – both hardware- and software-based – are possible. We need to ensure due diligence when selecting suppliers of any componentry that we choose to integrate into our networks
- Visibility and understanding what is “normal” is key. Only through understanding the “normal” can we detect the “abnormal” and investigate. This doesn’t have to apply to low-level component analysis, but can deliver valuable security outcomes when looking at user behaviour, network traffic, and other indicative metrics
Audits - The Missing Layer in Cybersecurity
Dark Reading has published a piece by ISACA Board Vice Chair and Vice President of Global IT Risk Management at Oracle Corporation (USA), Brennan P. Baybeck, in which he talks about the need for a cybersecurity audit function in ensuring that “common gaps in organizations' cybersecurity posture […] most notably insufficient controls around data management” are identified.
“Organizations often miss the mark on cybersecurity when they focus predominantly on the technology components of their programs rather than looking at people, processes, and technology in a more overarching way. Involving the audit team in cybersecurity helps make sure that the attention is not just on technology implementations; auditors also can identify instances when technology solutions are sitting on the shelf or being underutilized, rather than being deployed to strategically address security risks. Additionally, audits can help evaluate critical challenges such as coverage models, skill sets, training and gaps in key resource capabilities.”
It is important to note that an audit function doesn’t have to rely on external auditors. Internal auditors can also deliver cybersecurity improvement benefits to the organisation. However, it is critical that any internal audit function is independent of the departments who build and maintain the technology and processes that they are tasked to audit.
Contact Us today to find out how Thomas Duryea Logicalis can support you with your organisation's security concerns and posture.
