Are you still only using two factor authentication? I'm way ahead of you with my 7 factor authentication 🔐
Remote
sash
@sash@hachyderm.io
mastodon 4.7.3Writing Python & more 🐍 • internet infrastructure & standards • community organiser • aspiring rustacean 🦀 • Write the Docs • IRRD & BGP • 🏳️🌈🏳️⚧️ • she/they
812 Followers
391 Following
30 Posts
Joined February 09, 2023
www:
mxsasha.eu
ASN:
213279
work:
reliablycoded.nl
Boosted by @trending@homestead.social
I found that crafted MeshCore node names could compromise Home Assistant instances running meshcore-card, with an XSS leading to remote root access on the HA host. An attacker could then access anything controlled or visible through Home Assistant. The attacker doesn't need to be near the target, as MeshCore advertisements are repeated over the mesh, which is dense in NL.
This also affects around 20 public MeshCore analyzer websites. Some of those run CoreScope, where it looks like a vibecoding bot broke the XSS filter while hallucinating a bugfix. The analyzers are mostly public data though. In addition, the less popular MeshCore-Home-Assistant-Panel-v2 is likely also affected, but I was unable to make contact with the maintainer.
MeshCore node names are only 32 bytes, and each rendered in a different place in the page, so I had to be creative to run a more substantial payload. I found a way with three node names using an iframe feature I never heard of before.
https://mxsasha.eu/posts/meshcore-xss-home-assistant/
RIPE NCC made session tokens for the entire member portal available to over 1000 third parties, by design. Full access to the RPKI dashboard, the RIPE Database, and everything else. RIPE NCC had placed strangers under the same domain as their most critical systems.
The RIPE NCC SSO cookie is scoped to `*.ripe.net`, so browsers send it to any HTTPS server under that domain. Atlas anchor hosts and RIPE meeting attendees all had assigned hostnames under that domain, and nothing stopped them from requesting a valid TLS certificate for those hostnames. A single link click was enough to leak the token.
The impact went further than my publication from last week with XSS+CSRF: this allows full session access, including adding admin users and API keys that persist silently.
Full write-up: https://mxsasha.eu/posts/ripe-ncc-sso-cookie-exposure/
Resolved about 3 months after my report, by adding two DNS records. RIPE NCC has not published any acknowledgement of this vulnerability, nor credited me as the reporter on their own channels.
Rooting OpenWRT from the parking lot: I discovered an XSS in the OpenWRT SSID scan page, that can be chained to remote root access 👾
Write-up and demo: https://mxsasha.eu/posts/openwrt-ssid-xss-to-root/
CVE-2026-32721, fixed in 24.10.6 / 25.12.1
A RIPE Atlas probe could have been enough to hijack a RIPE NCC user's next login, giving full access to the member portal, including the RPKI dashboard and the RIPE Database.
I discovered a session fixation vulnerability in RIPE NCC's single sign-on: the session token was not rotated on login. Two ways to exploit it: a new XSS in RIPEstat through DNS NS records, or a free Atlas probe. Anyone with a free RIPE NCC account can host a probe, approved automatically. Installing a web server and serving one HTML page was all it took.
This builds on my earlier posts on the XSS+CSRF exploit chain and session token exposure through CAA misconfigurations: https://mxsasha.eu/posts/ripe-ncc-session-fixation/
The vulnerability was fixed within 20 days. This all took place before my #RIPE92 talk from last week, only some of it made it into that talk. More structural fixes are pending.
Just over 4 years after publishing the first draft, NRTMv4 has been approved by the IESG! This was my first ever IETF draft. This new protocol dramatically improves Internet Routing Registry security and reliability.
All that remains now is the RFC Editor process. Four authors went through 11 versions, 25 reviewers/implementers, dozens of comments, and 5 interoperable implementations. Catch my talk at the #RIPE92 database working group to learn more.
Replying to
My disclosure process with RIPE NCC took 14 months, 26 messages, and included two incorrect fixes for the same vulnerability. I wrote about the process, with thoughts on what better would look like for RIPE NCC and others: https://mxsasha.eu/posts/ripe-ncc-disclosure-retrospective/
Replying to
@litchralee_v6@ipv6.social yes, also because HTML is just one option. Maybe someone puts them in SQL, or LDAP, or shell. Only the code that prepares it for a particular context can know how to make it safe.
Thank you, people of mastodon and reddit ✨I was already aware this is not actually 7-factor auth technically ✨
Also it's a bad idea mainly for other reasons: one glitch in this usb hub could fry all my keys at the same time 🔥
I have been working on a set of vulnerabilities for 14(!) months, but the end is in sight! Just sent the draft blogs to the vendor for review, got € 3200 in bug bounties, and in two weeks I should be able to publish my attack chain on critical internet infrastructure 🕵️♀️
Replying to
The password is #7. And actually there were two more tokens that didn’t fit in this hub :)
Replying to
Replying to
@po3mah@mastodon.social if it's the latest version of meshcore-card, you are safe for the vulnerability I documented it, to the best of my knowledge. And the maintainer of meshcore-card handled my disclosure perfectly.
Replying to
@hrbrmstr Thanks! Plenty of things are broken, I have a backlog of disclosures and posts.
Next week I'll have another RIPE NCC post. That one is a bit harder, but much more rewarding, with full session takeover and persistent access.
Replying to
Replying to
@BafDyce Yeah that took me a bit of time to find. An alert(1) fits easy of course, but I have the most fun if I can show a full running exploitation to something practical :)
Replying to
@nyanbinary yes, although in this case, "administrative" includes almost any RIPE NCC platform, like e-learning courses, the blog (RIPE Labs), running an Atlas measurement, submitting a talk to a RIPE meeting, and so on. The same session token covers all services.
Replying to
@jelte openssl calls this SignatureAlgorithms, and Postfix has no direct option for this, you need to do it through openssl.conf. Here's my latest config for this: https://github.com/internetstandards/Internet.nl/issues/1553#issuecomment-4306775294
Tracking 30 vulnerability findings right now, all variations on the same mistake. Responsible disclosure is getting pretty draining. Vendors range from pretty great to deeply exhausting. Some of this is account takeover, some of it is worse. I do this in my free time, so irresponsible disclosure is starting to sound appealing :)
Replying to
@meph@social.treehouse.systems yes, bots, misconfigured clients, and similar, are sometimes a problem in NL too. MeshCore is pretty easy to DoS even by accident, in EU we also have max 10% duty cycle for transmit.
FIDO2 tokens (like yubikey) are great, but you either want more than one or a good process around recovery codes. Making logins more complicated will lower the risk of account compromise, but increase the risk of locking yourself out. Always have a plan for what happens if a token, phone or other hardware breaks, is lost, or stolen.
Replying to
Replying to
@alex@fedi.smith.geek.nz I can't be sure if ASPA was vulnerable. It's the same GraphQL API, but there is an additional entityTag field, and there are some requirements on it. I can't determine if it's enough to function as a CSRF token.
As it is the same API, it now too has the stricter CORS and Content-Type filters.
My next two posts will cover full RIPE NCC session takeovers, so that one would definitely have included ASPA :)
Replying to
@Hyperlynx it's just a sticker, it's this one: https://www.yubico.com/nl/product/yubistyle-covers-tie-dye-keychain-usb-a-c-nfc/
They make a few other nice ones: https://www.yubico.com/nl/product/yubistyle-covers-usb-a-c-nfc/
Replying to
@uvok there's a lot of these, I've been playing with it a lot over the last year, and I have some more fun ones in my queue waiting for release :)
Replying to
@GoblinKing_f@pawb.fun I don't, they are partially backups for each other. Some off-site, some with me, some at home, some in the office :)