Matthew Bryant
thehackerblog.com · Personal blog · on HN since 2013
Matthew Bryant, a security researcher, writes up vulnerabilities he found, including takeovers of TLDs, Signal Desktop RCE, and npm domain issues.
What HN saysHN cites it in security discussions, notably the Signal Desktop remote code execution bug and a post on NoScript's limitations.
48HN people shared it
19linked it in comments
51stories submitted
3.1Kstory points
2 years agolast shared
2013people per year2026
Most-shared posts
- 1Taking control of all .io domains with a targeted registration5 people · 1.4K points · first shared 2017 · 246 comments on HN
- 2Gaining control of a .int TLD4 people · 11 points · first shared 2016 · discussion on HN
- 3I too like to live dangerously accidentally finding rce in signal desktop via html injection in quoted replies4 people · first shared 2018
- 4Index4 people · first shared 2017
- 5Sonar – A Framework for Scanning and Exploiting Internal Hosts with a Webpage3 people · 3 points · first shared 2015 · discussion on HN
- 6The NoScript Misnomer2 people · 275 points · first shared 2015 · 66 comments on HN
- 7Obtaining Wildcard SSL Certificates from Comodo via Dangling Markup Injection2 people · 260 points · first shared 2016 · 58 comments on HN
- 8Compromising Angular via expired NPM publisher email domains2 people · 198 points · first shared 2022 · 75 comments on HN
- 9Taking Over 20K DigitalOcean Domains via a Lax Domain Import System (2016)2 people · 122 points · first shared 2019 · 51 comments on HN
- 10The Journey to Hijacking a Country’s TLD – The Hidden Risks of Domain Extensions2 people · 59 points · first shared 2017 · 7 comments on HN
- 11How I Got 5,000 GitHub Followers In Less Than 24 Hours2 people · 8 points · first shared 2013 · 6 comments on HN
- 12The International Incident – Gaining Control of a .int Domain with DNS Trickery2 people · 6 points · first shared 2016 · discussion on HN
- 13Hacking Guatemala’s DNS – Spying on Active Directory Users via a TLD Misconfig2 people · 4 points · first shared 2017 · discussion on HN
- 14Same Origin Policy Bypass (~8M Users Affected)2 people · 4 points · first shared 2018 · discussion on HN
- 15Obtaining Arbitrary Wildcard SSL Certs from Comodo via Dangling Markup Injection2 people · 2 points · first shared 2016 · discussion on HN
What HN people wrote when they linked it
woojoo666 · 2022-10-08
I completely understand the difficulty, but so far I haven't heard of whether or not Signal is even working on getting rid of phone numbers.
Also worth mentioning that Matrix isn't just working on encrypting contacts databases. They are also working on decentralization, which is a much more difficult problem. So I'm not surprised that they are running into issues every once and a while (though Signal has had security problems in the past too [1])
[1]: https://thehackerblog.com/i-too-like-to-live-dangerously-accidentally-…
Arathorn · 2022-10-02
Signal has security bugs line the best of them. The most famous is probably https://thehackerblog.com/i-too-like-to-live-dangerously-accidentally-… - which gave full RCE, letting the attacker steal all your messages or worse.
The two critical bugs in question here were similarly implementation bugs in matrix-js-sdk and its derivatives.
Separately, there’s a question over the fact Matrix by design controls group membership on the server… and warns users if malicious devices get added, rather than explicitly forbidding them. We’re fixing that anyway, but it’s questionable if this counts as “issues with e2ee” - it’s similar to deriding Signal for pushing all the users in your addressbook when you join the app(!)
Aissen · 2018-05-18
From the researcher who found it:
we were able to compile a list of strategic defense-in-depth recommendations for Signal Desktop which we’ve sent to the Signal security team per their request. At the end of the day there will always be new “hot” vulnerabilities, but the “vendor” response is generally what separates the wheat from the chaff. The Signal team’s quick patch time along with a strong interest in mitigating vulnerabilities of this type in the future was encouraging to see. I’ll remain a Signal user for the foreseeable future :)
https://thehackerblog.com/i-too-like-to-live-dangerously-accidentally-…
seanp2k2 · 2015-07-01
No disagreement on Ghostery; that got uninstalled real fast when I figured out what they were really up to. While I agree that NoScript helps, it doesn't prevent everything either: https://thehackerblog.com/the-noscript-misnomer-why-should-i-trust-vjs…
I used to be a big RequestPolicy believer, but single-page apps (which feels like saying "horseless carriages" in mid-2015) make it a lot of work. https://github.com/gorhill/uMatrix/wiki/Changes-from-HTTP-Switchboard is the best thing I've found if you're into granular control over sites. uBlock also has an ~"I'm an advanced user" option which will give you a little more blunt but still useful control over cross-site requests.
MarkTee · 2013-11-12
The author details how he did it here:
http://thehackerblog.com/how-i-got-5000-github-followers-in-less-than-…
cbxyp · 2024-05-10
I guess the most backdoor-looking bug I've ever seen (referring of course to Signal Desktop's usage of React's __dangerouslySetInnerHTML to render user-supplied messages in a Node.js privileged context) is below the technical authors paygrade. (https://thehackerblog.com/i-too-like-to-live-dangerously-accidentally-… - CVE-2018-11101
rvz · 2022-09-07
> You have more control over it, and it is fully accessible from the open web.
Do you want this again? [0] [1]. The so-called 'open web' is complete nonsense which technologists at large tech companies have taken control to push on their next grifting and surveillance products.
For example, Google Chrome being used as the dominant browser and Google already leading control over web standards, privacy violations and sabotaging other browsers like Firefox for their own gain.
There is no such thing as the 'open web'.
[0] https://news.ycombinator.com/item?id=21611677
[1] https://thehackerblog.com/the-io-error-taking-control-of-all-io-domain…
miles · 2020-05-16
Just tested in Windows with a registry file generated via the linked web interface[0]. Dark Reader was not prevented from accessing sites that should have been excluded based on the imported policy, even after a reboot. Has anyone successfully tested Chrome Galvanizer?
[0] https://thehackerblog.com/galvanizer/
agwa · 2020-01-31
They absolutely can. Just one example of how ICAAN regulation helps: ICAAN requires that the .org registry let domain owners lock in their current price for 10 years if a price increase is announced, and prohibits different renewal prices for different domains. ccTLDs can just increase prices with no notice, or price gouge popular domains.
And .io is certainly worse than .org will ever be - there have been numerous security outages of the .io name servers and one very bad security incident: https://thehackerblog.com/the-io-error-taking-control-of-all-io-domain…
wolf550e · 2019-09-16
The io cctld authoritative dns servers are not very competently run. There have also been security issues like https://thehackerblog.com/the-io-error-taking-control-of-all-io-domain…
'tptacek would add that a cctld that is under control of the five eyes governments is less secure because the registry can be interfered with more easily than .com, though I think that's kinda theoretical.
jbergstroem · 2019-02-04
For those who host their own email (read: use your own domain for incoming), I'd like to remind/raise awareness about using `.io` which had two pretty serious security incidents recently (<3 years). Last incident: https://thehackerblog.com/the-io-error-taking-control-of-all-io-domain…
foepys · 2018-05-16
Here is the obligatory post about how bad .io treated security less than 1 year back [1]. Someone was able to take over the whole .io zone just by registering a few domains.
1: https://thehackerblog.com/the-io-error-taking-control-of-all-io-domain…
dten · 2017-09-20
I wonder if they messed up again and let someone register the .io nameservers
https://thehackerblog.com/the-io-error-taking-control-of-all-io-domain…
cjsuk · 2017-08-03
This is sensible. Also the established TLDs seem to have a larger clue stick. Look at the recent .io domain shenanigans: https://thehackerblog.com/the-io-error-taking-control-of-all-io-domain…
mcbruiser3 · 2017-07-10
what about someone social engineering the registrar [1] or hacking the TLD nameservers [2] and getting control of all your accounts using that email?
[1] https://medium.com/@N/how-i-lost-my-50-000-twitter-username-24eb09e026…
[2] https://thehackerblog.com/the-io-error-taking-control-of-all-io-domain…
hannob · 2017-04-10
Appart from DNS many CAs do web or email based checks. And those had quite a few vulnerabilities in the past, e.g. in the extraction of whois records (via OCR...) [1] or through markup injection in the validation emails [2]. CAA can prevent misissuance in such cases.
Having an extra safety layer around these is definitely useful. It's not a super strong measurement like HPKP and CT, but still I think CAA is a useful extra security mechanism in the CA ecosystem.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1311713
[2] https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcar…
tyingq · 2016-10-22
This is an interesting approach to get past NAT: https://thehackerblog.com/sonar-a-framework-for-scanning-and-exploitin…
coldpie · 2015-07-01
> While I agree that NoScript helps, it doesn't prevent everything either: https://thehackerblog.com/the-noscript-misnomer-why-should-i...
This is just a default whitelist that's trivial to remove. Yes, it's dumb, but it doesn't completely compromise NoScript if you're aware of the whitelist.
hepha1979 · 2015-10-08