Slashdot Mirror

← Back to Stories (view on slashdot.org)

Malware Uses Router LEDs To Steal Data From Secure Networks (bleepingcomputer.com)

Posted by BeauHD on from the see-the-light dept.

An anonymous reader writes: Researchers from the Ben-Gurion University of the Negev in Israel have developed malware that when installed on a router or a switch can take control over the device's LEDs and use them to transmit data in a binary format to a nearby attacker, who can capture it using simple video recording equipment. The attack is similar to the LED-it-GO attack developed by the same team, which uses a hard drive's blinking LED to steal data from air-gapped computers. Because routers and switches have many more LEDs than a hard drive, this attack scenario is much more efficient, as it can transmit data at about the same speed, but multiplied by the number of ports/LEDs. Researchers say they were able to steal data by 1000 bits/ per LED, making this the most efficient attack known to date. The attack worked best when coupled with optical sensors, which are capable of sampling LED signals at high rates, enabling data reception at a higher bandwidth than other typical video recording equipment. A video of the attack is available here.

59 of 105 comments (clear)

  1. security of routers by Anonymous Coward · · Score: 5, Insightful

    If your routers are insecure enough that someone can sneak in, reprogram them to flash their LEDs and install sensors to pick up the flashing LEDs you have bigger issues.

    1. Re:security of routers by fuzzyfuzzyfungus · · Score: 1

      Aside from the 'researchers were looking for publication; not a practical exfiltration strategy' issue; I imagine that it would be most useful in a comparatively complex network where you can't necessarily do anything excessively shady looking over the network interfaces without the risk of being caught by the IDS or similar.

      For your basic "router is what turns the cable into wifi, right?" network setup, sure, this is absurdly perverse: you own the router, just use their own internet connection for whatever you want to exfiltrate; and do assorted other nasty things to their traffic, just because you can. If you have a toehold on a device buried in a better policed network, on the other hand, a channel of this sort is ample for sneaking out switch/router configs, crypto keys, and so on; and doesn't generate any unusual patterns on the parts of the network that are likely being monitored for suspicious behavior.

      (Sensors might be trickier: even switch closets not designed with any paranoia in mind tend not to get luxurious window views. Though, you probably wouldn't want to leave any unused fiber runs uncapped; be rather embarrassing if you end up piping the malicious signal out of the secure area for want of a cheapo little rubber insert.)

    2. Re:security of routers by drinkypoo · · Score: 1

      It seems to me like it's most plausibly useful in a context where you have owned the surveillance network and can point a camera at a router. But then you're limited to whatever data transmission rate you can manage given the limitations of the environment. However, what if you used many pieces of equipment in the DC, and many cameras?

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    3. Re:security of routers by msauve · · Score: 1

      "If your routers are insecure enough that someone can sneak in, reprogram them to flash their LEDs and install sensors to pick up the flashing LEDs you have bigger issues."

      And, I'll be glad to sell you a $1000 piece of opaque tape to put over the LEDs to obviate the attack. Maybe I'll write a formal paper about the method, which will then become a /. article.

      --
      "National Security is the chief cause of national insecurity." - Celine's First Law
    4. Re:security of routers by Miamicanes · · Score: 1

      I can think of a far more efficient way to exfiltrate data from a network: write a program to generate 2D color bitmaps and display them onscreen to photograph them.

      If you're using remote desktop and can do screen captures, you can literally pack up to 24 bits into every single pixel on the screen.

      Worst-case, with a high-end Android phone's ~12 megapixel camera photographing the screen, you could pack at least 8 bits into every 4x4 pixel square (2x2 of color, separated from adjacent data blocks by 2 pixels of black... 4 bits of green, 2 bits of red and blue) and export about 128k bytes per 1920x1080 screen (giving you 470 * 270 4x4 blocks). If you could hold the camera steady enough and capture 2160p30 (for a bit of oversampling headroom), that would allow you to capture a little under 4 megabytes per second.

      Or if they can make voice calls, I think even JAVASCRIPT is now fast enough to bitbang Bell103 FSK (a/k/a "300 baud acoustically-coupled modem"). And if they want to be really clever & can install something better, they could use phase modulation to hide it in an innocent-sounding song playing during their phone conversation.

      Moral of the story: the most robust network airgap is still potentially useless against a trusted individual with physical access. A single layer of technical security will get you only *so* far... at some point, the biggest single factor in keeping sensitive data secure is making sure that anyone with physical access to it is, in fact, trustworthy... and treat them well, so they won't have any reason to stop being trustworthy.

    5. Re:security of routers by hawguy · · Score: 5, Interesting

      If your routers are insecure enough that someone can sneak in, reprogram them to flash their LEDs and install sensors to pick up the flashing LEDs you have bigger issues.

      Lots of companies colocate in "secure" datacenters where their equipment cages are walled off by nothing more than chain link fences with equipment stacked in bare racks, plainly visible to anyone walking by.

      If you can find a software vulnerability and hack into one of their switches/routers, you can use this technique to extract data from their network without tripping any IDS sensors -- all you need to do is rent a neighboring cage and point a camera at the switches.

      The company across the courtyard from us has a bit stack of network switches facing the window. Same problem - get someone to infect their network from within (through, say, a compromised USB key) and you can send data all day long over the lights without anyone noticing any unusual outbound traffic.

    6. Re: security of routers by mSparks43 · · Score: 1

      dont need to sneak in.

      just install it at the factory or just before its delivered and hack the cameras securing the datacenter.

    7. Re: security of routers by mSparks43 · · Score: 1

      or better still.
      hack the website providing firmware updates.

    8. Re:security of routers by chispito · · Score: 1

      If you can find a software vulnerability and hack into one of their switches/routers, you can use this technique to extract data from their network without tripping any IDS sensors

      I'm curious to learn about this IDS that can catch traffic from compromised network hardware but can't catch the act of compromising network hardware. This is an impractical POC for anything but the most outlandish spy movies. There are far easier ways to exfiltrate data.

      --
      The Daddy casts sleep on the Baby. The Baby resists!
    9. Re:security of routers by tlhIngan · · Score: 1

      I'm curious to learn about this IDS that can catch traffic from compromised network hardware but can't catch the act of compromising network hardware. This is an impractical POC for anything but the most outlandish spy movies. There are far easier ways to exfiltrate data.

      If you have a lot of time, you can easily blink a network LED without most IDSes detecting it by simply bringing the link up and down. It's a slow process since it takes several seconds for the LED to react, but if you have enough machines that can be controlled together, you can bring multiple linkx up and down and use that as a rudimentary signalling mechanism. Most IDS won't be able to detect this since it's a common enough event.

      Heck, if you need data from a workstation and the switch LED is visible externally this is a great way to blink LEDs remotely. Doesn't matter how deep inside the building a workstation is if the switch its attached to can be seen through a window, for example.

    10. Re:security of routers by chispito · · Score: 1

      If you have a lot of time, you can easily blink a network LED without most IDSes detecting it by simply bringing the link up and down.

      I can't think of anything noisier and more disruptive than one or more NICs constantly going up and down.

      --
      The Daddy casts sleep on the Baby. The Baby resists!
    11. Re:security of routers by hawguy · · Score: 1

      If you can find a software vulnerability and hack into one of their switches/routers, you can use this technique to extract data from their network without tripping any IDS sensors

      I'm curious to learn about this IDS that can catch traffic from compromised network hardware but can't catch the act of compromising network hardware. This is an impractical POC for anything but the most outlandish spy movies. There are far easier ways to exfiltrate data.

      "Hey guys, we just had a huge DoS traffic flood - overwhelmed our IDS for a few minutes, but everything looks good now. Looks like it made one of our core switches reboot. Weird. But everything is back online now, IDS isn't reporting anything unusual so at least we can be certain there's no data leak!"

    12. Re:security of routers by blindseer · · Score: 1

      There are far easier ways to exfiltrate data.

      You mean like print out secured documents, fold them up, stick them in a pocket, and walk out the door? It sounds like that is what Reality Winner did.

      --
      I am armed because I am free. I am free because I am armed.
  2. Re:good grief by Anonymous Coward · · Score: 2, Interesting

    There's a piece of electrical tape over my router LEDs so I can sleep...

  3. 1000 bits/ per LED? by michael.karl.coleman · · Score: 2

    Is that like making the Kessel Run in 12 parsecs?

    1. Re:1000 bits/ per LED? by by+(1706743) · · Score: 1

      And how is it even pronounced? "One thousand bits per per LED"? "One thousand bits over per LED"? "One thousand bits-slash per LED"?

    2. Re:1000 bits/ per LED? by CaptainDork · · Score: 1

      Parsec is distance.

      --
      It little behooves the best of us to comment on the rest of us.
    3. Re:1000 bits/ per LED? by Anonymous Coward · · Score: 1

      The 1000 bps was based on having an high-speed optical sensor. A regular LED can just manage turning off and on and communicating at 1000 bps to an optical sensor.

      Against a camera, the number will be somewhere between 30 bps and 240 bps. The issue is that the camera has a shutter speed. (It might not have a physical shutter, but it will have the electronic equivalent.) Often this results in a series of 1(ms) stills taken at 30 or 60 frames per second. Even with a PWM variable brightness algorithm, for the 1 ms the electronic shutter is open, the LED will be off or on. With clever programming, you might get some kind of in-between state. However, you are not getting 8-bits of in-between states.

      You better know exactly what the data is that you are after ... because blinking a regular LED will result in a very slow data path.

    4. Re:1000 bits/ per LED? by Megol · · Score: 1

      Depends on how the LED is connected to the rest of the hardware. If the LED is connected to a GPIO pin on a microcontroller 1Mbps+ is easy to do (depends on the LED color and construction AFAIK).

  4. 1000 bits/ per LED by Anonymous Coward · · Score: 1

    Come on editors.
    Assuming video recording at 30/frames a second, each bit requiring at least 2 frames I'm guessing it's around 1000 bits/minute.

  5. Re:good grief by CaptainDork · · Score: 1

    Or some duct tape.

    --
    It little behooves the best of us to comment on the rest of us.
  6. inb4 by poity · · Score: 1

    entire room wrapped in tape

    --
    your thin skin doesn't make me a troll
  7. Secure network? by Anonymous Coward · · Score: 1

    Wireless by definition makes the network insecure...

  8. Almost old school by fuzzyfuzzyfungus · · Score: 5, Informative

    This looks like a contemporary attempt to revive a classic.

    Back in the Before Times; you could get serial modems that did DES(maybe 3DES? my memory grows fuzzy) in hardware, to allow systems without built in line security measures to be run over phone lines(ATMs, that sort of thing). It was cleartext on the RS-232 link between the device and the modem; but that was supposed to be physically secured inside the chassis; then encrypted between the modems on each end of the line; and decrypted at the far end, presumably in a secure location.

    Some designs, whether out of lack of imagination, incompetence, or sneaky malice, had LEDs that were more or less directly tied to the cleartext serial input; and the LEDs and drive circuitry were quite capable of blinking at the rates of at least the slower serial links; so you could read the unencrypted serial traffic right off the fancy 'secure' modem's blinkenlights(at a fair distance, with magnification).

    This study tested ethernet gear as well; but found that(if unmodified) it was of relatively limited use: data rates were far too high for LEDs to be driven directly by high/low values in the data stream; and instead blinked in ways only indirectly associated with traffic activity, mostly for diagnostic convenience.

    This new one requires that the system be maliciously modified, so it lacks the charm of the original; but takes advantage of the fact that indicator LEDs can still blink pretty fast(and some are GPIO controlled) so they can still be shoved into transmitting information; but now you have to handle that yourself, rather than having the vendor do it for you.

    1. Re:Almost old school by fuzzyfuzzyfungus · · Score: 1

      Some really fancy cameras may be good enough; but the latter approach is the more practical one: if all you care about is one LED's flickering, you are basically just building an optocoupler with an unfortunately suboptimal gap between the transmitter and receiver. Suitable optics, stabilized mount, filtering noise from ambient light sources, etc. are all potential problems; but photodetectors with ample bandwidth are very much available.

    2. Re: Almost old school by fuzzyfuzzyfungus · · Score: 1

      Which is why I didn't describe it as one; though the case of grabbing plaintext that is leaked before link encryption because of a design flaw is pretty close to 'attack'; and requires no modification of the target system, which is handy.

  9. Bits per LEDsecond by cfalcon · · Score: 1

    I think "bits per LEDsecond " is the funniest unit I've seen in a long damned time. "This exploit grabs data at 1000 bits/LED*s"

  10. IrDA by Dan+East · · Score: 4, Informative

    What do you think IrDA is (was)? Same thing using infrared LEDs is all. It supported up to 115.2 kbit/s, and that's just on one "channel" (LED). Back in 2004 I bitbanged IrDA with a micro-controller in a homebrew PS1 controller adapter that allowed me to use the controller with a Pocket PC. It was one-way communication, because the controller just needed to communicate button presses to the Pocket PC. It worked quite well. Anyway, assuming there is a relatively low-level access for toggling the LEDs on or off on a [insert device name here], such a method of transmitting data is patently obvious...
    The "scary" thing is that communications of this sort are far beyond the refresh rate of the human eye, and so the end result is that the LED simply looks about half the normal brightness and does not appear to pulsate or anything.

    --
    Better known as 318230.
    1. Re:IrDA by nounderscores · · Score: 1

      Cryptonomicon (1999) by Neal Stephenson had a scene where a guy was being asked to crunch data (on pain of death) to get the location of buried treasure, and so had to first make a program that obfuscated his screen output to display a bogus location and to blink out the real coordinates to his capslock light in Morse code.

      Ten years later, lilspikey made it real.

      http://www.psychicorigami.com/...

    2. Re:IrDA by Megol · · Score: 1

      Was going to post that IrDA supported 4Mbps and wondered if I remembered that correctly -> wikipedia check -> realize that IrDA actually supports up to 1Gbps!

      Of course one can't bit-bang 4Mbps+ IrDA... Perhaps on those XMOS processors, they are designed for fast bit-banging.

    3. Re:IrDA by JD-1027 · · Score: 1

      1999-2000 I had two iMacs linked via built in IrDA networking in my dorm room with my roommate. All out of the box stuff built into the iMac.

      It was this model:
      https://en.wikipedia.org/wiki/...

      Ah... old simple fun tech.

  11. So if I get physical access... by StevenMaurer · · Score: 4, Insightful

    ...to be able to install my own firmware on a router that is on a secure network, then I can access the data on the secure network it is attached to?

    I would imagine if you could do all of that that, and be nearby at the time as well, then you could access the secure network by other means.

    And all that assumes that data going across the secure network isn't all encrypted, which it typically is.

    1. Re:So if I get physical access... by AHuxley · · Score: 1

      It depends on the site. Tell the workers some nice fiction. Enter a remote site building at night with a door held open by a shift change, ask a cleaner for access due to a lost ID card once trusted in the "secure" building. Use the elevator to get to a floor thats "locked" to most people.
      The network might be the same as in the very, always secure main building in a city, state or nation.
      The network could be very secure but some on site hardware in an office on the same network could be trusted due to all the advanced physical building security.
      The building is secure at the front street, the elevator is locked per floor, the office door is locked.
      The slower led network might just get crypto out over time to be collected later again in person.
      The well protected network was never altered. Nothing new was logged. The needed data is collected in person. A CCTV review shows a person wondering around talking to people in a secure area. Nobody called security so that person was allowed to be in the area as they passed the front door security..

      --
      Domestic spying is now "Benign Information Gathering"
    2. Re:So if I get physical access... by gl4ss · · Score: 1

      look, its something that doesnt even need a paper. you can explain the concept in 1 sentence so that a programmer knows that it can be done(But is stupid).

      --
      world was created 5 seconds before this post as it is.
  12. Upgrade your router... by Anonymous Coward · · Score: 1

    Upgrade your router...install systemd. It'll fuck it up so bad nothing will work.

      * INFO: Running install_ubuntu_check_services()
      * INFO: Running install_ubuntu_restart_daemons()
    Job for salt-minion.service failed because a configured resource limit was exceeded. See "systemctl status salt-minion.service" and "journalctl -xe" for details.
    start: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
      * ERROR: No init.d support for salt-minion was found
      * ERROR: Failed to run install_ubuntu_restart_daemons()!!!
    root@r1:/etc/salt#

    Jun 07 02:50:07 r1 systemd[1]: salt-minion.service: Failed to run 'start' task: No such file or directory
    Jun 07 02:50:07 r1 systemd[1]: Failed to start The Salt Minion daemon.
    Jun 07 02:50:07 r1 systemd[1]: salt-minion.service: Failed with result 'resources'.
    Jun 07 02:50:51 r1 systemd[1]: [/lib/systemd/system/salt-minion.service:11] Failed to parse service restart specifier, ignoring: $RESTART
    Jun 07 02:50:54 r1 systemd[1]: [/lib/systemd/system/salt-minion.service:11] Failed to parse service restart specifier, ignoring: $RESTART
    Jun 07 02:50:54 r1 systemd[1]: Stopped The Salt Minion daemon.
    Jun 07 02:50:54 r1 systemd[1]: salt-minion.service: Failed to load environment files: No such file or directory
    Jun 07 02:50:54 r1 systemd[1]: salt-minion.service: Failed to run 'start' task: No such file or directory
    Jun 07 02:50:54 r1 systemd[1]: Failed to start The Salt Minion daemon.
    Jun 07 02:50:54 r1 systemd[1]: salt-minion.service: Failed with result 'resources'.
    root@r1:/etc/salt#

  13. Deja vu by ShaunC · · Score: 5, Informative

    LED Lights: Friend or Foe? was posted here more than 15 years ago. Everything old is new again (except me, I guess).

    --
    Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
    1. Re:Deja vu by Lawrence_Bird · · Score: 1

      At least as interesting is the 85% decline in comments. Has Netcraft declared /. dead yet?

  14. Tom Cruise by Frosty+Piss · · Score: 4, Funny

    The only realistic application of this "hack" is in a bad Tom Cruise movie.

    --
    If you want news from today, you have to come back tomorrow.
    1. Re:Tom Cruise by Lennie · · Score: 1

      Forget about the routers, etc. Actually, IoT lighting systems are perfect for real world attacks for getting data out of secure facilities.

      --
      New things are always on the horizon
  15. I love it by ArylAkamov · · Score: 1

    Impractical but creative, I can dig it.

  16. Not an "attack" by Anonymous Coward · · Score: 2, Insightful

    It's not an attack. It's a sidechannel communication mechanism, and the optical sensors needed to pick it up are going to be pretty damn obvious sitting on the floor if a datacenter.

  17. Nice movie plot but.... by pcjunky · · Score: 2

    While this might be used as a plot device on Mr. Robot, I don't expect much to come of this.

  18. Re:Jesus h Christ by hawguy · · Score: 1

    So, you own a router enough to send data via its lights to some other dude who can interpret your signals. Why the fuck don't u just tap it at that point? This is an overly complicated exfiltration method that has zero chance of ever mattering. I'm glad some money somewhere got spent for this idiocy

    Because the owner of the data is watching for unusual network activity, but not for unusual blinky lights.

  19. Re:good grief by gl4ss · · Score: 1

    in that case you would just lose some transmit speed. ..this is fucking stupid. it's a custom firmware for a router that sends stuff out over the LED. it's fucking stupid and COULD HAVE BEEN FUCKING MADE 17 YEARS AGO.

    like, it doesn't prove anything. it just proves that you could do something that you already knew that could be done.

    --
    world was created 5 seconds before this post as it is.
  20. fucking stupid by gravewax · · Score: 1

    If you are in a position where you can even see the enclosures let alone the Router LED's I have more fucking problems than this attack vector. seriously is their any real Datacentre that would have any exposure to this ANYWHERE?

    1. Re:fucking stupid by avandesande · · Score: 1

      Maybe the data centers own security cameras?

      --
      love is just extroverted narcissism
  21. Re:good grief by K.+S.+Kyosuke · · Score: 1

    I don't see how using Perl helps here?

    --
    Ezekiel 23:20
  22. so.. by CptLoRes · · Score: 1

    If you have rooted the router and is close enough for optical transfer (aka irDA), would it then not be easier to just plug in network cable?

    1. Re:so.. by Zero__Kelvin · · Score: 1

      Not if you want to sound like you came up with a really new and cool hacking technique to anyone without a clue.

      --
      Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  23. Re:good grief by geekmux · · Score: 1

    hardware randomize the time the LEDs stay on... Either a LFSR or a noise source hooked up to a comparator. That'll slow things down tremendously.

    Or we could just stop using LEDs for every damn indicator on devices like this.

    This is why I own electrical tape.

  24. Re:good grief by sabbede · · Score: 1

    What about a capacitor? Wouldn't that slow down the LED response time enough to make high frequency flashes impossible? I'm not an electrical engineer, could be totally wrong.

  25. Re: good grief by guruevi · · Score: 1

    Depends on the frequency of the signal and size of the capacitor and probably needs a resistor too but it would also add size and cost. You'd still be able to do some data exchange, you'd just have to tune it to the speed of the RC network.

    --
    Custom electronics and digital signage for your business: www.evcircuits.com
  26. Re:"1000 bits/ per LED" - LOL by srpape · · Score: 1

    Same thought, what kind of rate is that?

  27. Re:good grief by unixcorn · · Score: 2

    Yep, just like the check engine light in the dashboard of my car. Problem solved!

  28. Re:good grief by RockDoctor · · Score: 1
    That's a standard piece of signal conditioning - I've used it a lot over the years for example to "de-bounce" the signal coming from mechanical switches on pumps. You could use it the other way, to decrease the frequency at which a lamp (LED, whatever) can flicker.

    Yeah, you need to add a resistor and a capacitor to the data line, and you'd only decrease, not prevent the flickering which carries the signal. So, small benefit. Personally, I'd put the black boxes into an opaque cabinet. Problem eliminated. If the network stops responding ... then that's when you call the IT department, who have the keys to the cabinet. Which would solve some other issues too. For example, you want to write some data to a USB drive? Fine! The USB port for your floor is in the cabinet, call IT. Want to play your favourite CD? Sure! The CD drive for your floor is in the cabinet, call IT.

    --
    Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"
  29. Re: good grief by sabbede · · Score: 1
    Well, if the expected response time for the LED (first emission of light to last) is 100ms, but you slow that down to 1s with a capacitor (and or resistor or whatever), then instead of an attacker sending 10 bits/sec, they send none.

    The downside being that it can't be done by the manufacturer unless they use low-spec parts so there is significant variation in response time between individual devices.

  30. Re:good grief by sabbede · · Score: 1
    Ah-ha! You just taught me the right term for what we're talking about! Signal conditioning.

    Soldering components into everything with an LED is not something I'd want to do, but if manufacturers put in caps with wide variations in capacitance - instead of buying parts that deviate from the expected values by .001%, they vary by 10% - then the frequency of the flicker would be too unpredictable to be exploited.

  31. Re: good grief by guruevi · · Score: 1

    Then send 1 bit per second. Across the entire router, this could still be easily 10-20bits/s and even 1 bit/s is plenty to extract information like encryption keys. As long as I can modulate the behavior of the LED's, I can send data. The reason I can modulate the LED's in the first place is so the system doesn't need the extra circuitry to detect packets moving on the network, just wire it directly to the CPU and let it handle the blinking.

    You can avoid these attacks by directly attaching the LED via a circuit to the data line and make it blink based on packets moving across the network, but that costs a few extra resistors, capacitors and perhaps even a chip (or not having LED's at all but there is a reason for them)

    --
    Custom electronics and digital signage for your business: www.evcircuits.com
  32. Re: good grief by sabbede · · Score: 1

    My point is that an attacker wouldn't know that the response time of the LED has been changed. They told it to blink 10 times in one second, but instead it just stayed on the entire time. They tell it to flash once, and it's not enough to actually light the LED. They'd have to carefully and manually analyse the response to their commands to work out how to get around the delay. If, of course, they figure out that's where their problem is instead of thinking the hack failed, and they don't spend so much time on it that they get caught.