Only tangentially related but I'm a Canadian but have been on a US Cell provider (AT&T) for over a decade now because its cheaper, especially when I used to spend a lot more time roaming in the US. The number of Canadian companies that fail silently when sending SMS to US numbers is too damn high.
My bank is one of those with Verified by Visa. Thankfully I've figured out that using the Voice option instead of Text will work but still that silent failure is really annoying.
I'm not a lawyer so maybe I'm misunderstanding something but the plaintiff is Whatsapp, not the journalists. This isn't really about holding NSO Group accountable for hacking journalists at all
The fact journalists were compromised seems only incidental, the ruling is about weather or not NGO Group "exceeded authorization" on WhatsApp by sending the Pegasus installation vector through WhatsApp to the victims and not weather they were unauthorized in accessing the victims. Its a bit of a subtle nuance but I think its important.
Quoting the judgement itself:
> The court reasoned that, because all Whatsapp users are authorized to send messages, defendants did not act without authorization by sending
their messages, even though the messages contained spyware. Instead, the court held that the complaint’s allegations supported only an "exceeds authorization" theory.
> The nub of the fight here is semantic. Essentially, the issue is whether sending the Pegasus installation vector actually did exceed authorized access. Defendants argue
that it passed through the Whatsapp servers just like any other message would, and that any information that was 'obtained' was obtained from the target users' devices (i.e., their cell phones), rather than from the Whatapp servers themselves
> [...removing more detailed defendant argument...]
> For their part, plaintiffs point to section (a)(2) itself, which imposes liability on whoever "accesses a computer" in excess of authorized access, and "thereby obtains information from any protected computer" pointing to the word "any"
> [...]
> As the parties clarified at the hearing, while the WIS does obtain information directly from the target users’ devices, it also obtains information about the target users' device via Whatsapp servers.
Adding a little more detail that comes from the prior dockets and isn't in the judgement directly but basically NSO Group scripted up a fake Whatsapp client that could send messages that the original application wouldn't be able to send. They use this fake client to send some messages that the original application wouldn't be able to send which provide information about the target users' device. In that the fake client is doing something the real client cannot do (and fake clients are prohibited by the terms) they exceeded authorization.
Think about that for a moment and what that can mean. I doubt I'm the only person here who has ever made an alternative client for something before. Whatapp (that I recall) does not claim that the fake client abused any vulnerabilities to get information just that it was a fake client and that was sufficient. Though I should note that there were some redacted parts in this area that could be relevant.
I dunno, I mean the CFAA is a pretty vague law that has had these very broad applications in the past so I'm not actually surprised I was just kinda hopeful to see that rolled back a bit after the Van Bruen case a few years ago and the supreme court had some minor push back against the broad interpretations that allowed ToS violations to become CFAA violations.
Author of the site here (though not this specific post).
Any chance you could take a screenshot of what your seeing? The other commenter mentioned the contract of comment s in code blocks which I've already noted to fix.
I run a markov chain bot in a Twitch chat, has some great moments. I tried using a LLM for awhile, would include recent chat in the prompting but never really got results that came across as terribly humorous, I could prompt engineer a bit to tell it some specifics about the types of jokes to build but the LLM just tended to always follow the same format.
Standard way being trying to measure the precise differences between requests. The smaller the difference the more requests are needed to level things out and that just becomes pretty impractical quickly but still possible in some situations.
If you actually wanted to do a timing attack on the web you'd probably want to do something like a "Timeless Timing Attack" [0]. At a high-level the idea is to measure relative timing differences rather than the precise difference. Answering which request completes faster rather than how much faster.
The specific attack from the paper is taking advantage of HTTP/2 multiplexing to send two requests within a single packet, ensuring they arrive at the same time. Then uses the response order to determine which was processed faster/slower. It still requires making multiple requests to smooth out the data just not as much since you're only interested in the relative competition time.
Its not practical everywhere, but its more practical for the web than the traditional technique.
Binja decompiler is more-or-less fine. Its not as mature as IDA or Ghidra but its not a bad decompiler.
Though for me the big selling point on Binja is the Intermediate Languages (ILs). HIgh-level IL is the decompiler but you also get Low-level and Medium-level ILs as steps between assembly and source. If the decompiler is a bit funky you can look at the ILs to get a better idea of what is happening. the ILs are also just much nicer to read than plain assembly so I tend to use them a lot.
Its a feature that isn't really matched on any other platform. Ghidra and IDA both have a single IL that is more machine readable compared to Binja's human-readable ones.
First, just a high-level overview over how it would work as an app/consumer which is not terribly centralized outside of requiring browser support:
Passkeys are an open standard, and they basically are just public/private keys with a wrapper. When you create a credential which is just a call to `navigator.credentials.create` with options to indicate a PublicKeyCredential type and that it should be a client-side discoverable key and a user ID to associate with it (and some optional info). Its gives you back some meta-info and the public key to store.
For a login flow, similarly a call to `navigator.credentials.get` indicating you want one of those discoverable keys to be used and a challenge. The browser returns a signature to you along with the key info (that user ID from the creation) and you are responsible to verify the signature is appropriately signed.
---
So, on the actual crypto side, nothing about it requires any centralization, there is no required phoning home or to a remote source. On the creation/storage/retrieval side, the WebAuthn Authenticator Model is defined as part of the standard so anyone can implement it. I don't know enough about how you'd register as such an authenticator. Dashlane already supports passkeys, so it is possible for a third-party to do so, Bitwarden and 1Password are also working on it.
So my understanding would be that self-hosting is more just a matter of giving it time for others to implement the necessary components and not there being any restriction on who can do this.
Its not just historically (atleast if you include IoT/Industrial/Medical devices) Microsoft's "Section 52" (IoT security research group) called out this issue in several allocators used in IoT in April 2021 [0][1].
It is, it'll build a few fuzzers hitting different areas[0]. The important function in many of those `.c` files is `FuzzerTestOneInput` which is effectively the entrypoint for a single fuzz test.
Taking a look at x509.c[1] which I believe is the most likely to be able to reach the punnycode parser. (I am not at all familiar with the codebase). You can see that the OpenSSL fuzzer is basically doing a holistic fuzz (I assume the i2d* and d2i* functions exercise the parser), that is its just invoking key entrypoints that in theory can exercise all the rest of the functionality with the correct inputs.
Hanno's fuzzer on the other hand, is explicitly only testing the `ossl_punnycode_decode` function[3].
Given the breadth of the fuzzer, I think its very possible OSS-Fuzz just didn't hit it.
So "pentesting" often kinda defaults to "network pentesting" which is closer to an IT job than a software engineering job and its salary range (in general, as you specialize pay goes up regardless).
But there is "application penetration testing" and just application security in general which tends to pay competitively with software engineering. And of course plenty of people do both at the same job.
So pentesting can be competitive but it depends on definitions a bit. That said on the upper end, software dev tends to have more chances to get a big exit by being part of building something. In security you might be with a consulting firm where you have a slight chance at that, but its not common for a security guy to have that sort of big exit.
This is a bit of a common trap, the idea that to do anything you must know everything. When you read writeups you see people just going from some bug to exploit and incorporating obscure bits of knowledge to make it happen. It feels like they must know everything. The reality is they probably spend hours or days banging their head against a wall having an intuition that _something_ is wrong but no idea how to abuse it or that there must be something. Spending hours researching until they can connect the dots. Those hours of frustration are not captured very well in most writeups.
> I know for stuff like this the key is to just get started, and the understanding will follow, but I'm curious if anyone has any recommendations for how to do that.
The single tip I give anyone getting started is:
Follow all the rabbit holes.
Seriously, all of them. Any time you have some random question come up, "Would doing X be vulnerable", "Could I exploit Y feature", "Why didn't this writeup author do Z", "How does A work", "Why send B this way instead of this way" ... all of them. When you have the question, just go spend the time to figure it out. Every rabbit hole you go down, even if it ends up being a dead end, is adding bits and pieces to your knowledge. Over time you build up an immense library of random bits of knowledge that you can draw from in the future.
While I wrote that with an eye towards doing binary-level exploit development against modern targets, the advice for doing manual auditing is pretty universal. It's like how to learn to program you actually have to write code, reading about writing code isn't enough. Practice against anything can be useful.
I'll also leave you my favorite vuln research quote:
"Frustration is a key part of exploit research and you must embrace it accordingly"
Funnily, both ExpressVPN and NordVPN which you call out have been externally audited.
NordVPN had the clients audited by VerSprite last year, and their No-log policy audited by PwC in 2018 and 2020. And a bug bounty program on HackerOne. [1]
ExpressVPN - Windows Client was just audited by F-Secure in March, and server side audits by Cure54, and PwC in 2021 and 2019 respectively. And a bug bounty program on Bug Crowd. [2]
---
For comparison
Mullvad has been audited (Client security and Infrastructure (for privacy)) by Cure53 through 2020, and first was in 2018. Has no bug bounty, but they do still have a vulnerability disclosure program. [3]
ProtonVPN, audits of the no-log policy in April, and clients in 2020. And they run their own bug bounty program.[4]
---
I actually find it kinda interesting that while they've all had audits regarding privacy on the server side, only ExpressVPN has had a security audit of server side components. (Granted I've not look that deeply at this)
[1] Annoying, you can only download the audit reports if you Login then click Reports in the menu
Unfortunately many parts of this paper are beyond me, but this study does appear to find that community level masking has an impact, but it is a study that used actual communities and tracked compliance (and impact of different interventions on encouraging making)
On a whole what I found more interesting here was just the techniques they came across through fuzzing that had some impact. Yes its interesting to see the specific combinations that were impacted, but in the real-world there are so many other potential combinations.
The dominate method for request smuggling as of the last few years has been with `Content-Length` and `Transfer-Encoding`. What I found most interesting and the biggest take-away as someone who has worked doing web-app assessments is more just the attacks that they found to work and cause problems.
I mean the details about particular server pairs having issues is great information, as is the fuzzing setup (great use of differential fuzzing) but I think more important is being able to take these potential attack avenues that they had success with and running them against your own deployments. Given how many applications internally are running their own stacks there is still a lot of room for potential issues. I can imagine people running with some of these for bounties in the near future.
A brief summary of the manipulations they had some success with are on pages 7-8. Though if you don't feel like reading, the "headline" version of the list gives you a pretty decent idea of what was having an impact:
So, disclosure policy is kinda an active discussion within the security community but there is a general move away from coordinated disclosure (aka responsible disclosure) where the vendor and reporter coordinated on disclosing the vulnerability, not publicly disclosing until the vendor okays it.
Coordinated disclosure puts a lot of power in the vendor to simply ignore or delay fixing issues, and frankly may not actually be the "responsible" course of action. Full disclosure, where the first warning anyone has about the issue is when all the details are dropped about it to the public _may_ result in a faster patch time but it also increases risk of it being weaponized during that in-between period. There is the chance it was being used in-the-wild without being known also, but releasing the information increases the risk of those in the-wild-attacks but reducing the overhead necessary to carry them out.
All that said, there is a newer option that has been pretty steadily gaining popularity over the last seven or so years. Deadline-based disclosure. This did exist before, but really gained popularity in recent years as Google's Project Zero adopted it as their disclosure policy. This is the idea where the reporter discloses a vulnerability which starts a countdown to the public disclosure (90 days is fairly common, but I've seen 30, 60, and 180 reasonably often also)
I think this deadline-based disclosure option strikes a good balance between the benefits of coordinated, and full disclosures.
Kinda on a related note I found myself needing to make a bunch of these sorts of scraped feeds. The problem for me was the lack of date parsing support which I sorely needed (and it doesn't appear like this option supports it either)
I did write it specifically for my use-case so there are some "warts" on it like custom generators for HackerOne and Google's Monorail bug tracker. But perhaps someone else might benefit from its ability to create slightly more complicated RSS, Atom, or JSON feeds.
https://github.com/minimaxir/hacker-news-undocumented/blob/m...