3 ms·

The attackers didn't get the keys to the back door. They actually replaced the entire door with a new door that they made, which went unnoticed (by Juniper) for

by khuey 5y ago

The attackers didn't get the keys to the back door. They actually replaced the entire door with a new door that they made, which went unnoticed (by Juniper) for 3 years, locking out the owners of the original back door too. It's a rather impressive attack.

marcan_42 5y ago
No, the attackers just re-pinned the backdoor lock cylinder that the NSA put on their "secure" door. That's why nobody noticed. The NSA conveniently left them a door with a backdoor they could hijack in a way that is effectively invisible. Replacing the whole door would've been like replacing the entire DRBG, which would've much more likely raised alarms.
- eli 5y ago
  Having a convenient backdoor already integrated definitely aided the attack, but a sophisticated attacker with the ability to silently modify your codebase is a pretty bad place to start from regardless.
  - convolvatron 5y ago
    how would you possibly prevent such a thing? even if Juniper subjected all potential employees to clearance-like screening - that's not foolproof either.
    - lostmsu 5y ago
      Absolute prevention is probably impossible, but you can severely reduce the chances of successful attack by a) limiting access to security critical parts of code b) having shadow reviews of the same code (e.g. a separate team, that gets a notification every time these pieces of code are modified, and re-reviews them without notifying the original patch submitter)
soraminazuki 5y ago
From the original link: > In practice this would simply mean hacking into a major firewall manufacturer’s poorly-secured source code repository, changing 32 bytes of data, and then waiting for the windfall when a huge number of VPN connections suddenly became easy to decrypt. And that’s what happened. 10/ I would definitely not describe replacing 32 bytes as "replacing an entire door."
ThePadawan 5y ago
TBH sometimes you don't think about this stuff. Back in college, my (CS) department shared a student area with the students from the EE department, so naturally a friendly rivalry evolved. There was a shared common area, and a private office for CS and EE each, both separated by lockable doors from the common area. One day, we arrived to find that the EE department had left a taunting note on a desk in our (still) locked office. At first we thought they airdropped it (since the office walls didn't reach all the way to the slightly domed ceiling), but we didn't think of the obvious: The office doors simply had their hinges on the outside. They straight up took the door off the hinges, and then put it back.
- stordoff 5y ago
  That reminds me of some dodgy locks I encountered at university. There was a gap between the door and the frame, and if you slid a knife down here, it would unlock the door (one of our tutors informed us of this, oddly enough). This was fixed by screwing a metal plate over the gap - of course, if you were determined enough, you could just unscrew the plate.

by khuey 5y ago

marcan_42 5y ago

No, the attackers just re-pinned the backdoor lock cylinder that the NSA put on their "secure" door. That's why nobody noticed. The NSA conveniently left them a door with a backdoor they could hijack in a way that is effectively invisible. Replacing the whole door would've been like replacing the entire DRBG, which would've much more likely raised alarms.

eli 5y ago
Having a convenient backdoor already integrated definitely aided the attack, but a sophisticated attacker with the ability to silently modify your codebase is a pretty bad place to start from regardless.
- convolvatron 5y ago
  how would you possibly prevent such a thing? even if Juniper subjected all potential employees to clearance-like screening - that's not foolproof either.
  - lostmsu 5y ago
    Absolute prevention is probably impossible, but you can severely reduce the chances of successful attack by a) limiting access to security critical parts of code b) having shadow reviews of the same code (e.g. a separate team, that gets a notification every time these pieces of code are modified, and re-reviews them without notifying the original patch submitter)

soraminazuki 5y ago

From the original link: > In practice this would simply mean hacking into a major firewall manufacturer’s poorly-secured source code repository, changing 32 bytes of data, and then waiting for the windfall when a huge number of VPN connections suddenly became easy to decrypt. And that’s what happened. 10/ I would definitely not describe replacing 32 bytes as "replacing an entire door."

ThePadawan 5y ago

TBH sometimes you don't think about this stuff. Back in college, my (CS) department shared a student area with the students from the EE department, so naturally a friendly rivalry evolved. There was a shared common area, and a private office for CS and EE each, both separated by lockable doors from the common area. One day, we arrived to find that the EE department had left a taunting note on a desk in our (still) locked office. At first we thought they airdropped it (since the office walls didn't reach all the way to the slightly domed ceiling), but we didn't think of the obvious: The office doors simply had their hinges on the outside. They straight up took the door off the hinges, and then put it back.

stordoff 5y ago
That reminds me of some dodgy locks I encountered at university. There was a gap between the door and the frame, and if you slid a knife down here, it would unlock the door (one of our tutors informed us of this, oddly enough). This was fixed by screwing a metal plate over the gap - of course, if you were determined enough, you could just unscrew the plate.