kdbg

Its one of the features that is behind a minimum karma requirement.

https://github.com/minimaxir/hacker-news-undocumented/blob/m...

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.

Edit: Adding a link to the judgement for anyone interested: https://storage.courtlistener.com/recap/gov.uscourts.cand.35...

Edit2: And CourtListener if you want to read the other dockets that include the arguments from both sides (with redactions) https://www.courtlistener.com/docket/16395340/facebook-inc-v...

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.

curious what type prompting you do on the LLM?

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.

Reminds me a little of a stored XSS I read about last year.

https://tttang-com.translate.goog/archive/1880/?_x_tr_sl=aut...

Had that same root of not having the mime.types in the container, leading to server-side sniffing of the mime type for the Content-Type header.

It's just a bit interesting the impact such a file can have

You can, but maybe not in the "standard" way.

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.

[1] https://www.usenix.org/conference/usenixsecurity20/presentat...

Thanks for this, was trying to wrap my head around it a bit and you broke it down nicely.

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.

Pretty sure that price is only for your first year if you sign up with a code/link from one of their creators.

The advertised rates are currently $5/month or $50/year.

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].

[0] https://msrc-blog.microsoft.com/2021/04/29/badalloc-memory-a...

[1] Full list: https://www.cisa.gov/uscert/ics/advisories/icsa-21-119-04

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.

[0] https://github.com/openssl/openssl/blob/master/fuzz/

[1] https://github.com/openssl/openssl/blob/master/fuzz/x509.c

[2] https://twitter.com/hanno/status/1587775675397726209/photo/2

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.

I have a blog post about getting started with manual vulnerability auditing: https://dayzerosec.com/blog/2021/05/21/from-ctfs-to-real-vul...

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

[2] https://www.expressvpn.com/blog/?s=audit

[3] https://mullvad.net/en/blog/tag/audits/

[4] https://protonvpn.com/blog/?s=audit

https://www.science.org/doi/10.1126/science.abi9069

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:

Request Line Mutations

- Mangled Method - Distorted Protocol - Invalid Version - Manipulated Termination - Embedded Request Lines

Request Headers Mutations

- Distorted Header Value - Manipulated Termination - Expect Header - Identity Encoding - V1.0 Chunked Encoding - Double Transfer-Encoding

Request Body Mutations

- Chunk-Size Chunk-Data Mismatch - Manipulated Chunk-Size Termination - Manipulated Chunk-Extension Termination - Manipulated Chunk-Data Termination - Mangled Last-Chunk

---

And a bit of self-promotion but we talked about this paper on Monday on the DAY[0] podcast I cohost (24m53s - 35m30s) https://www.youtube.com/watch?v=GmOuX8nHZuc&t=1497s

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.

Fwiw there was a good talk from Ben Hawkes about Project Zero's Disclosure Philosophy at FIRST 2020, https://www.youtube.com/watch?v=9x0ix6Zz4Iw

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 ended up writing my own CLI tool that similarly supports CSS selectors for feed generation: https://github.com/dayzerosec/feedgen

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.

Example config with date parsing: https://github.com/dayzerosec/feedgen/blob/main/configs/bish...

So kinda a quick summary given the available information that I've seen.

Back in August 2020 some research was performed looking at introducing vulnerabilities into the Linux Kernel.[0] The paper indicates that three patches were submitted via anonymous gmail accounts to the mailing list and were never committed. The reviewers were provided a proper patch upon accepting the vulnerable one and received explicit confirmation that the maintainers would not move forward with the vulnerable patch.

I'm not sure when exactly questions started being raised about that research. Though I first became aware of it in December. The discussion was mostly around the human involvement and led to the prepublication of the paper being removed and clarifications being issued.[1]

Fast-forward to April 2021. The patch seems to have kicked things off[2]. This was called out as being an impossible situation, and as being a "known-invalid patch" by Greg KH [3].

It appears that at least three patches by this same author introduced vulnerabilities[4] according to Leon Romanovsky. Though I don't have links to the specific patches.

