[HN Gopher] 5Ghoul: Unleashing Chaos on 5G Edge Devices
___________________________________________________________________
5Ghoul: Unleashing Chaos on 5G Edge Devices
Author : rho138
Score : 113 points
Date : 2023-12-08 09:51 UTC (13 hours ago)
(HTM) web link (asset-group.github.io)
(TXT) w3m dump (asset-group.github.io)
| jruohonen wrote:
| Seems bad enough, although most seem plain DoS. Even with that,
| the fun may start soon and continue for a long time because most
| of these are never patched. (That said, I didn't read close
| enough to deduce how realistic exploitation is.)
| osy wrote:
| They are all denial of service bugs. I.e. crashes/hangs. No
| remote code execution or disclosure of sensitive data.
|
| Glad they were able to figure out the branding though.
| bryancoxwell wrote:
| > No [...] disclosure of sensitive data.
|
| Not directly, but downgrading to LTE would almost certainly
| force a UE to expose its IMSI at least.
| gafage wrote:
| You don't need a baseband exploit for that, just a jammer.
| zapcto wrote:
| > At least two other vulnerabilities are not disclosed yet due
| to confidentiality.
| jdiff wrote:
| > Glad they were able to figure out the branding though.
|
| That's pretty obviously something someone threw together in a
| few minutes after grabbing a few [0] random images from the
| internet. This isn't one of those exploit sites with more
| effort poured into marketing than the exploits themselves.
|
| [0] https://www.flaticon.com/free-icon/ghost_1227567
| coldpie wrote:
| The vulnerability branding trend is stupid, but I'm not sure
| it's worse for communicating what you're talking about than
| "CVE-2023-129038, 109239, and 120993" or "Those 5G
| vulnerabilities from uh I think 2022 or 2023? No not those, the
| other ones." Is there a better method?
| fragmede wrote:
| I don't think it's stupid because I can't, off the top of my
| head, tell you the CVE number for Heartbleed, despite being
| very involved with it for a couple of weeks.
|
| Heartbleed I remember, along with Spectre/Meltdown, but I
| couldn't name the weak exploits that turn out to be nothing
| burgers. Log4j could have used a brand though, imo.
| andrewxdiamond wrote:
| How often do you need CVE numbers while simultaneously
| being unable to google for the CVE number?
| fulafel wrote:
| They observed just crashes and they didn't try to research
| exploitability. Absent more details, and knowing the usual
| exploitability distribution of C crash bugs, this would seem in
| doubt still.
| snvzz wrote:
| Proprietary, audit-unfriendly blobs.
|
| It should be no surprise the code is crap quality, like the fw in
| those Polish trains, although those had malware to boot.
|
| And then, the protocols themselves are encumbered. GSM is a
| disaster in general.
| cogman10 wrote:
| I hate that this is status quo for mobile hardware. And almost
| certainly just to enforce artificial support boundaries to sell
| more hardware.
| hedora wrote:
| It also enables a lot of surveillance and prevents innovation
| in cell phone business models. Imagine what things would be
| like if you could connect any compatible device to the phone
| network for the same price.
|
| The land line network used to work like the cell network does
| today. Early home computer networks, and then later, home
| internet were enabled by the court ruling that said the phone
| company couldn't block you from plugging modems in (or charge
| more for the same copper wire if you did plug a modem in).
|
| California network neutrality laws supposedly ban
| discrimination against devices as well as against web sites,
| but it's either unenforced, or there is a loophole.
| cduzz wrote:
| So -- to a large degree you're right.
|
| But also, with the history of actually open protocols such
| as SMTP, the opportunity for abuse is enormous. The mobile
| phone system is abused right now by manufacturers, vendors,
| and "the surveillance state", but being open may just end
| up with us in a state where all that is true _and_ there 's
| a limitless slurry of effluent from semi-anonymous bad
| faith actors.
| cogman10 wrote:
| SMTP has no authentication, authorization, or encryption
| built in. GSM and the verizon standard do. SMTP abuse is
| entirely down to you being able to fire and forget a
| message without any sort of acceptance criteria for
| downstream systems.
|
| Anyone abusing the mobile network runs the risk of their
| provider pulling the plug and disabling their access.
| hedora wrote:
| I think Signaling System 7 (what the phone networks use)
| might be the only widely-used communication protocol
| that's more open to abuse than SMTP.
|
| With SS7, not only can you spoof any phone number, but
| you can cause the other end of the network connection to
| wire money without getting their prior authorization!
|
| This is improved somewhat by STIR/SHAKEN, but, even with
| that, the state of the art is worse than SMTP.
| gruez wrote:
| > Imagine what things would be like if you could connect
| any compatible device to the phone network for the same
| price.
|
| Can't you already do that today? Just swap your sim card.
| ksjskskskkk wrote:
| you are way out of date on how bad things are.
|
| just moving sim card to another phone will completely
| block you any access until you "reactivate" in the
| majority of telcos around the world.
| gruez wrote:
| >just moving sim card to another phone will completely
| block you any access until you "reactivate" in the
| majority of telcos around the world.
|
| Mind listing those countries? One source[1] for the US
| says that statement is only true for 1 of the 3 major
| telecoms. One of the other two requires an approved
| device to activate the sim, but otherwise doesn't care,
| and the other doesn't care as long as the device supports
| VoLTE.
|
| [1] https://prepaid-data-sim-
| card.fandom.com/wiki/United_States#...
| neverrroot wrote:
| Happy to see these things getting more attention, they are a
| critical part of the modern mobile devices.
___________________________________________________________________
(page generated 2023-12-08 23:01 UTC)