tprynn

ActiveSupport adds tons of great convenience methods to Ruby and you can require it even outside of Rails! blank, present; date and time conversions like 1.month.from_now; except; enumerable methods like pluck... It's just lovely

    require 'active_support/all'

https://guides.rubyonrails.org/v5.2/active_support_core_exte...

I am. Pinning is a footgun with negligible real world security impact:

https://tprynn.github.io/2022/12/06/cert-pinning-bad.html

You tell a fun anecdotal narrative but in other cases those workers show up unannounced and threaten to separate families if they don't allow entrance even though of course that's unconstitutional. You can't reduce it to a single story here.

- https://www.propublica.org/article/child-welfare-search-seiz... - https://www.propublica.org/article/dcfs-illinois-investigati... - https://www.propublica.org/article/some-constitutional-right...

This is true, by default Android apps do not trust user-installed certificate authorities. IMO the easiest solution if you're doing security testing on a dedicated device is MagiskTrustUserCerts[1]. If you're not testing on a dedicated device or you don't want to root the device, I'd recommend using the objection[2] tool which has a guided mode for patching an apk, and you can modify the manifest to add your CA or to trust all user-installed CAs.

[1]: https://github.com/NVISOsecurity/MagiskTrustUserCerts

[2]: https://github.com/sensepost/objection/wiki/Patching-Android...

I am not sure how this is getting so many upvotes, but the claims in the readme do not appear to be supported by evidence. Those claims are so extreme that they are simply not believable without much more evidence, rather than what is in the readme which appears to be mostly rambling or attempts to get readers to look at other projects of the author.

Visual Studio Code has built-in support for remote development. It runs a local agent on the remote server via SSH which does essentially whatever you would be doing locally (e.g. viewing, editing, searching) and only sends the minimal results you need over the network.

https://code.visualstudio.com/docs/remote/remote-overview

It's showing a little age, but this list from Tech Solidarity gives you an intro to (1): https://techsolidarity.org/resources/basic_security.htm

I agree with the principle, but the way these arguments have been summarized here has led to near-complete strawmanning. It's like the author started from the blog title and then came up with their own contextless, binary arguments.

Certifications: The typical arguments against security certifications are not that they "don’t represent the full spectrum of skills a professional needs" but instead that many of them teach outdated, useless, or actively negative practices. Then they're used as an advertising tool and organizations with less security expertise are told they must hire based on certifications rather than actual skill.

Compliance: "compliance is counterproductive for security." Most security practitioners don't necessarily like compliance primarily because it's not enjoyable for them. It distracts them from the tasks that they want to be working on. In most cases compliance is orthogonal to security. In some cases it can certainly be counterproductive (e.g. government compliance programs requiring outdated crypto).

Management: The typical refrain "management doesn't spend enough on security / take risks seriously" has been turned into "management doesn’t care about security because they don’t fund every single thing the security team asks for". I mean, it's obvious that the argument wasn't taken seriously by the author just based on how they wrote that.

Yes, it's basically a side effect of activating Emergency SOS. The five-press shortcut works on all iPhones as far as I'm aware. As the doc says:

"If you use the Emergency SOS shortcut, you need to enter your passcode to re-enable Touch ID, even if you don't complete a call to emergency services. "

Signal could add app-level encryption, but who would this serve? Signal can't do anything better than what the OS/hardware provides in terms of encryption. Even if they let you specify your own signal-specific password/encryption key:

* Non-technical users either won't use it, or will use a weak key

* Technical users are better served by making sure their device is secure and hard-locked with a strong passcode (tip: 5 presses of the lock button on iPhone wipes in-memory encryption keys, essentially exiting "AFU mode")

The instructions posted by the dev directly include instructions for pulling the APK from your phone which was installed through the Play Store.

https://github.com/signalapp/Signal-Android/tree/master/repr...

uBlock Origin in advanced mode is gorhill's suggested replacement. If you have never used uMatrix before most likely uBlock Origin is what you should be using, and can easily accomplish the "globally block facebook domains" either via blocklists or manually via the advanced mode.

BinData (https://github.com/dmendel/bindata) is a Ruby gem for this, basically using a DSL in Ruby to declaratively define binary data formats that can be both read and written.

EMR is just an automated way of deploying open source components (Hadoop and co.) - there's some glue code there but the equivalent "open" version is probably the Hortonworks stuff (now owned by Cloudera): https://github.com/hortonworks

With DNS rebinding, you can still only send HTTP requests* to the target. With this attack, you have a direct, raw TCP/UDP socket.

(*) I'm simplifying, what I mean is that DNS rebinding still limits you to only what you can do in the browser, which is effectively HTTP. Most non-HTTP services will generally just close your socket once they see you send an HTTP request.

We don't have to consider anything near unlimited resources here - you can do a masscan of the internet on commodity hardware in an hour, or you have a shodan sub (they've sold lifetime basic subscriptions before for $5). Actually doing the exploitation on every target again probably takes under an hour with a couple cheap droplets. The only thing that actually requires any effort is setting up a reliable C&C infra.

The cost of any additional untargeted attack attempt is essentially zero in most cases. It doesn't matter whether you are trying your exploit on 100 hosts or 1 million. An attacker willing to spray exploits across the internet has basically zero incentive to only use those exploits on hosts they know to be running a specific version, and every incentive to just try it out on all hosts running the software that they can possibly identify.

