Backdoor Found in Lenovo RackSwitch and BladeCenter | Hacker News Reader

Backdoor Found in Lenovo RackSwitch and BladeCenter

bleepingcomputer.com

96 pointslinsomniac25 comments

Who wants to guess requested this backdoor be added?

A source code revision history audit revealed that this authentication bypass mechanism was added in 2004 when ENOS was owned by Nortel’s Blade Server Switch Business Unit (BSSBU). The mechanism was authorized by Nortel and added at the request of a BSSBU OEM customer. Nortel spun BSSBU off in 2006 to form BLADE Network Technologies (BNT). BNT was purchased by IBM in 2010, and, subsequently, Lenovo in 2014.

> Who wants to guess requested this backdoor be added?

It could actually have been added by malicious hackers.. Wikipedia entry[0] reads like Nortel didn't really care about having had their systems completely breached for a decade, nor did they disclose that to any (prospective) buyers of the company.

[0]: https://en.wikipedia.org/wiki/Nortel#Hackers_had_free_access...

>In a security advisory regarding this issue, Lenovo refers to the backdoor under the name of "HP backdoor."

Could they be implying it was HP?

This reads as similar problem as https://www.exploit-db.com/exploits/14875/ (which impacts certain Dell switches)

What is somewhat relevant is that for most of these Accton switches exploiting this vulnerability is the only way to perform factory reset of switch that you don't know password for that does not involve paid out-of-warranty service. To some extent I'm able to believe that this money-grab is the reason for existence of the whole backdoor, only the manager who had this brilliant bussines idea didn't expect that the password generator would get reverse engineered.

What I don't get is: why not do it like HP? With some of their switch gear, you can connect ports 1/2 via cable during powerup to trigger a reset, proving ultimate control over the physical device. Other HP gear I use has a "clear config" pinhole which together with the "reset" pinhole can be used to wipe the password, the config or both.

Also, I remember that some years ago I read a story about a sysadmin who locked down all networking equipment and some of it could actually not be resetted and had to be a) serviced and b) completely reconfigured, leading to significant cost...

Because you cannot collect money each time customer presses physical button (or flips bit in confreg, which is cisco way of doing the same)

Best solution I've seen from the practicality standpoint is distinct "clear password" button on HP ProCurves that you mention which works without power cycling the switch (and thus downtime). Looping ports 1 and 2 which is used by typical non-Accton chinese OEM switches seems like giant hack to me (which can even happen by accident given right environment)

Somewhat relevant observation is that good test for various CCNwhatever wielding network administrators is presenting them with piece of cisco hardware with some "unusual" value in confreg (eg. console port set to something other than 9600 8N1).

> console port set to something other than 9600 8N1

I have some ProCurve switches at work - they auto-detect line speed somehow by making the operator press the Return key twice. If someone can tell me how to replicate this functionality e.g. on a Linux server, here's a bounty offer for some beers...

Looks like you can use picocom to get this functionality from a Linux client, although your probably asking for this from the server. https://linux.die.net/man/8/picocom

In your read loop, when you get data, if it isn't a CR or a NL, change the rate and wait again. You probably don't need to cycle through them all, just the most common options like 9600, 19.2K, 115K... Depending on what you read and what speed you are at, you may be able to make more intelligent choices (a CR sent at 19.2K when you are on 9600 might look like this or that).

Hmm, that would be an interesting implementation idea, however the ProCurves seem to be doing this in hardware as your algorithm would require up to 6 CR presses in the worst case and the ProCurve always needs exactly two... and how do I get to modify the readline implementation of (I presume) the kernel?

Are you SURE they do it in hardware and not switch software? I'd bet it's in software somewhere, but the question I was trying to answer was related to how to get Linux to do it.

At 115.2K, you can probably do it in two CRs, if you look at the data you see. My recollection is that if you have a rate mismatch you often get garbage characters. Just simply the number of garbage characters you get could indicate where you need to change rates to. Like, if you get 10 characters try going to 9600, if you get 5 try going to 19.2K. Just simple timing of how long you get characters might be a good representation of the speed.

