[HN Gopher] DoS Attacks in Available MQTT Implementations
___________________________________________________________________
DoS Attacks in Available MQTT Implementations
Author : goodburb
Score : 22 points
Date : 2024-01-25 05:55 UTC (1 days ago)
(HTM) web link (st.fbk.eu)
(TXT) w3m dump (st.fbk.eu)
| bhaney wrote:
| One hell of a nothingburger. Of course you open yourself up to
| DoS/magnification attacks if you publicly expose a broker with
| broadcast/fanout functionality.
| lfmunoz4 wrote:
| Yeah what an obvious article. Too bad brokers are all locked
| down by clientIds / passwords and certificates and if you start
| acting out of the ordinary you will get banned / blocked. Even
| 1 packet of a large size can cause being blocked in a good
| production environment.
| fisf wrote:
| Also ignores any required authentication. This is basically
| just a load test.
|
| Why has the security field degenerated to such a shitshow?
| pixl97 wrote:
| Degenerated?
|
| Welcome to the shitshow, it's always been this way in
| computing, security is always an afterthought.
| zer00eyz wrote:
| >>> security is always an afterthought.
|
| Not everywhere.
|
| Some places take security seriously. Banks do not fuck
| around on this front.
|
| Some places security is where they shove all the diversity
| hires. It's not an afterthought it's a dark corner no one
| cares about.
|
| Other places have security as theater. I know of quite a
| few companies who have security tools implemented just to
| have someone to blame when the fuck up happens. XXX was our
| provider, were sorry sue them, were going to!
|
| The reality is that the decision makers heard what they
| should do, and made a choice, not understanding the risk.
| In that regard some of them are getting better (see
| theater), and making it worse.
| pixl97 wrote:
| >Banks do not fuck around on this front.
|
| So, I have a fair bit of insight into bank operations and
| their programming practices.
|
| The vast majority of it is security theater. There is
| quite a bit of decent code near the core moving money
| portions, but once you start getting into the webapp side
| of things it quickly devolves into "Please do the basic
| minimum to ensure security of this application".
| 3abiton wrote:
| To be fair you'd be surprised how many Hassio hoppyist leave
| their MQTT setup default (or even without password). Was part
| of a community 2 years ago that was tinkering with IoT for home
| automation, and most of them were not that familiar with linux,
| let alone lua, and would leave all their setup default.
| mindslight wrote:
| In a sense this is still more secure than your common
| proprietary solution: It is at least illegal for surveillance
| companies to connect to your open MQTT broker and record your
| house telemetry to try to get you to buy more crap!
| mindslight wrote:
| Regarding MQTT in general - is my reading of the spec correct in
| that there are actually no message ordering guarantees across
| different topics ? This would imply that the common HA pattern of
| a single device publishing/receiving commands/status on multiple
| semantically-named topics (eg /dev001/onoff + /dev001/color) is
| actually a subtly incorrect use of the protocol? And the way to
| maintain ordering with the protocol is to have only a single
| topic for commands and a single topic for status updates? Because
| this is what I've concluded, but I'd love to be wrong!
| oriettaxx wrote:
| If you follow the "Acceptance News: Link" you get to a date:
|
| Published: Jun 5, 2021
___________________________________________________________________
(page generated 2024-01-26 23:00 UTC)