Show newer

Yes, it was definitely a great idea to sync all passwords to people’s Google accounts while making encryption optional and requiring an explicit action to turn it on. 🙄

I’ve written about that a while ago… palant.info/2018/03/13/can-chr

RT @TheHackersNews@twitter.com:

confirmed that it was hacked by the Yanluowang gang after the hackers gained access to an employee's personal account, which contained all the credentials synced by the victim's browser.

Read: thehackernews.com/2022/08/cisc

twitter.com/TheHackersNews/sta

I’ve started publishing my “extension security basics” article series. First article takes apart a very simple extension. Two more are already written, quite a few more are planned.

palant.info/2022/08/10/anatomy

I’ve added another data point to github.com/palant/chrome-exten, now we can compare extension manifests from November 2021 to those from August 2022.

One finding: Manifest V3 usage went up from 3.5% to 16.6% in that time. But >80% extensions are still on Manifest V2.

Interesting. So each and every restaurant website hosted on placejuice[.]com is redirecting to a lottery scam. The malicious script has been present for at least two weeks.

Question is: is this a hack or an exit scam of a free service run by some anonymous? 🤔

It seems that for some people Hacker News is not toxic enough. So they will create those invite-only walled gardens where they can bash other people’s articles without being disturbed. If the author then tries to put things right: “Sorry, you are not allowed to participate. 🤷‍♂️”

The companies who do “damage control” on vulnerability reports by not admitting a vulnerability: do you realize that this strategy also prevents you from announcing having fixed the issue? And that people will keep suspecting forever that you didn’t? Is that really your goal?

Carbon code examples got me confused for a moment: it looks like Rust with some added syntactical bloat. Then I realized that being better than Rust wasn’t the goal. It only needs to be better than C++, yet easy enough to migrate to for existing C++ projects. Fair enough.

Got an email notification saying that is shutting down. Too bad, that was one of the few vendors who handled security issue reports quickly and professionally.

palant.info/2019/07/08/various

And apparently, the answer is: I compile with my own allocator. This way I can not only log all allocations, I can also ignore deallocations to make sure no two data structures share a memory location. Rather smelly code but it works.

github.com/palant/pfp-cli/comm

Show thread

Unbelievable but true: I have it all ironed out. All the implicit input/output buffers, all the timing issues, and even most of the OS-specific weirdness when it comes to searching a process’ memory for leftover secrets. 🥳

Show thread

Got this one figured out: io-streams crate gives me unbuffered input, so no secrets will be leaked via buffers here. Now to the next secret leak…

Show thread

Well, I have a dilemma: reading a password from stdin via usual I/O leaves that password in memory, due to a libc buffer I think. Reading the password properly via rpassword does not but it isn’t compatible with integration tests (the ones searching memory for secrets). Heh…

Show thread

Ok, I’m now using the secrecy crate in my code to make sure no secrets are left in memory. I have automated memory searching and it finds the secrets nevertheless. And now the trick question: how do I figure out which code path left them there? 😅

So malware is abusing Developer Mode to install extensions that share their extension ID with a legitimate Google extension. Pretty clever, and I guess it’s exactly why Mozilla decided against allowing developers install permanent extensions.

blog.zimperium.com/abc-soup-th

Somehow I didn’t see the Soatok vs. Bugcrowd story (twitter.com/SoatokDhole/status) when it happened. Frankly, it doesn’t surprise me the least. Bug bounty platforms currently have two goals:

1. Reduce the effort for vendors
2. Reduce PR damage from disclosures

Keeping vendor’s customers secure is not on the list.

The first one means that vulnerability reports usually aren’t handled by developers but rather by staff of the bug bounty platform who have no deeper knowledge of the product. Hence they must rely on researcher to exactly prove the impact, ideally via a proof of concept.

This is great for the company, they have to “waste” less developer time on handling security reports. Instead this approach shifts the burden onto security researchers. But hey, they are being paid for it, right?

The customers are the ones losing out of course. Bug bounty platforms disincentivize reporting issues which might be considered minor. They also disincentivize reporting out of the box issues. So bug bounty reports will concentrate on obvious targets. palant.info/2017/10/04/observa

And of course bug bounty platforms will retaliate against “unauthorized” disclosure. Their customer is the vendor after all, and they hired them to avoid bad PR. The vendor doesn’t like being called out if they dismiss a valid vulnerability or take years to fix.

For reference: these are largely the reasons why I stopped using bug bounty platforms years ago. I do security research with the goal of making users more secure. For that I need to evaluate the entire attack surface, and disclosure deadlines aren’t optional either.

Today I got reminded that 14 years ago I asked Mozilla to disable dynamic code execution in browser extensions: bugzilla.mozilla.org/show_bug.. 13 years ago this request was rejected because “too late to fix.” Then 10 years ago Chrome devs did it by means of CSP. 🤷‍♂️

Has been more than a year since I created my own Android APK rewriting tools. Took me this long to realize that pattern-based rewriting isn’t the most efficient approach when all I need is to change one class. So it can now just replace that one class. 😅

github.com/palant/apk-instrume

The funny part: whatever vulnerability class I can come up with, I already have a write-up on it (or multiple). So either I’m not imaginative enough, or I really have all of them covered.

Show thread

So the question now is whether I try to make the information easier to digest (and the parts potentially very long) or whether I spit things up even further (10-15 parts?), at the risk of never finishing this. It’s a crazy amount of work…

Show thread

I’m writing a series of articles on extension security fundamentals. I’m at part 3 (out of 5-6) and I can already see that I’m packing way too much information into each part. My goal is making this easier to understand than my typical blog post but I’m not getting there.

Show older
Infosec Exchange

A Mastodon instance for info/cyber security-minded people.