Source Link Privacy.

Privacy test result

https://themarkup.org/blacklight?url=https%3A%2F%2Fwww.tarlogic.com%2Fnews%2Fbackdoor-esp32-chip-infect-ot-devices%2F&device=mobile&location=us-ca&force=false

Tarlogic Security has detected a backdoor in the ESP32, a microcontroller that enables WiFi and Bluetooth connection and is present in millions of mass-market IoT devices. Exploitation of this backdoor would allow hostile actors to conduct impersonation attacks and permanently infect sensitive devices such as mobile phones, computers, smart locks or medical equipment by bypassing code audit controls.

Update: The ESP32 “backdoor” that wasn’t.

  • priapus@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    39
    arrow-down
    1
    ·
    edit-2
    25 days ago

    This isn’t a backdoor. Just a company trying to make a name for themselves by sensationalizing a much smaller discovery.

      • Rexios@lemm.ee
        link
        fedilink
        English
        arrow-up
        14
        arrow-down
        2
        ·
        26 days ago

        Idk maybe specify that it was determined to not be a backdoor. Right now it reads as anti-china fear mongering.

        • Oisteink@feddit.nl
          link
          fedilink
          English
          arrow-up
          4
          ·
          26 days ago

          Could be propaganda as well - why not scare the monkeys with the bad Chinese? Without ESPs the market is so much easier to control.

          Note:I use both the ES8266ex and different ESP32s in my projects.

        • fuamerikkka@lemm.ee
          link
          fedilink
          English
          arrow-up
          3
          ·
          25 days ago

          Thank you, I keep getting down voted because I said the same, but obviously other get it. Appreciate you and the sanity check!

  • JcbAzPx@lemmy.world
    link
    fedilink
    English
    arrow-up
    14
    arrow-down
    2
    ·
    26 days ago

    The rebuttal wasn’t as comforting as some are making it out to be. They seem to be more interested in the semantics of it not being a backdoor tied to a specific product, which appears to be true.

    Rather it is a potential for vulnerability that exists in all wireless implementation, which seems to me to be a bigger issue.

    • trashgirlfriend@lemmy.world
      link
      fedilink
      English
      arrow-up
      3
      ·
      25 days ago

      It’s a vulnerability where an attacker already needs code execution on the device/physical access.

      If you have that you’re already compromised no matter what.

    • jj4211@lemmy.world
      link
      fedilink
      English
      arrow-up
      4
      arrow-down
      2
      ·
      25 days ago

      The issue is where the undocumented commands are. They aren’t just allowing any old external person to send payloads to this.

      It’s kind of like noticing that someone unexpectedly hid a spare key next to the door… On the inside of the house. Like, sure, maybe the owner would have like to know about that key, but since you have to be inside the house to get to it, it doesn’t really make a difference.

    • Entropywins@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      25 days ago

      I was reading someone else’s explanation and they said it’s the equivalent of every computer possibly having a backdoor because there is code in a computer that a bad actor can use. There are extra commands that could possibly be used for a backdoor if a malicious actor found a way to use those bits of code. It’s much less oh here is a security vulnerability that is being used and more of a if a robber breaks into our house which is possible they will rob us situation.

  • thickertoofan@lemm.ee
    link
    fedilink
    English
    arrow-up
    11
    ·
    25 days ago

    welp, TL;DR from comments says its fear mongering at best, physical access required right?

      • Zron@lemmy.world
        link
        fedilink
        English
        arrow-up
        3
        ·
        25 days ago

        It allows the takeover of devices!

        How?

        By already having taken over the device.

        Wtf is this reporting

  • ycnz@lemmy.nz
    link
    fedilink
    English
    arrow-up
    9
    ·
    27 days ago

    I hate it when an attacker who already has root access to my device gets sightly more access to the firmware. Definitely spin up a website and a logo, maybe a post in Bloomberg.

  • Ebby@lemmy.ssba.com
    link
    fedilink
    English
    arrow-up
    8
    ·
    27 days ago

    Well… Shit.

    There are so, so, so, many ESP32’s in not just my house, but practically everyone I know.

    There outta be fines for this BS.

    • cogman@lemmy.world
      link
      fedilink
      English
      arrow-up
      10
      ·
      27 days ago

      You’re fine. This isn’t something that can be exploited over wifi. You literally need physical access to the device to exploit it as it’s commands over USB that allow flashing the chip.

      This is a security firm making everything sound scary because they want you to buy their testing device.

      • tehmics@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        27 days ago

        In that case, how long til some open source project uses it to make a custom firmware to bypass the manufacturer bs and integrate my cheap IoTs seamlessly into Home assistant?

      • Ebby@lemmy.ssba.com
        link
        fedilink
        English
        arrow-up
        0
        ·
        27 days ago

        I do have a few outside. Probably not the best security-wise. Haha. Those are the first to get patched when one comes out.

        • cogman@lemmy.world
          link
          fedilink
          English
          arrow-up
          0
          ·
          27 days ago

          Security wise, unless you are being specifically targeted by someone, you are almost certainly fine. And if you are being specifically targeted, I think someone hacking your ESPs is the least of your worries. A malicious attacker that knows your physical location can do a lot more scary things than just spying through ESPs.

          • Treczoks@lemmy.world
            link
            fedilink
            English
            arrow-up
            0
            ·
            27 days ago

            Just wait until a jester creates a software that sends an erase flash backdoor command to any BT device it sees.

            • oldfart@lemm.ee
              link
              fedilink
              English
              arrow-up
              1
              ·
              edit-2
              26 days ago

              And runs with an USB cable flashing other peoples ESPs to ruin everyone’s day

        • cogman@lemmy.world
          link
          fedilink
          English
          arrow-up
          6
          ·
          27 days ago

          I just re-read the article and yes, you still need physical access.

          The exploit is one that bypasses OS protections to writing to the firmware. In otherwords, you need to get the device to run a malicious piece of code or exploit a vulnerability in already running code that also interacts with the bluetooth stack.

          The exploit, explicitly, is not one that can be carried out with a drive-by Bluetooth connection. You also need faulty software running on the device.

          • Blue_Morpho@lemmy.world
            link
            fedilink
            English
            arrow-up
            0
            ·
            27 days ago

            “Depending on how Bluetooth stacks handle HCI commands on the device, remote exploitation of the backdoor might be possible via malicious firmware or rogue Bluetooth connections.”

            I of course don’t know details but I’m basing my post on that sentence. “Backdoor may be possible via … rogue Bluetooth connections.”

            • haleywm@startrek.website
              link
              fedilink
              English
              arrow-up
              8
              ·
              27 days ago

              Looking at the article, the exploit requires you to be able to send arbitrary data to the Bluetooth device over a physical connection. This means that a properly secure application will be protected from drive by connections, but if the application has an exploit that either lets an attacker write arbitrary values to the Bluetooth controller, or more likely contains a general arbitrary code execution exploit, then you could use this to rewrite values to the chip that would let you “persist” certain changes to the Bluetooth chip that would be difficult to notice.

              I would consider this a moderate concern, as this will definitely increase your options if you’re looking to be able to make an attack that targets a specific device and this gives you a few additional persistence options, but any attack would have to be designed for a particular program running connected to a Bluetooth chip.

              A more likely concern in my opinion would be the possibility of a supply chain attack, where someone compromises a Bluetooth chip that they know will be used to construct a particular part.

              I don’t think that it’s super likely that either of these will affect the average person, only corporations and governments where espionage is an actual threat, as if you can find a Bluetooth IOT device that you want to mess with, like a Bluetooth enabled door lock, then you’re more likely to be able to find an arbitrary code execution attack which causes it to unlock immediately. Being able to spoof a different Bluetooth device isn’t likely to give you that big of an advantage when you’re working with a device that was already vulnerable for a different reason.

              • ByteJunk@lemmy.world
                link
                fedilink
                English
                arrow-up
                0
                ·
                27 days ago

                Thank you for the analysis, very insightful!

                Do you reckon this is more of an oversight or bug in the BT stack, or a deliberately places backdoor as the title seems to suggest?

                • haleywm@startrek.website
                  link
                  fedilink
                  English
                  arrow-up
                  1
                  ·
                  26 days ago

                  From what I can tell from looking at it, this seems like something deliberately left in, but not for malicious reasons. The op codes referenced simply give access to lower level parts of the boards programming. ESP32’s are already a user programmable board, a valid use case is to run your entire application on one if the code being run is lightweight enough to not interfere with the Bluetooth code. Either during development, or during runtime, these undocumented codes are likely used to run specific commands on the board.

                  The actual issue as far as I can tell, since normally it’s valid usage to rewrite the board over USB, is that ESP32 boards also offer ways to encrypt device code, and require it to be signed, and you are presumably able to mess with this in order to dump code that was expected to be securely encrypted, and overwrite code on devices that was intended to require signing. (https://docs.espressif.com/projects/esp-idf/en/latest/esp32s3/security/secure-boot-v2.html#background)

                  Proving what someone was thinking when they programmed something is extremely difficult unless you can find written evidence of someone specifically saying if they did something or not, but this all seems like a legitimate minor exploit in a device that wasn’t built by, or intended for, people who are working against highly resourced attackers. This is still not a concern for normal people who aren’t concerned about being attacked by spies, and if a nation state wanted to hide a vulnerability in something then there are far easier paths to take than one that only works if you can steal a microcontroller so you can connect to it over USB.

        • IllNess@infosec.pub
          link
          fedilink
          English
          arrow-up
          1
          ·
          27 days ago

          Depending on how Bluetooth stacks handle HCI commands on the device, remote exploitation of the backdoor might be possible via malicious firmware or rogue Bluetooth connections.

          I really wish these articles just tell us what these scenarios are. I understand companies need publicity or need to sell software but if it isn’t replicatable and the article says “might be possible” it kind of sounds like a secuity sales pitch.

          This is especially the case if an attacker already has root access, planted malware, or pushed a malicious update on the device that opens up low-level access.

          This part basically sounds more like a software issue where the attacker has a way in already. The system is already vulernable at this point before using the exploit found.

          I don’t think there’s enough information out yet.

          It is very interesting though.

      • Treczoks@lemmy.world
        link
        fedilink
        English
        arrow-up
        0
        arrow-down
        3
        ·
        27 days ago

        Wrong. Read the analysis. It is a BT vulnerability. One can probably design a cheap attack system that just sends a erase flash command to any BT device in reach, instantly bricking every BT enabled ESP32 device.

        • cogman@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          27 days ago

          Just reread it and no, it’s not a BT vulnerability. The “erase flash” command is something that has to be done by software running outside the BT stack. You can even see that inside the slides. The UsbBluetooth software is connected to the device with the flawed bluetooth chipset.

          The vulnerability is that if you have this chipset and compromised software, someone can flash the chipset with compromised flash. They even say that it’s not an easy attack to pull off in the article.

          In general, though, physical access to the device’s USB or UART interface would be far riskier and a more realistic attack scenario.

          In otherwords, the attack is something that can only be pulled off if there’s also a security vulnerability within other parts of the hardware stack.

  • notanapple@lemm.ee
    link
    fedilink
    English
    arrow-up
    8
    ·
    27 days ago

    We really should be pushing for fully open source stack (firmware, os) in all iot devices. They are not very complicated so this should be entirely possible. Probably will need a EU law though.

    • secret300@lemmy.sdf.org
      link
      fedilink
      English
      arrow-up
      4
      ·
      27 days ago

      I 100% believe firmware should be open source no question about it. There’s so many devices out there especially phones and iot devices that just become e-waste because you can’t do anything with it once it’s not supported if it was open source and documented in some way then it could be used. I have like five cheap phones that I got because they were so cheap but once they lost support they’ve become completely useless even though they still work.

      • Malfeasant@lemm.ee
        link
        fedilink
        English
        arrow-up
        1
        ·
        26 days ago

        But then big companies wouldn’t be able to keep milking the consumer via planned obsolescence. Won’t somebody think of the shareholders?

    • oldfart@lemm.ee
      link
      fedilink
      English
      arrow-up
      3
      ·
      26 days ago

      Open source stack will not prevent this. It’s not even a backdoor, it’s functionality that these researches think should be hidden from programmers for whatever reason.

      Open source devices would have this functionality readily available for programmers. Look at rtl-sdr, using the words of these researches, it has a “backdoor” where a TV dongle may be used to listen to garage key fobs gasp everyone panic now!

  • Oisteink@feddit.nl
    link
    fedilink
    English
    arrow-up
    4
    ·
    27 days ago

    Too much fanfare and too little real info shared to be of any value. Sounds more like an ad than infosec

    • priapus@sh.itjust.works
      link
      fedilink
      English
      arrow-up
      1
      ·
      26 days ago

      Exactly what it is. A gross example of company trying to get their name out their by sensationalizing their findings.

  • Thrawne@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    26 days ago

    Fukin dmnit! I just spent the last several months fine tuning a PCB design supporting this platform. I have , what i believe to be my last iteration, being sent to fab now. I have to look i to this. My solution isnt using bluetooth, so i dont know if im vulnerable.

  • Jerkface (any/all)@lemmy.ca
    link
    fedilink
    English
    arrow-up
    4
    ·
    26 days ago

    Weird that they removed the reference to ESP32, one of the most common and widely known microcontrollers, from the headline.

      • Jhuskindle@lemmy.world
        link
        fedilink
        English
        arrow-up
        1
        ·
        24 days ago

        Idk what they can do with my data from my many Bluetooth devices so they are welcome to come through my Bluetooth devices 😂 and I’d be fine with being a Chinese citizen if that’s where this leads, they have healthcare and social housing.

  • mystik@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    27 days ago

    I have a bunch of ESP32’s that … I can update and replace the firmware on, if i reset it the right way with a usb cable. the web site doesn’t explain it any way how this is any worse than that…?

  • Dasus@lemmy.world
    link
    fedilink
    English
    arrow-up
    0
    ·
    26 days ago

    Haha. I wear cheap Chinese bluetooth literally on my skull like 95% of the time, web when sleeping.

    Hope they enjoy my thoughts.