By itself, disclosing version information provides little to no security consequence. If you are using an outdated, vulnerable server version, you will be exploitable regardless of whether you present a version number in the vast majority of cases. Attackers don't care whether you present a specific version number before attempting exploits in most cases (unless the exploit has a risk of crashing the service). And if you do have an exploit which depends on a specific version, most likely you can figure out the version without a version number anyway. Hiding version numbers probably does more work to hurt defenders (who want to easily scan and identify outdated software without attempting exploits).

I think it's generally a poor assumption to assume that any two internet "crowds" are the same people. Some commenters care about X and some about Y and we can almost never tell what the overlap between those groups is. The hivemind is not as uniform as that.

It's a real system dialog popped by the OS when the install script requests superuser privileges. It's not fake, and the password goes to the OS, not the script.

Curious what the higher-level solution to CSRF/SSRF is? I’m struggling to think how it could be prevented except at the browser level (for CSRF). And for SSRF if there’s a legitimate need for a network path between two services but one has an SSRF issue, how can you stop that?

I enjoyed the post and like the idea of Tailscale[^1], but agreed. As long as there's some path to the Internet, you can't trust your LAN. I mean, that's kind of the whole point of modern network security: even on a trusted network, you can't trust the endpoints.

Consider a modernized example of the business app in the story: let's say this is an internal-facing webapp with no security features implemented. With tailscale you can implement network security controls that only allow access from specific endpoints (tied to user or service identities), but the point is that you don't trust those endpoints. Of course they could be phished/compromised, but they could also easily use a boundary-crossing attack like CSRF/SSRF to attack your insecure app. So no matter what, you need to implement standard web app security features.

[^1]: https://news.ycombinator.com/item?id=22644357

Presumably power is disconnected by the T2 chip. Different from mechanical disconnect via a physical switch, but equivalently effective if you trust the T2 chip. (And if you don’t ... well, you can’t use the MacBook securely at all.)

If you read the article, it seems like it has both of those features, though I'm not sure what exactly you mean by "UDP relay".

Macbooks since 2018 physically disable microphones and webcams when the lid is closed: https://www.businessinsider.com/apple-macbook-air-and-2018-m...

Copying comment from previous thread:

Systemic issues:

* Creds scattered throughout source code, including DB / AWS creds, "fixed" by removing but still present in git history

* Numerous crypto vulns: nonces / AES-ECB

* What's even the point of blockchain, it just makes everything worse

Selected quotes:

"Trail of Bits was only provided a backend for live testing on the second-to-last scheduled day of the assessment"

"The system is unusually complex, with an order-of-magnitude more custom code than similar mobile voting systems we have assessed."

"Voatz's voting processes are error prone and manual, relying on manual verification of voter identity and long-term storage of this identity on Voatz's premises"

"E2E-V systems allow voters to cast encrypted ballots such that ballot counts are verifiable to anyone, but individual voters’ preferences are not revealed. ... Voatz is not E2E-V."

"Storing voting data on a blockchain maintains an auditable record to prevent fraud, but this comes at the expense of both privacy and increased attack surface. Clients do not connect directly to the blockchain themselves, and are therefore unable to independently verify that their votes were properly recorded. Anyone with administrative access to the Voatz backend servers will have enough information to fully reconstruct the entire election, deanonymize votes, deny votes, alter votes, and invalidate audit trails."

Systemic issues:

* Creds scattered throughout source code, including DB / AWS creds, "fixed" by removing but still present in git history

* Numerous crypto vulns: nonces / AES-ECB

* What's even the point of blockchain, it just makes everything worse

Selected quotes:

"Trail of Bits was only provided a backend for live testing on the second-to-last scheduled day of the assessment"

"The system is unusually complex, with an order-of-magnitude more custom code than similar mobile voting systems we have assessed."

"Voatz's voting processes are error prone and manual, relying on manual verification of voter identity and long-term storage of this identity on Voatz's premises"

"E2E-V systems allow voters to cast encrypted ballots such that ballot counts are verifiable to anyone, but individual voters’ preferences are not revealed. ... Voatz is not E2E-V."

"Storing voting data on a blockchain maintains an auditable record to prevent fraud, but this comes at the expense of both privacy and increased attack surface. Clients do not connect directly to the blockchain themselves, and are therefore unable to independently verify that their votes were properly recorded. Anyone with administrative access to the Voatz backend servers will have enough information to fully reconstruct the entire election, deanonymize votes, deny votes, alter votes, and invalidate audit trails."

Really? I find that brakeman is a pretty amazing tool which finds a number of surprising issues. Of course, these days the vast majority of Rails apps already have brakeman set up, so it's used more as part of the commit process and less of a "wow, here's a few dozen potentially high-impact web vulns". I wouldn't hesitate to say that it's the most high-signal SCA tool I've used across any language/framework.

(source: a few years of webapp pentesting and Rails app dev)

How can I opt out a virtual card number through Apple Pay? It doesn't seem that you can get the full "Device Account Number".

iOS won't consider itself connected to a WiFi network until it can hit that domain and get the response it expects, but some networks want you to be connected even though they don't actually give you full internet access. For example, plane wifi networks where you can stream video to your device but would have to pay for actual internet. So those networks will allow the connection for that site and other captive detectors but intercept actual connection attempts.