Leading to U.Mn's ban from contributing to the kernel by Greg KH[5]

---------

What is in my opinion unclear at least to me is whether these more recent patches are actually in bad faith or just simply bad. The prevailing theory is that they are part of more research into introducing vulnerabilities. As already stated though, that research and its paper were done in August of 2020. The more recent commits, the official story from Kangjie Lu, Qiushi Wu, and Aditya Pakki[6] are that they are part of "a new project that aims to automatically identify bugs introduced by other patches". This does somewhat align with statements[7] made indicating that the commits were from a static analysis tool being researched which was made prior to this blowing up. Though I will note that the author of that patch was _not_ one of the authors of the apology letter, so may genuinely be unrelated.

This tool story was not believed by Greg KH[8].

And his take is the one that has gained a lot of adoption. That these patches were intentionally made in bad faith for another paper.

I will state that the newer patches that caused problems did _not_ follow the methodology that the original research followed to try to prevent vulnerabilities from actually being introduced into the repo. The original paper, while certainly had issues with methodology and experimenting on people inappropriately, did take steps to prevent any actual vulnerabilities from being committed, whereas the ones in question did not, and even made it to stable branches.

If the official story from U.Mn is true the commits should also have been noted as having been found by a tool, and followed the proper procedure for that, which they did not do. Though it does appear that the vast majority of the patches that were reverted were legitimate patches.[9] Atleast spot checking replies on that mailing list.

I mean on a whole the original research was questionable, but I kind of want to be more charitable in my interpretation of the more recent events but honestly that original patch that kicked things off is pretty bad.

[0] https://github.com/QiushiWu/QiushiWu.github.io/blob/main/pap...

[1] https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....

[2] https://lore.kernel.org/linux-nfs/20210407001658.2208535-1-p...

[3] https://lore.kernel.org/linux-nfs/YH5%2Fi7OvsjSmqADv@kroah.c...

[4] https://lore.kernel.org/linux-nfs/YH+zwQgBBGUJdiVK@unreal/

[5] https://lore.kernel.org/linux-nfs/YH+7ZydHv4+Y1hlx@kroah.com...

[6] https://lore.kernel.org/lkml/CAK8KejpUVLxmqp026JY7x5GzHU2YJL...

[7] https://lore.kernel.org/lkml/CAAa=b7dnrz5Pz5hMUc29VHJb9ucFkW...

[8] https://lore.kernel.org/lkml/YH%2FfM%2FTsbmcZzwnX@kroah.com/

[9] https://lore.kernel.org/lkml/202104221451.292A6ED4@keescook/

The paper was already withdrawn. https://www-users.cs.umn.edu/~kjlu/papers/withdrawal-letter....

I don't think there have been any recent comments from anyone at U.Mn. So, back when the original research (happened last year) the following clarification was offered by Qiushi Wu and Kangjie Lu which atleast paints their research in somewhat better light: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc....

That said the current incident seems to have gone beyond the limits of that one and is a new incident. I just thought it would be fair to include their "side"

https://dayzerosec.com - We do a weekly security podcast on exploit development and related topics/research.

Its a pretty niche target audience so its unlikely to make money or be any sort of object success. But its self-fulfilling; it has been great for keeping me on top of new research and trends that impact my job.

While Phrack has stopped, there is the Paper Feed (no generic link, just have to link to the latest in the feed) http://phrack.org/papers/escaping_from_freebsd_bhyve.html

I think one big change these days is just that more people will self-publish their writeups and research. There are also a lot more security conferences that people present at some with a more narrow focus than the well known conferences too leading to more specialty content.

I do a weekly podcast[0] talking just about the latest exploits and strategies/research from the last week and pulling content for that is basically just following a ton of RSS feeds. There is a lot more getting written these days compared with the years when Phrack was regularly released. Unfortunately its also more spread out and harder to find.

[0] https://dayzerosec.com

Are there stats, not that I'm aware of. There might be its just not my area. I am more aware on the exploit development side of things though.

