[HN Gopher] 38C3: Blinkencity, radio controlling street lamps an...
___________________________________________________________________
38C3: Blinkencity, radio controlling street lamps and power plants
[video]
Author : aunderscored
Score : 188 points
Date : 2024-12-28 23:02 UTC (23 hours ago)
(HTM) web link (media.ccc.de)
(TXT) w3m dump (media.ccc.de)
| aunderscored wrote:
| Saw this in person, awesome look at street lamp control and then
| walking that all the way up to "oops we figured out a way to
| attack the European power grid"
| pantalaimon wrote:
| I can imagine how this went:
|
| - We have this protocol to switch the streetlights remotely by
| modulating a signal on the main - but that's needing expensive
| hardware and it's cumbersome. Can't we just sent that over radio
| instead?
|
| - There is all this decentralized renewable energy generation, we
| need a way to switch that off remotely if there is an overload in
| the grid - hey, we already have that hardware for swtiching
| streetlamps, let's just use that!
|
| Of course encrption was never a concern and now anyone could
| remotely turn off / on power generation. But for that to cause
| real trouble, you'd need coordinated action that would require
| something like a state level actor.
| unbelauscht wrote:
| Like the one who's been messing with our deep sea cables?
| gorgoiler wrote:
| I really enjoyed how the payloads _are_ encrypted, but the
| implementation leaves time synchronization in plaintext. With
| the street lamps that work to a fixed schedule, all you have to
| do is reset the time between 12pm and 12am to turn them on and
| off (the "lamplighter" attack, in the talk.)
| happosai wrote:
| Listening to the talk, I don't think it was encrypted. They
| just said in early in the talk that it seemed encrypted due
| to high entropy. But later in the talk they decoded the
| payloads after they figured out the format.
|
| But yeah, insecure time is a underrated attack vector.
| pantalaimon wrote:
| As I understood it, that's likely weather data from a 3rd
| party (Meteocast) that they encrypt to protect their
| IP/subscription.
| mindcrime wrote:
| _But for that to cause real trouble, you 'd need coordinated
| action that would require something like a state level actor._
|
| Or thousands of individuals using relatively inexpensive HackRF
| One SDR's, or home-brew radio transmitters which can be built
| even more cheaply. Of course all those people would need a way
| to communicate with each other over large distances... perhaps
| some kind of packet switching network running over a series of
| tubes (or avian carriers). Hmmm.
| Muromec wrote:
| >But for that to cause real trouble, you'd need coordinated
| action that would require something like a state level actor.
|
| luckily there isn't a state actor actively sabotaging all kinds
| of infrastructure in Europe right now with explicit interest to
| sabotage renewables
| ForOldHack wrote:
| They could drag a boat anchor across it?
| H8crilA wrote:
| Authentication, not necessarily encryption. It's a common
| misconception to think that you need the latter while you
| actually need the former. And no, encryption does not mean
| authentication, not at all, usually you can meaningfully modify
| the ciphertext if a given protocol has no authentication.
|
| Also, here's a fun thought experiment: consider two channels,
| one authentic but not encrypted, another non authentic but
| encrypted. Can you actually find a use for the second one? Can
| you find a use for securely talking to an unknown entity, other
| than running Omgele? :)
| tialaramex wrote:
| We should distinguish whether we want _everybody_ to be able
| to authenticate the messages or only our intended recipient.
| This is separate from the question of whether the message
| should be encrypted. It may be reasonable for infrastructure
| to work only with messages everybody may authenticate since
| there is nothing to hide. For this purpose a Signature Scheme
| is ideal - simply _sign_ your messages.
|
| Whereas for example in Signal two people could have made an
| Alice->Bob message. Both Alice and Bob have the keys to make
| such a message. Alice might have made it, and sent it to Bob,
| or, Bob might have just made it seem as though Alice sent him
| a message. Bob presumably knows if he's lying, but he can't
| prove it either way.
|
| The unauthenticated link is basically useless. You aren't
| "securely talking to an unknown entity" because if you were
| that would be an authenticated link. TLS 1.3 can do "securely
| talking to an unknown entity" - but it's an authenticated
| link, the unknown entity is the authenticated remote party.
| You don't know who they are, but you do know they're your
| remote party whoever that is.
| H8crilA wrote:
| Maybe I should have added what an encrypted, but not
| authenticated link looks like, because I meant it in both
| directions. An example would be doing unauthenticated
| Diffie-Hellman (without any signatures, or proving
| knowledge of a secret, or anything of this sort), then
| proceeding using the shared key with even the best of
| schemes. Another example would be a spy sending and
| receiving one-time-pad encrypted data via an untrusted,
| malleable channel - the only authenticity is in hoping that
| adversarial modifications will cause one of the endpoints
| to fail at "parsing" the message. It is indeed useless.
|
| Also, this property of Signal is called repudiation (or
| non-non-repudiation :) ), meaning that you as a party in
| the communication can repudiate the origin of the message,
| i.e. say that you didn't write it. It is a nice extra
| feature, on top of authenticity and secrecy.
| tialaramex wrote:
| > then proceeding using the shared key with even the best
| of schemes
|
| Unlike with your "spy" scenario, this situation is in
| fact what TLS 1.3 builds initially and it's not useless
| at all, nor is the resulting link unauthenticated.
|
| 1. First Alice sends her fresh parameters to Bob
|
| 2a. Then Bob sends his fresh parameters to Alice
|
| 2b. Alice and Bob now have all the DH parameters and they
| now have a shared secret X
|
| 2c. Bob calculates a Digest of a transcript of the entire
| conversation so far and sends this Digest, encrypted with
| X to Alice, he can send this alongside the parameters if
| he wants
|
| 3. Alice also likewise calculates a Digest and sends the
| encrypted digest to Bob
|
| Both Alice and Bob now have a shared secret and have an
| authenticated (because they've seen the other party's
| view of the conversation in the digest and confirmed it
| matches their expectation) communication channel which
| they can use. They don't learn each others' identity but,
| of course, it is easy to additionally offer this as part
| of the same protocol and HTTPS does so in one direction
| in the typical case.
|
| Edited: Renumbered to clarify that only three messages
| are sent, parts 2a, 2b and 2c are actually a single
| message from Bob to Alice
| H8crilA wrote:
| I meant that man in the middle attacks make this
| effectively unauthenticated.
| tialaramex wrote:
| Suppose that Eric is in the middle.
|
| Eric _could_ allow those initial three messages to pass
| unmolested. In this case Alice and Bob now have an
| authenticated connection and Eric is unable to read or
| modify their messages. So I suppose you don 't mean that.
|
| What if Eric just substitutes his own message for Alice's
| in step 1? He provides his own parameters. Since these
| were not Alice's parameters, Alice will not provide an
| acceptable Digest for the conversation, the parameters
| Eric sent to Bob are different and do not match the
| transcript, the connection is terminated.
|
| What if Eric substitutes Bob's only message in step 2? He
| provides his own parameters, and he can respond with a
| transcript digest for this alternate conversation. Now in
| fact the TLS 1.3 connection exists as normal, but it is
| between Alice and Eric. We're actually fine! We have a
| properly authenticated connection, with unidentified
| participants (we know they're Alice and Eric but Alice
| and Eric don't know that). Bob's connection fails, or he
| is unaware that Alice tried to connect.
|
| Finally if Eric waits until Alice's second message in
| step 3, no message Eric knows how to construct is
| satisfactory. Only Alice's original message will work,
| other messages cause the connection to fail because Bob
| will not accept them.
| H8crilA wrote:
| I'm sorry, are you trolling? You pretend to be Bob to
| Alice, and Alice to Bob, at the same time. Real Alice and
| Bob never compute the same transcript digests, but it
| doesn't matter. As post handshake data is flowing you
| decrypt it and reencrypt, modifying what you want.
|
| Or, imagine that there isn't even one legitimate Bob in
| the world. But Alice is still talking to someone who
| follows the protocol, and is indistinguishable from a
| real Bob. Is that possible?
| npteljes wrote:
| This is very nitpicky, and not even valid at that.
|
| First, I think authorization is even more valid than
| authentication. In this context, it's the authority is what
| is important, so that only the designated entities can assert
| control over the system, and not others.
|
| Second, it's very hard to imagine authorization on an open
| channel like radio, without any sort of encryption. In fact,
| only the one-time pad comes to mind, although I'm far from
| being a proper security person. What I see is that authority
| is usually demonstrated through some encrypted means - even
| if the message itself is unencrypted, its digital signature
| is.
|
| >another non authentic but encrypted HTTPS is one such
| channel. The weakest guarantee of HTTPS is that the comms
| between the client and the HTTPS terminating server is
| encrypted, nothing more. HTTPS security can be upgraded to
| include authenticity information, but it's not mandatory, and
| it's still very useful even in this weaker form.
| Scaevolus wrote:
| Authorization can be achieved by authentication with either
| a preshared key or a key derived using public key
| cryptography and some PKI.
|
| It's trivial to implement on an open channel, HMAC being a
| common form. This is how old APIs using HTTP (Flickr, S3)
| handled authorization despite all communication being
| cleartext.
|
| Confidentiality and integrity can be achieved with a single
| authenticated encryption primitive, or done separately with
| encryption and a hash-based authentication primitive, or
| exist as one without the other.
| H8crilA wrote:
| Authentic channel is a channel typically uses for digital
| signatures, or MACs, or something like the Dragonfly
| protocol used for example in WPA3. As you may know the
| padlock and alerts in browsers are exactly for that reason,
| to show that a channel is authentic. The client doesn't
| authenticate by default, we use passwords/API
| keys/oauth/etc for that. Though the client actually can,
| and some services use that.
|
| > Second, it's very hard to imagine authorization on an
| open channel like radio, without any sort of encryption.
|
| It's easy: you add digital signatures to sign plaintext
| packets/messages.
| Eduard wrote:
| TL;DR: by law, German power stations are required to "turn off"
| (taken off the energy grid) when they receive specific radio
| messages. This is intended for energy grid load balancing.
|
| Unfortunately, the message protocol is completely flawed
| security-wise, which allows malicious actors to control the power
| station.
|
| It would require only a handful of strategically placed senders
| to control an estimated 20 gigawatt of load Germany-wide, causing
| havoc on the European energy grid (brown-out, cascading effects,
| etc.).
|
| The security researchers followed a responsible disclosure
| towards the vendor, EFR, who reacted with sending letters from
| their lawyers.
|
| Today's SPIEGEL online news magazine pre-talk report (
| https://archive.is/p66as ) on this topic cites EFR that the
| proposed attack vector is not possible.
|
| The security researchers therefore made the last minute decision
| to go full disclosure with today's talk to press on the urgency
| of the topic.
| jdiez17 wrote:
| Just read the SPIEGEL article and I think it's a pretty
| balanced report on the positions of both sides. Basically, it
| comes down to the assertion that you can't reach a large number
| of electricity generation plants with "simple radio equipment".
| That is the position of EFR, and sadly, the Bundesnetzagentur
| (the radio communications regulator in Germany).
|
| I haven't watched the talk yet but I think it's pretty clear to
| all of us on this website, that sending a specific short radio
| transmission to a large area is not an insurmountable challenge
| for our favorite terrorist state.
|
| What I don't understand is why there is such a reluctance to
| admit that these problems exist and work towards fixing them.
| Instead we pull the Ostrich maneuver every time. One day it's
| going to really bite us in the ass.
|
| EDIT: after watching the talk, the funny thing is that all of
| the "business secrets" that EFR is accusing our fellow hackers
| of leaking, are actually mostly DIN standards. In other words,
| they are just upset that someone is talking about the fact that
| no efforts have been made to proactively secure these
| receivers. Peinlich.
| Etheryte wrote:
| Ass covering, so much ass covering everywhere. I've done a
| fair bit of consulting for the public sector and figuring out
| their office politics is often the only real way to get
| anything done, the actual technical discussion is often
| secondary.
| randunel wrote:
| Insurmountable? How many russian citizens live in Germany?
| And how many russian fanboys with a non-russian citizenship?
| Now extend that to neighbouring countries, or the Schengen
| area.
| jdiez17 wrote:
| You may want to reread my post.
| semi-extrinsic wrote:
| IANAL, and didn't watch the full recording yet. But if the
| EFR lawyers are threatening the hackers with "leaking
| business secrets", they have to be wildly incompetent. I
| won't give those guys any ideas, but I'm certain there are
| much more scary parts of DE/EU law that you could threaten
| with.
| trebligdivad wrote:
| I think they kind of have a point; they were talking about
| needing a 10kW transmitter - that's a heck of a lot of power
| for a transmitter, not easy to make at all. And at those
| frequencies, the antenna is a challenge. Having said that, a
| bunch of few-hundred W transmitters in convenient places
| would be a lot easier, and there are probably easy but
| inefficient antenna hacks (drop a wire down a cliff/across a
| park/out of the top floor of a tower block?)
| grumpy-de-sre wrote:
| I beg to disagree, 10kW at ~140khz is actually relatively
| straight forward with modern semiconductors and LiPo's. Eg.
| the inverters in a Tesla Plaid can do up-to 750kW, so I
| think two orders of magnitude more power is theoretically
| possible.
|
| And then they left out that at such long wavelengths there
| are some unconventional antenna topologies available. Some
| of which are a lot more feasible than anything that was
| discussed in the talk.
|
| The dismissal is quite concerning IMO.
| Eduard wrote:
| Also, IMHO instead of a few strong senders, an attacker
| could use more low-powered senders placed in proximity to
| power stations.
| matchamatcha wrote:
| Talk starts around ~16:20 minutes in..
| Torkel wrote:
| And the talk itself is in English.
| _ink_ wrote:
| Why do we still build new remotely controlled things and then
| skip security? Like when was this ever a good idea?
| avidiax wrote:
| I think it's a failure to solve 1 + x = 2. x is the percentage
| of the power grid controlled by this system, which has risen
| over time.
|
| So at design time, the threat is just that people can turn off
| street lamps, which you can do with a BB gun. Then you expand
| to home solar. Also not so interesting.
|
| But then you expand to be a significant fraction of the grid
| supply and load. Now there is a substantial target that
| actually needs security, but which requires a full redesign.
| __jonas wrote:
| That was an interesting talk!
|
| I'm not very familiar with security stuff, but I didn't really
| get the responsible disclosure thing - is it really unreasonable
| for this company to ask them not to go public just three months
| after their initial disclosure?
|
| I understand the 'it was known since 2013' thing, but they did
| also say the company was actively making improvements after the
| initial disclosure so they were not exactly just shoving it under
| the rug were they?
| Hikikomori wrote:
| They got letter from their lawyers no?
| __jonas wrote:
| Yeah? I'm saying I don't get why the letter from the lawyer
| is unreasonable.
|
| Sure, ideally it would have not been done via a lawyer but
| rather just asking them to delay going public directly since
| they were communicating before, but still it's just three
| months after initial disclosure and they were actively making
| improvements and informing customers that they need to switch
| out hardware which I assume takes time, I think not wanting
| the researchers to go public just yet is pretty reasonable
| no? Am I missing something?
|
| As I said I'm not very familiar with security research stuff,
| maybe anything goes three months after disclosure, it just
| surprises me.
|
| Also just to be clear: the work by the researchers here is
| super impressive, and it's fantastic that they are doing it,
| I was just wondering about this disclosure process.
| aunderscored wrote:
| If you always allow a company to say "wait no don't" with
| issues, it gives them a tool to quiet problems without
| solving them. Responsible disclosure is a tool , and part
| of that tool is the understanding that this will be public
| BonoboIO wrote:
| What a great way for a state to cause havoc in all of Europe.
|
| Russia definitely has the capabilities to send such signals in a
| coordinated attack and deny an wrong doing.
|
| And this is just one example we know of, there must be hundreds.
| ElectRabbit wrote:
| They have low-kHz transmitters for reaching submarines. So, for
| many decades already.
| Towaway69 wrote:
| Are there any pointers to the software they built for the
| flipper?
|
| It seems that they did create an app but it's nowhere to be found
| on the flipper "app store".
| ugjka wrote:
| this seems their website https://positive.security/ not sure
| where they host their code
| Towaway69 wrote:
| Thanks but from there I got nowhere, unfortunately no links
| to git*.com.
| oger wrote:
| The researchers did a great job in pointing out the failures in
| what basically is an old DIN standard that should not be used in
| this century. I congratulated them after the talk as I did
| similar research and didn't get it finished for 38C8. Their
| presentation is spot on. The attack vector is definitely feasible
| and publicly known for a while. I honestly don't understand why
| nobody in the industry wanted to switch to a safer alternative.
| The reaction by EFR will create an unnecessary Streisand effect
| and after all they will be able to upsell their customers to a
| (soon to be legacy) 450 MHz LTE system.
___________________________________________________________________
(page generated 2024-12-29 23:01 UTC)