5 ms·

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

by dfox 9y ago

This reads as similar problem as https://www.exploit-db.com/exploits/14875/ 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.

mschuster91 9y ago
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...
- dfox 9y ago
  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)
  - dfox 9y ago
    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).
    - mschuster91 9y ago
      > 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...
      - dfox 9y ago
        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)
        dfox 9y ago
        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 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.
  - mschuster91 9y ago
    > 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...
    - dogma1138 9y ago
      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.

by dfox 9y ago

mschuster91 9y ago

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...

dfox 9y ago
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)
- dfox 9y ago
  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).
  - mschuster91 9y ago
    > 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...
    - dfox 9y ago
      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)
      - dfox 9y ago
        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 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.
- mschuster91 9y ago
  > 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...
  - dogma1138 9y ago
    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.