kafrofrite

Disclaimer: I work as a sec engineer and part of my job includes finding vulnerabilities.

I think the effort is misplaced. We should be exploring ways to make our systems more resilient and I would expect those companies* to focus on that front. Vulnerability research is important, and we should aim to remove as many bugs as we can from our codebases but the pace of software development is increasing and so is the introduction of new bugs.

* I would also expect an increase on relevant research regarding novel paradigms of securing systems.

I was once asked what's my favorite starter Pokemon in some specific edition of the game. I was baffled to put it mildly. Some other guy from the team jumped in and pretty much said "disregard that question"

IIRC, around 2016 or so, Slack invited us in their office to pitch us the enterprise version and ask whether we would be interested in becoming one of their first enterprise customers. Among other requests, one colleague asked me to ask them to not kill their IRC gateway. One of their PMs looked at me and told me “No, we are not doing this”.

I guess there's merit for that, especially if you are in a cloud environment. In a previous company, I decided to set up dnf/kpatch for VMs that we considered critical. At the time I had a healthy disregard for reliability, mostly because we had enough trust in our terraform process so I decided to automate the whole thing through AWS System Manager across the fleet and guard the feature to work only for security patches targeting the kernel. Briefly, every VM that came up would have the necessary packages installed and from there live patching would execute periodically (I believe once a week) or manually. At some point after a quarter or something we had to devise a way to tag VMs to be excluded from this but this was relatively easy to do and most of the exclusions were testing infra anyway.

Please do share

It's probably not trivial to implement and there's already a bunch of problems that need solving (e.g., trusting keys etc.) but... I think that if we had some sort of lightweight code provenance (on top of my head commits are signed from known/trusted keys, releases are signed by known keys, installing signed packages requires verification), we could probably make it somewhat harder to introduce malicious changes.

Edit: It looks like there's already something similar using sigstore in npm https://docs.npmjs.com/generating-provenance-statements#abou.... My understanding is that its use is not widespread though and it's mostly used to verify the publisher.

The answer to your question is WebKit (because iOS), kernels (XNU, Linux, Windows) etc. In case you are not familiar with the domain I'd start with user-space exploitation and relevant write ups to get my feet wet. You'll find plenty of write ups, blogs etc. so I'll skip those. Some of the books I generally found interesting are [1],[2], [3]. There's more to that, including fundamental concepts of CS (e.g., compilers and optimization in JITs, OS architecture etc.). I believe also https://p.ost2.fyi/dashboard has some relevant training.

[1] https://nostarch.com/zero-day

[2] https://nostarch.com/hacking2.htm

[3] https://ia801309.us.archive.org/26/items/Wiley.The.Shellcode...

Most probably what Apple means is that since their codebase is shared, the vulnerability exists across devices. This does not mean that the vulnerability is actively exploited in iOS nor that it will not be actively exploited as part of some other campaign.

> Has this happened before? That iPhones had a security hole that could be exploited over the web? Yes, there were exploits in the past that could be exploited remotely, including some that were used for jailbreaking.

I work as a security engineer and, yes, the CT logs are extremely useful not only for identifying new targets the moment you get a certificate but also for identifying patterns in naming your infra (e.g., dev-* etc.).

A good starting point for hardening your servers is CIS Hardening Guides and the relevant scripts.

IIRC, in [1] it mentioned a few examples of AI that exhibited the same bias that is currently present in the judicial system, banks etc.

[1] https://en.wikipedia.org/wiki/Weapons_of_Math_Destruction

I'm not a fan of Windows but Stuxnet didn't happen because of Windows. Iran decided to spin up a nuclear program and Israel and the US had concerns and wanted to stop it. They had the resources to develop something tailored for this unique situation, which included windows, Siemens PLCs (IIRC), Centrifuges etc. and developed the malware based on their target. Even if their target used a different stack, they'd find a way to achieve the same result.

I'll try my best to explain everything (trying to avoid too much security lingo, hopefully).

A password manager is a big database of passwords. There is a master password that decrypts the database and from there you can use your passwords. Notice that hashes are one-way operations thus not used in password managers. The benefits of using a password manager are that that users need to remember and handle only one password, that of their password manager, the rest of the passwords are unique and can be rotated quickly. Ideally, your password manager does a few more things, including taking precautions against leaving traces of passwords in memory etc.

There's another part of commercial password managers which is mostly convenience functionality. Passwords are synced across devices, specific members access specific passwords etc.