I don't really have any serial gear or cables handy, or I'd probably try whipping a Python program together to see if I could do it.

This has to be supported by the UART hardware in order for it to work reliably. The idea is in essence that the receiver measures the length of start bit, this requires the expected character to have first transmitted bit (LSB usually) set to 1. For example this is done by almost all Hayes compatible modems and is the reason why commands start with 'AT' (or in fact, the 'A' itself).

IIRC there is also somewhat reliable and simple (ie. not involving sampling the whole waveform and analysing it after the fact) for doing autodetection for random unknown data, but I cannot find the reference where I've seen it described at the moment (it was in some TI appnote or something similar)

I didn't find the appnote I mentioned, but found another that describes exactly the case of detecting baud rate from one or two CR characters (SLAA215, ie. http://www.ti.com/lit/an/slaa215/slaa215.pdf)

As it happens, when you set UART to 115200 then it will receive the CR character transmitted at any baud rate <115200 (with the obvious caveat that you may get additional garbage characters after that) and for standard baud rates between 9600 and 115k2 you will get unique received bit pattern. If you get zero or framing error then the baudrate is 9k6 or lower, so you change speed to 9k6 and retry the same idea (and if you care about less than 1200 you can do this for the third time, but that starts to be somewhat pointless as the really slow tty baud rates will not generate unique and repeatable bit patterns because they are too close together and are not 115k2 divided by some integer).

[Edit: there is not that much special about using CR for that. You want character with LSB set and the lower hamming weight the better, CR is convinient, 0x01 would work better. Obviously the table garbage=>speed depends on what character you choose, but with some clever masking it can probably be made universal at least for every character with LSB set]

It seems that I misremembered what I read about the more general auto detection. It in fact is not more general, but derived from LIN protocol and involves intentionally sending more complex synchronization pattern, consisting of break, some idle time and then 0x55. On the other the MSP430 hardware is capable of locking onto essentially any received baud rate (not only the standard ones) with sufficient precision by doing this.

> Best solution I've seen from the practicality standpoint is distinct "clear password" button on HP ProCurves that you mention which works without power cycling the switch (and thus downtime).

No downtime == not detectable by monitoring. Port looping by accident is not a problem - when it occurs during operation the network grinds to a halt very quickly after the deed and the hellfire of flashing LEDs should show any operator what is going on, and when it happens during power-up by accident something has gone very wrong...

It is definitely detectable by monitoring.

And it can also be disabled, proliant servers also have or had since I didn’t handled them for years a password bypass button for ILO/IPMI it and it was a god send in some cases.

This is the CVE:

https://nvd.nist.gov/vuln/detail/CVE-2017-3765

And this is Lenovo's page on the issue:

https://support.lenovo.com/us/en/product_security/len-16095

> The existence of mechanisms that bypass authentication or authorization are unacceptable to Lenovo and do not follow Lenovo product security or industry practices

What about their own installation of spyware like Superfish[1] or even harder to remove UEFI malware[2]? Apparently they are OK with doing it, when they do it themselves.

1. https://en.wikipedia.org/wiki/Superfish#Lenovo_security_inci...

2. https://news.ycombinator.com/item?id=10039870

Not really sure why people are downvoting without providing their side of the argument. Your point is valid.

In my probably uneducated opinion, this sounds less like a backdoor, and more like a bug.

The crucial distinction being that this authentication bypass was added intentionally, but arguably forgotten to time and left there unintentionally. But I think fair to say, certainly it was a backdoor when it was originally created.

I disagree, that definitely sounds like something that could have been added. It is very probable whoever had the joy of holding the legacy code support bag after all the transitions had no idea this existed in it.

Will Lenovo always have the shadow of the Chinese government looming over it? Is there a point in the future when the two might be disconnected?

oh which gov does not case this shadow?

Nothing about this has anything to do with the Chinese government specifically. This was introduced by Nortel, then perpetuated by IBM, then eventually discovered by Lenovo.

Reply on news.ycombinator.com