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.

105 comments

  1. good grief by Anonymous Coward · · Score: 0

    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.

    1. Re:good grief by Anonymous Coward · · Score: 2, Interesting

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

    2. 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.
    3. Re:good grief by Anonymous Coward · · Score: 0

      Yes. That's why I said it would slow it down. Can you read, or are you only interested in showing off your borderline personality disorder outbursts?

    4. Re:good grief by Anonymous Coward · · Score: 0

      BACON AND EGGS, DEAR!
       
      For CRYIN' OUT LOUD, I said REVERSE BIAS THAT DIODE and AMPLIFY it and put it in the ADC, you STUPID IDIOT!!!

    5. 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.
    6. Re:good grief by K.+S.+Kyosuke · · Score: 1

      I don't see how using Perl helps here?

      --
      Ezekiel 23:20
    7. 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.

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

    9. 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
    10. Re:good grief by unixcorn · · Score: 2

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

    11. 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"
    12. 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.

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

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

  2. That's Nothing: I hacked a Tesla to Transmit... by Anonymous Coward · · Score: 0

    voice conversations in the cabin via Morse code in the taillights!.

  3. Didn't know I was so security-focused? =) by Anonymous Coward · · Score: 0

    Most router LEDs are so obnoxiously bright I have purchased filter tape to make them only visible nearly point-blank.

    Sometimes you have to use 2x strips to dull the room-brightening glow.

    http://lightdims.com/store.htm

  4. Obvious improvement would be PMT by Anonymous Coward · · Score: 0

    A photomultiplier tube could be used to detect higher bandwidth.. ok, no credit needed. Go get your new world record.

  5. 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 Anonymous Coward · · Score: 0

      Thanks NSA.

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

    3. 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.'"
    4. 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
    5. Re: security of routers by Anonymous Coward · · Score: 0

      Or just don't install optical sensors in your gear and be immune from the attack.

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

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

    8. Re:security of routers by Anonymous Coward · · Score: 0

      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.

      Please do. Your comment made me consider that while "opaque" tape typically blocks visible light it would be interesting to know if the typical router LED emits non-visible wavelengths that might pass through.
      If nothing else there will probably be some IR.

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

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

      or better still.
      hack the website providing firmware updates.

    11. Re:security of routers by Anonymous Coward · · Score: 0

      If your routers are insecure enough that someone can sneak in,

      When you purchase a router, do you checksum the firmware so you know that I didn't mess with it in the shop, or paid the delivery guy to replace it with my special one? I do not need to sneak into your well-guarded premises to compromise your network equipment. Note that downloading a manufacturer's firmware is not enough - the flashing is done by the existing firmware which may be doctored to not do what you think.

      As for sensing the LEDS: You may be safe, with your router locked in an opaque closet. Some uses a glass door so they will notice a fault light (or power-off) quickly. Some have an office switch visible in their landscape. I might be able to see the LEDs through a window - I can then use a telephoto lens/telescope from another building. And some rent space in a data center - I can rent a rack that see the compromized LED (or its reflection). All worth it if I can collect enough credentials to do a bank transaction in someone elses name . . .

    12. Re:security of routers by Anonymous Coward · · Score: 0

      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.

      That would have to be one of those nets where you can't do https then. Even office environments with decent network security tend to allow using the web for looking up stuff - businesses have a use for that. So https somewhere, and leak. If they proxy https, use steganography to hide the leak in blog/facebook postings about football/fishing/home brewing. . .

    13. Re:security of routers by Anonymous Coward · · Score: 0

      Out of curiosity: you could (presumably still can) directly control the caps lock led on the keyboard with relative ease. Wouldn't that be an easier target for this sort of attack than router firmware?

    14. Re:security of routers by Anonymous Coward · · Score: 0

      Most leds have a very narrow spectrum, around 20 to 30 nanometers wide. White leds are about the only difference, they use a very bright narrowband blue pump diode and a fosphor that spread the energy to the red and green part. Near-IR emissions of leds are almost undetectable (unless it is an IR led, obviously). There will be thermal IR radiation due to the temperature of the component, but that would be a very slow channel and a very obvious detector.

      That said, black tape is not a very good attenuator. If you put a small photomultiplier in front of your detector you will still likely pick up a very good signal. Some of these sensors can measure individual photons...

    15. 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!
    16. 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.

    17. 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!
    18. Re:security of routers by Anonymous Coward · · Score: 0

      My routers have LEDs on the top side of devices. Camera must be placed on the ceiling.

    19. 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!"

    20. 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.
    21. Re:security of routers by Anonymous Coward · · Score: 0

      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.

      The routers are connected to the network and may be susceptible to some manner of virus. Then if you put a rack unit you equipped with the senors into a data center shared by otehr clients if any of them managed to catch your virus you can get data off them.

      It could be useful for snagging passwords and such where basically any server potentially get you something, maybe even bank details or something similarly sensitive if you get lucky with the data center.

  6. 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: 0

      Yes. It is. And the GP knew that.

      Now think about it for a bit and re-read the comment.

    4. Re: 1000 bits/ per LED? by Anonymous Coward · · Score: 0

      Don't get cocky kid.

    5. Re:1000 bits/ per LED? by Anonymous Coward · · Score: 0

      This makes me think this is a bunch of bull.

      Normal video is 60 frames per sec, to get the data off a LED you probably could not send more that 30 bits per second per LED.

      If you can modulate the brightness of the LED, you are probably limited to 8 bits of setting resulting in 240 bits per second.

      1000 bits per second per LED is BULL^&*@.

      E.C.P.

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

    7. Re:1000 bits/ per LED? by Anonymous Coward · · Score: 0

      Look at the brain on this one!

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

    9. Re:1000 bits/ per LED? by Anonymous Coward · · Score: 0

      If the LED is connected to a GPIO pin on a microcontroller 1Mbps+ is easy to do...

      Just because you're cycling the input to the LED at 1Mbps doesn't mean that it's flashing at 1Mbps.

  7. Jesus h Christ by Anonymous Coward · · Score: 0

    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

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

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

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

      bits/second/LED

  9. Amazing by Anonymous Coward · · Score: 0

    Today i:

    * remembered slashdot editors don't check for technical sanity because they don't know what they're checking for
    * lost (more) respect for the israeli hacking scene

  10. This research was sponsored by by Anonymous Coward · · Score: 0

    The makers of NCIS to make their computer bullshit seem less bullshit

  11. inb4 by poity · · Score: 1

    entire room wrapped in tape

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

    Wireless by definition makes the network insecure...

  13. 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 Anonymous Coward · · Score: 0

      But what video records at the speed?

      E.C.P.

    2. Re: Almost old school by Anonymous Coward · · Score: 0

      Still not an attack method.
      Exfiltration method, yes. Side channel communication, yes. But it's not a fucking attack.

    3. Re:Almost old school by Anonymous Coward · · Score: 0

      You could get one of those high-speed cameras they use for filming bullets and such. Or go cheaper - drop the camera stuff and just use an optical transistor and a telescope.

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

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

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

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

  16. 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 Anonymous Coward · · Score: 0

      > So if I get physical access...

      You don't need physical access. Have you not read the reams of tech stories about how vendor firmwares (at least for consumer goods) are utterly crap? This may be slightly more difficult on enterprise equipment (if only because the cost of acquiring said equipment to test for vulnerabilities is higher) but I'm sure someone dedicated could pull it off.

      So we've established physical access is not required to modify the firmware.

      Next point: how many people have insecure security systems? Again, reams of IP cams have the worst firmware security you can imagine, and many have cloud functionality, so it wouldn't be outside the realm of possibility to monitor the LEDs using an IP cam (although I would imagine the data rate will be much lower, since these devices are usually on the order of 5-30 FPS). So there's a way to egress data (albeit slowly) without raising any flags. Alternatively as others have pointed out, if you are within visual range of the equipment, just point your photodiode at it.

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

      How many home networks have encrypted data on them? I'd hazard a very small number. Samba isn't encrypted, neither is NFS or iSCSI. So file transfers between computers (or a NAS) are fair game.

      You're right it's best practice in a data center to have encrypted connections between any application servers, database servers, etc. But it's still unlikely that iSCSI traffic is encrypted. Sure, it's usually on a separate VLAN, but you can exfiltrate data using the LEDs, and it's unlikely you are running filesystem encryption on top of the iSCSI device. However the bandwidth of said LEDs are likely to be orders of magnitude lower than the link speed, so you'd have to be particular about what you wanted to snoop.

      Overall is this attack practical? Of course not. Is it possible? Yes, and that's why they wrote a paper about it. They are academics, after all. Feasibility doesn't matter, only published papers ;-)

    3. 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.
    4. Re:So if I get physical access... by Anonymous Coward · · Score: 0

      This is an airgap attack.

      Router leds are the TX, a Cellphone camera, security camera, or a camera with a telescope is the RX side.

      When was the last time you saw a data center with no security cameras?

    5. Re:So if I get physical access... by Anonymous Coward · · Score: 0

      Malware sometimes comes on these things out of the box.

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

    1. Re: Upgrade your router... by Anonymous Coward · · Score: 0

      If I ever see Poettering I'm bashing his brains in.

  18. Mod parent up by Anonymous Coward · · Score: 0

    Most douchebag flamer millenial readers like BeauHD will not understand. They will get boners from the Star Wars reference, and the rest will go over each other's heads as they jack each other off.

  19. Not exactly new. by Anonymous Coward · · Score: 0

    I have seen this exact same attack used to leak information as early as 1994.

    At the time, I was part of a team maintaining a large(ish) university network. One of my colleagues wrote a little program (I guess you'd call it malware today) that would sit around waiting for someone to enter in a password. It had some heuristic filtering in it that would basically log everything from the keyboard, separating the input into words based on the space bar or a period of time before and after a series of keystrokes. If it saw a word that had been entered twice with some minimum period of time in-between entries, it would assume that was a password, and wait for the machine to go idle. Once that happened, it would attempt to access the HDD and cause the HDD indicator to blink out the password using a simple binary format with some parity checking built-in (it was still able to successfully transmit the password even if the OS or another program caused a few errant blinks of the LED while transmitting the information).

    The general idea was that you could deliver the program to the computer somehow, then point a video camera at the computer from a safe distance (presumably through a window or something) and wait for the system to start leaking passwords. Afterwards, you'd just FF through the recorded video looking for the start of the password transmission (indicated by a set pattern of HDD LED blinking), then play it back realtime, and use your space bar to tap out the pattern you see on the video into the utility that converts the blinking patterns back into plaintext.

    I'd suspect that trying to do this today would be a hell of a lot more efficient if you've got access to the direct GPIO pins that drive an LED, but the theory is exactly the same. During the same job, we actually had someone complain about a bunch of LEDs on a rather popular piece of networking equipment having been tied directly into the data lines of some chip, from which you could actually identify bits and pieces of information flowing through the system. The manufacture responded by spinning up a second revision of that product's PCBs and including a pulse stretcher circuit that would basically hold the LED pin high for a minimum amount of time after any activity was detected. This eliminated the issue we'd heard the complaints about, and also made the activity LED much more pleasing to watch since it wasn't trying to flicker on and off a thousand times per second.

    In any case, this sort of thing isn't exactly new. I'm just surprised people haven't done more research on this subject, but I'd assume that things like this are still in active use by the CIA/NSA/etc. Kinda reminds me of a line from the movie Zero Days (a great documentary about Stuxnet BTW)- they had some dialogue from a supposed CIA guy and basically said "It's cute you think your airgapped systems are safe".

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

  21. 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 Anonymous Coward · · Score: 0

      Kim Jong Un uses this method to communicate with his operatives.

      Russia communicates to the Trump Administration via blinking lights on The Empire State Building.

      Trump replies via twitter using secret code words whose meaning is only known to the KGB.

    2. 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
  22. I love it by ArylAkamov · · Score: 1

    Impractical but creative, I can dig it.

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

    1. Re:Not an "attack" by Anonymous Coward · · Score: 0

      Something the size of a pinhead in a strategic location might go unnoticed for quite a while, I would think.

    2. Re:Not an "attack" by Anonymous Coward · · Score: 0

      Also, many NOCs have security cameras, so if an attacker compromises the right angle then this could be a potential issue.

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

    1. Re:Nice movie plot but.... by Anonymous Coward · · Score: 0

      Not being practical today does not preclude someone else coming up with a useful attack method at some later date.

  25. Restrictions... by Anonymous Coward · · Score: 0

    Please note that this research works on an AIRGAPPED router...

    On the one hand, who's going to have an air-gapped router? On the other hand, stuxnet was able to penetrate onto air-gapped networks and then activate its payload. It was not necessary to exfiltrate any data. Or maybe just one bit: "success". This was transmitted optically: observed by spy satellites...

    I agree with the other posters that remark that much higher datarates should be possible.

  26. 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 Anonymous Coward · · Score: 0

      Sure. Many secure racks are simply locked, sometimes with an extra metal fence in front of the room. Renting a rack on the opposite site and pointing a camera at their switch should be doable.

      Hacking the datacenter CCTV may also be possible, seeing the general state of security in IP cameras.

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

      Maybe the data centers own security cameras?

      --
      love is just extroverted narcissism
  27. 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
  28. FFS by Anonymous Coward · · Score: 0

    Fine! I'll turn the router off! Hey, now I can't post....NO_CARRIER

  29. running out of research paper ideas :) by Anonymous Coward · · Score: 0

    Ridiculous waste of time.

  30. "1000 bits/ per LED" - LOL by Anonymous Coward · · Score: 0

    Typical Slashdot idiocy.

    1. Re:"1000 bits/ per LED" - LOL by srpape · · Score: 1

      Same thought, what kind of rate is that?

  31. Not that original... by Anonymous Coward · · Score: 0

    Seriously guys, we were doing this sort of thing with the LEDs on 10baseT network cards back in the day and you didn't even have to reprogram them!

    And what is this obsession with sticking Malware on everything all of a sudden?

    This isn't malware, just a regular firmware hack surely?

  32. Judging by this and past stories by Anonymous Coward · · Score: 0

    Israel has the market cornered in useless malware.