Some people do use local password managers, depending on their threat model (i.e., who's after them) and their level of expertise/time on their hands. Setting up something locally requires taking additional precautions (such as permissions, screen locks etc.) that are typically handled by commercial password managers.

Reg. Okta, Okta is an identity provider. In theory, identity providers can provide strong guarantees regarding a user, i.e., "I authenticated him thus I gave him those token to pass around". Strong guarantees can include a number of things, including Multi-factor Authentication, VPN restrictions etc.

Funny story: during an internal red team engagement on a previous employer of mine, we took over the local password manager of a subset of the security org, twice. The first time, they had a VNC, unauthenticated, with the password manager running and the file unlocked. The second time, a team conveniently used Git to sync their password manager file, with their password tracked.

Most providers had a semi-automated process that granted you permission to conduct your pentest (assuming you'd share any findings reg. their infra with them). In reality though, most of the findings didn't come from poking around but from tapping the wire. I'd spin up VMs and tcpdump for hours, then look at the logs for odd packets, plaintext etc. etc. which makes it hard to detect such shenanigans

Edit: We went through the process for everything, including having a provider ship us a back-up solution to pentest. My desk became everyone's favourite place in the building :P

Reminded me of a funny story. Maybe a decade ago, when moving to the cloud was all the rage, my then employer decided to check whether the cloud was any good. Long story short, he asked me to conduct penetration tests against the major providers. In one of the providers I pivoted through some network and hit a webpage that looked like some sort of control plane panel (but required authentication so...). I decided to google part of the HTML and... A stack overflow thread pops up with the code and parts of the backend code/logic. So much win.

IIRC, Intel announced about a year later plans to develop something similar. That being said, at the time they didn't have a specific timeline.

> I don't think OS becomes any less vulnerable than usual Linux/Windows installation.

is not a good enough argument.

For the story, SIP is Apple's "rootless". Effectively the OS runs with less privileges than root. Disabling SIP significantly increases the attack surface.

That being said, I'm grateful that someone decided to do something more native for containers in macOS.

DEP is a Windows implementation of a non-executable stack, i.e., memory permissions that do not allow execution on specific pages. Depending on the situation, an attacker can e.g., mmap() a new page with the execute permission set, write his shellcode there and jump there. Another way to bypass the NX bit is to actually use gadgets (snippets of code essentially) that are already there in the code thus they can be executed and redirect your instruction pointer to those addresses. Reusing code is generally known as ROP, JOP etc. and is mitigated by PAC for ARM (after v.8.3) and CFI for Intel (11th Gen onwards I believe).

That being said, Apple implements a ton of mitigations, both on a hardware level and on a software level which generally makes exploits on Apple devices interesting to analyze and see how they bypassed stuff.

My two cents reg. this.

Creating backdoors that allow encryption schemes to be subverted is _fundamentally_ going to cause harm on the internet, and eventually fail the weakest users/those that need privacy/security the most.

A mechanism that can subvert cryptographic protocols can be used by any party, including oppressive regimes, private entities etc. that have the resources/will/knowledge to use the backdoor etc. Backdoors harm both the trust on the web (which can have an impact on economic transactions among many others) and the people that need security/privacy the most. In the meantime, criminals will wise up and move their operations elsewhere where no backdoors exist.

We basically end up with a broken internet, we are putting people in harm's way and the criminals we are targeting are probably updating their OPSEC/MO not to rely on E2EE.

In the above he's mentioning that

Privacy features like user-agent reduction, IP reduction, preventing cross- site storage, and fingerprint randomization make it more difficult to distinguish or reidentify individual clients, which is great for privacy, but makes fighting fraud more difficult. This matters to users because making the web more private without providing new APIs to developers could lead to websites adding more:

- sign-in gates to access basic content

- invasive user fingerprinting, which is less transparent to users and more difficult to control

- excessive challenges (SMS verification, captchas)

My question is whether there is any data to back up those claims.

Uh the joys of PHP's type juggling. Fairly sure this bug is still present in many systems.

You can target co-processors in general, e.g., here [1], thus I assume people do hack GPUs.

Generally, the better we become in introducing mitigations, the more expensive attacks become and attackers have bosses, budgets and deadlines. They will try to find other avenues to land on a target :-)

[1]https://objectivebythesea.org/v5/talks/OBTS_v5_iBeer.pdf

We actually have two libraries in the office :)

The first library has, for the biggest part, engineering books. Everyone can order books and everyone can borrow them. Most modern books also exist internally as e-books so the physical library currently is a mix of books, 3D prints, random music collections etc.

The second library is everything else. Multiple copies of various titles are available to take and keep, for free. Only requirement is to inform someone if the copy you picked up is the last one. Many employees are totally oblivious about this library.

> I like that they suggest better solutions I didn't think of.

Although I don't write code full-time, when I do this is the part I enjoy more. People reviewing my code and coming up with better solutions on that same problem amazes me.

For what it's worth, Meta offered me slightly after the hiring freeze was announced for a security engineer position (L4 IIRC). I'm interviewing with Google for Security Engineering as well and still they haven't told me anything about a hiring freeze yet.

Just adding to your comment, there is some VX activity here https://www.vx-underground.org/.

Some fun stuff still takes place in game hacking and jailbreaking (whether iOS devices or consoles).

There's some theoretical background on how collision functions work. Generally, the assumption is that the hashing functions in cryptography meet the following: - Each input can be quickly converted to a digest (hash). - Getting from a digest to the input should be infeasible. - It should be infeasible to produce two inputs such that they map to the same digest (although strictly mathematically, people tend to prove it is inefficient to do so). and a few more assumptions that are irrelevant for your question.

In a nutshell, the idea is that hashing functions are deterministic. One input maps to one output and by knowing the output I cannot find the input nor I can produce two inputs that map to the same output.

Now, those attacks basically violate the principle that one input maps to one output. Suddenly, many inputs map to the same output.

What's the risk though? You want to download a Linux Distro with hash digest of value ABC. I'm somewhat interested in people using that linux distro so I tamper the distro to introduce a tracking mechanism that also produces ABC when hashed. You download the distro, verify that the hash is indeed ABC and install it.

A more structured answer to your question is available here https://github.com/corkami/collisions (he also put together a presentation that I can't find right now). Hope this helps :)

I wouldn't be surprised. I've seen colleagues reference April's Fools RFCs, and the reference wasn't meant to be taken as a joke.

or they could maybe use a specific OS as their golden image, use ansible or chef or puppet or any of the hundreds of tools that config machines and keep their staging and prod in sync. Bonus points for introducing a service that produces mock data for staging.

- I don't always test my code but when I do, it's in production.

- Everyone has a testing environment. Some people are lucky enough that they have a separate one for running production

[INSERT ADDITIONAL JOKES HERE]