The process of going from a bug to a weaponized exploit though is still largely manual. Yes some tooling exists that may automate certain tasks, however these tools often only work as proof of concepts. ROP compilers are a great example, they "work" but they are are usually far more prone to crashing than one compiled by hand, as such wouldn't be used in the real world.

Thats just kinda the general truth, ignoring the many cases where the automated offering just don't work at all, when they do its often not weaponized to a useful degree. You might thing that you could then use what it does as a starting place, but it takes a lot of time to now reverse what the script did and figure out what can/should be changed, similar to having just done it yourself in the first place and not being constrained.

That said there has been some research in augmenting the workflow by discovering exploit strategy candidates. I forget the name right now, but there was a paper early this year presenting a capability guided fuzzer that focused on "fuzzing" OOB Write vulns to expand them and discover viable exploit strategies for them.

Unfortunately OSCP/PWK is their only course that has that open lab environment to learn through failure.

In the other courses the lab is just a server or two running the vulnerable programs covered by the walk through in the course material.

Hey, I'm one of the hosts of the podcast (zi).

I co-host with Specter (and sometimes Anti, a friend who works in threat intelligence) and we both do vulnerability research and exploit development. Neither of us are world-renown security experts or anything but we do get our hands dirty at a technical level, a perspective we think has been missing in other security podcasts. Specter's best known for his work in the PS4 scene, whereas I've been quietly working in appsec doing manual security assessments for most of the last decade, and was a magician turned developer before that.

I'd be the first to admit that there are some individuals where who on HN that have forgotten more about this than I've ever known. None-the-less we thought there would be some interest at least within our little niche in hearing the thoughts and discussion from a couple of guys who are in the weeds of exploit dev. We make mistakes and are open to being corrected.

Most episodes have three rough sections, we start off talking about news and some soft-topics. This week, a bit about a ransomware campaign, a "$500k" Zoom vuln and Binary Ninja's new decompiler/HLIL. Then we move into talking about exploits released or detailed in the past week, this week included some stupid issues like an OTP disclosure ("the request which sends the OTP also returns the OTP in the network response"), and some lower-level privilege escalations impacting Linux, Windows, and Solaris (whodo/w buffer overflow).

Ending with some research, often fuzzing or exploit mitigation related but really on a whole we just talk about things we find interesting.

We are available on all the major podcast platforms if you search for dayzerosec, but we also stream it live on Twitch (@dayzerosec), Mondays starting at 3 pm Eastern and take questions from the chat as we go.

I'd love feedback on all levels from content to distribution and quality issues.

While I didn't have high hopes to get a summary of a technical paper, since I spend a good chunk of time every week reading some related to exploits and mitigations for a podcast I host, I hoped this might help reduce time spent trying to get an overall understanding before diving into the details.

It actually did better than I expected with the paper "Bypassing memory safety mechanisms through speculative control flow hijacks" [0]

I copied and pasted the text from sections 3-7 (Case Studies - Conclusion) and Section 2 on its own (describes the attack)

It did pull out some important statements, better than I expected. Probably won't save me much time, but I was quite disappointed by the fact that the Advanced and Basic versions were the same for both which kinda felt a bit cheap to get the same results especially since it still cost to get that advanced result. Maybe including information about how the basic version is restricted and what the advanced does better would make it easier to know when the advanced version won't be useful.

I also tested with a random write-up I'll be covering tomorrow "Breaking the Competition" [1] I had higher hopes for this since it was more of a blog-ish post. I did get different results for basic and advanced with this one, but the result was basically non-sense, worse than expected, and worse than the paper summary.

Overall, probably not something that I'll end up using, but technical content also isn't the intended use-case which is totally fair. I'll also add that one feature that I looked for immediately was API access as I'd have wanted to integrate this into an app I use to plan episodes.

- [0] https://arxiv.org/pdf/2003.05503v1.pdf

- [1] https://medium.com/ctf-writeups/breaking-the-competition-bug...

Not exactly the same but https://portswigger.net/web-security has several good lessons and labs about specific attacks.