Add supply chain attack defenses for downloaded firmware

Supply chain attacks are gaining in popularity and it would be good for Peplink to offer additional assurance that downloaded firmware is legit. Thanks to Solar Winds, everyone knows that depending on HTTPS is insufficient.

One approach is to publish a hash of each firmware version. A simpler, but related, approach would be to publish the exact size, in bytes, of each firmware version. Or both.

Peplink routers do some verification of new firmware before installing it. Explaining what is validated would also be re-assuring.

Finally, a firmware Release Candidate should be clearly identified as such. This is already done with Beta releases. I mention this because 8.1.1 RC2 self identifies as 8.1.1 build 4991, with no mention of it being a Release Candidate.

Thank you.


SW had nothing to do with HTTPS.

How many people actually check the hash? An attacker could also change the posted hash, right? so you need a secure process around all of that…

With the SW hack, common sense was lacking in multiple instances, including:

  1. weak password that could be guessed / cracked
  2. not listening to incident report of the password being known, going back and making sure things are good after a serious report
  3. telling users of their software to disable AV scanning on the software directory
  4. absolutely poor change control/change management procedures
  5. not locking down ingress/egress internet traffic to critical infrastructure/devices
  6. trusting a network tool that is closed source with “god” access to your critical infrastructure
  7. etc

the hackers did a dry run to see how much they could get away with and struck a balance between their code changes being detectable and the level of access they were going after. they were not detected until likely one of the national agencies, cough NSA, probably sprinkled a hint over to someone at fireeye, and thats when things started to get uncovered.

How many people actually check the hash?

The point is that if a client does not check it and they hacked, much of the blame falls on them.

An attacker could also change the posted hash, right? so you need a secure process around all of that…

Yes. The system that creates the software needs to be off-line and thus, hopefully, not hackable. And the process of generating/publicizing the hash should be manual, again, in the hope that it can’t be hacked.

Solar Winds was warned about security issues multiple times both internally and from external sources. I read that the first detection came from a Duo Security 2FA system when a hacker registered a device and the real employee, whose password was stolen, was notified. But, that seems like a dumb mistake for a group that is otherwise sophisticated, so I am skeptical.

Someone submitted a security incident report about the password being known and easily crack-able in Nov 2019. Pretty sure the Duo part occurred later on but I could be mistaken. Also, the hackers did a dry run.

I’d argue secure and solid change management is way more important than a hash.

Good luck getting developers to use an off-line system… even “offline” systems are hackable…