>so I could see if anyone else had a domain with driverhub.asus.com.* registered. From looking at other websites certificate transparency logs, I could see that domains and subdomains would appear in the logs usually within a month. After a month of waiting I am happy to say that my test domain is the only website that fits the regex, meaning it is unlikely that this was being actively exploited prior to my reporting of it.
This only remains true in so far as no-one directly registered for a driverhub subdomain. Anyone with a wildcard could have exploited this, silent to certificate transparency?
A wildcard certificate is only for a single label level, '*.example.com.' would not allow 'test.test.example.com.', but would allow 'test.example.com.'. If someone issued a wildcard for '*.asus.com.example.com.', then could present a webserver under 'driverhub.asus.com.example.com.' and be seen as valid.
Parent comment is making a point that it might have been possible for an attacker to avoid discovery via certificate transparency logs, because anyone 'with a wildcard' could pull off the attack, which is not correct.
I'm pointing out that a wildcard at the apex of your domain (which is what basically everyone means when saying 'a wildcard'), would not work for this attack. Instead if you were to perform the attack using a wildcard certificate, it would need to be issued for '*.asus.com.example.com.' - which would certainly be obvious in certificate transparency logs.
Can you still publicly apply for a “*.*.mydomain.com” certificate? IIRC a wildcard cert starting with “*.*.” allows you to chain 2+ names with that cert, I think? (E.g.: “*.*.example.com” cert would match “hello.world.and.hi.com.example.com”)
I don't know of any CA that allows for wildcard characters within the label, other than when the whole label is a wildcard, but it is possible under that RFC.
> Wildcard Certificate: A Certificate containing at least one Wildcard Domain Name in the Subject Alternative Names in the Certificate.
> Wildcard Domain Name: A string starting with “*.” (U+002A ASTERISK, U+002E FULL STOP) immediately followed by a Fully‐Qualified Domain Name.
Now of course with your own internal CA, you have complete free reign to issue certificates - as long as they comply with the technical requirements of your software (i.e. webserver and client).
Also note that a cert issued as '..example.com.' would only match 'hi.com.example.com.', not an additional three labels.
I think the point is that it wouldn't be silent to certificate transparency, because having a certificate for *.asus.com.example.com would be a clear indication of something suspicious
You're right about the wildcard certificate blind spot. An attacker with a wildcard cert for .example.com could have exploited this without appearing in CT logs specifically for driverhub.asus.com. domains. This is why CT log monitoring alone isn't sufficient for detecting these types of subdomain takeover vulnerabilities.
It's 'driverhub.asus.com.example.com.' not 'driverhub.example.com.', therefore entirely discoverable in CT logs by searching for (regex): (driverhub|\*)\.asus\.com\.
Yeah, sponsor sections of content is usually done respectfully of the audience. There's no javascript being run on my machine, the sponsor is usually tangentially related to the content, and the creator has an incentive to deliver it in either a humorous or relevant manner.
>Yeah, sponsor sections of content is usually done respectfully of the audience.
I literally just LOL'd and spit water at my screen reading that. They are the most condescending over the top waaaaay too long of a segment. Even in the 1950's, sponsors were just mentioned along the lines of "This segment is brought to you by Ovaltine. Remember to drink your Ovaltine!" and then moves right the fuck along. But nooooo, youtube sponsors took the SNL idea of play it until it's uncomfortably long, then keep going until it's just funny that they haven't stopped, but then continue until you just feel like a sad sap for continuing to have this product/service talked about like it is the second coming. Respectful. As. If.
Maybe you should watch other creators then. IME better creators have higher respect for their audiences and create better, even entertaining sponsor segments.
I have even been introduced to services I pay for now via these segments. Nebula, Backblaze, DBrand, and Audible are some of them.
I used to think that too, but then i installed sponsorblock. It's like the skipped segment wasn't even there (well, duh). What i mean is that if i skip a segment of the video and not notice it, was it really relevant and well-integrated?
You weren't introduced to these services, you got advertised to. How many raid shadow legend ads did you sit through to hear about backblaze once? Did you ever hear about backblaze from a more reputable source? Did you consider alternatives to backblaze before paying for their services?
>IME better creators have higher respect for their audiences and create better, even entertaining sponsor segments.
This teeters on the verge of being a shill's comment. This concept of "creators" being any different than any other social media "influencer" that is doing things for clicks/likes/subscribes opposed to "respecting" their audience is just farcical. Are there various degrees of their insincerity, of course.
I never drank the social media Kool-aid. I find it very disconcerting how many people from the social media generations actually believe that these "creators" shilling products are anything more than what they actually are.
Yeah, it's an unfortunate titling of the HN post. Defensive means something different in this context - it's meant for people working within the defensive roles of an organization's infosec department.
Kali are a little to blame here for that confusion as well - "We are making enterprise grade security accessible" - is open to misinterpretation of what they are presenting.
Great presentation. Any thoughts on including these tricks directly into wireshark to allow fluid decryption at least on the Linux client where CAP_BPF is present?
Could be a good weekend project, they already allow importing keys for decryptions so most of the work is finding references where openssl, etc stores it.
Being at the author's talk earlier today, that wasn't really the spirit that it was given in. The author isn't really talking about "defeating" TLS as a technical control more as he is talking about "defeating" it as an annoyance when reverse engineering.
It's meant more as a showcase of how eBPF can be applied to a technical challenge, as opposed to the author claiming they fundamentally broke TLS.
Having been on the receiving end of this as a candidate (not at IBM), everyone was in on the test in the first 15 seconds, and it changed people's behavior instantly.
It's fairly obvious if you're on the receiving end what the purpose of the test is when you're being observed (as with most interview questions, it helps to ask yourself why the interviewer asking me / having me do this?)
Like with those "personality tests" where anyone with decent perception and reading comprehension can easily tell which outcomes each answer's going to push them toward, and so obtain any result they like.
Agreed, but also given they initially thought the aircraft itself was deviating from a stable approach (or at least the ATC transcription appears to suggest that?), perhaps the pilots may have thought the feedback was due to autopilot and not the person sitting next to them.
Make sure you're trying to get into the game mode you downloaded when prompted with "Select game data source" - if it was HLDM, only multiplayer is going to work.
This only remains true in so far as no-one directly registered for a driverhub subdomain. Anyone with a wildcard could have exploited this, silent to certificate transparency?