meteohub.de

When can we expect WPA2 client patches for Meteobridge devices for the recently well publicized KRACK vulnerability?
https://www.kb.cert.org/vuls/id/228519

I expected a first time poster to ask for this Anyhow, welcome to the forum.

Meteobridge is based on openwrt "barrier breaker", which is not the most current release and apart from that openwrt has forked into a strong "lede" development stream. All this has a negative impact on if/when backports of the WPA2 stack will be made available for the openwrt release Meteobridge is based on.

One way out would be develop a new firmware based on a fixed and up-to-date lede releases. Having that users will need to reflash their systems to get this running... Lots of work/hassle not just on my side, but also for the users.

Looking at the discovered issue, it does NOT leak the WPA2 key. Therefore there is no risk when the communication between Meteobridge and the WiFi router is cracked, that the WPA2 key is leaked and by that someone can penetrate your WLAN. Only risk to my understanding is that the traffic between the WiFi router and Meteobridge can be decoded. So someone in direct WiFi reach of your Meteobridge can listen to the traffic. That is quite an effort just to get access to your weather data, isn't it? Credentials you use in Meteobridge to feed your email account or FTP-Server might also leak by that. This is of course a threat. But do you have a realisitc chance that a crypto hacker will position himself in your WiFi reach to read out your email or FTP credentials? Is that a real risk in the specific Meteobridge use case? You might judge yourself.

As said, I will try to find a good solution to this. But please also get a realistic feeling of the mangitude of this threat regarding Meteobridge. A smartphone used in alien WiFis where you might also do online banking with is of course at significant risk, no doubt. But Meteobridge is a complete different scenario imho. Therefore, no reason to be deeply concerned

Thank you.

I suspected there would be logistical issues for patching and expected it to be non-trivial on an older embedded-esk system (especially after reading the recent post about changes to licensing/updates) and haven't dug too deep into the Metrobridge stack. I'm also aware of the minimal risk in most use cases but I had to ask.

I'm responsible for some of the underlying infrastructure and deployment for a small (yet growing and unknown end scale) state wide mesonet of weather stations across my region and currently use Metrobridge devices at each station to ferry data back to a central MySQL database. The majority of the nodes are in rural locations in areas that are typically not surrounded (within WiFi range) by technical users, so the current risk is very minimal, however, with multiple nodes, risk grows. The station locations have detailed spatial information from high accuracy GPS for scientific use, but such information could be used against us in this particular case (for more conveniently localized WPA2 attacks, we even have a map ).

The main risk right now is that some nodes are in fairly densely populated areas that are much higher risk (on two university campuses, soon three, where people are known to explore -- one is right beside our CS department heh) and these are the nodes at the most risk (likely from CS students interested in IoT/cybersecurity). As you mentioned, I expected patching WPA2 will require flashing or some physical time with the devices (which requires me driving hours and hours through rural regions to each node location which as you mentioned, is not something enjoyable for me) which is another reason I was interested so I can try plan out the future network deployment schedule (minimize driving to sites multiple times by applying patched firmware to future nodes).

I've taken obvious precautions to create a minimally privileged a database user for Meteobridge I/O to minimize risk of having our database compromised (amongst other precautions), or worse, escalated shell access from the database account (due to design choices by other parties on a software platform, I'm stuck with an older version of MySQL that likely looks like a Swiss cheese of vulnerabilities).

Ultimately, the direct MySQL client database connections from Meteobridge are expected to be replaced by calls to a REST interface/API to add another layer of encapsulation, but given strained personnel resources on time of my associated project, this may or may not ever happen.

Anywho, it's my job to ask this question, otherwise on the odd (and unlikely) chance someone targets our network and our mesonet's dataset integrity is compromised, my boss will ask if I was aware if the issue and looked into it or not. I can now say "yes."

Don't get me wrong, it is completely fair to ask and given your specific situation I would also do

Regarding making use of HTTP(S) requests instead of direct MYSQL requests to send data to a server and to bring it into a database my preferred choice would also be HTTP(S). Doing such a wrapper in perl or php should be easy going.

Being back from vacation I started gathering information about this. For the time being my recommendation for worrying users is to use encrypted services instead of the plain ones:
- HTTPS instead of HTTP for http uploads/requests
- SFTP instead of FTP for uploads
- email services with START-TLS, TLS instead of plain password authentication

By doing so you eliminate the risk, that someone grabs your server credentials by cracking and reading WPA2 traffic between your Meteobridge and your router. When doing FTP, HTTP or unencrypted SMTP services you already have been vulnerable on the connection from your router to the target in the Internet. KRACK just opens up an additional chance to read data from the connection from your Meteobridge to your router.

Please stay tuned, I will look for a patch for this, although it might take some time to get a grip to an applicable back port.