HN user

ninegunpi

97 karma

CTO at data security company. Opinions reflect my current state of mind and nothing else matters. I blog at http://www.ivychapel.ink about information security, risk and other things that amaze me.

Posts23
Comments43
View on HN
www.cossacklabs.com 7y ago

Preventing SQL Injections When WAF’s Not Enough

ninegunpi
18pts13
hackernoon.com 7y ago

Web app data leaks and how to prevent them 101

ninegunpi
3pts0
medium.com 7y ago

On avoiding band-aid security after penetration tests

ninegunpi
2pts0
github.com 7y ago

Quiche: QUIC implementation in Rust

ninegunpi
2pts0
www.cossacklabs.com 7y ago

Hiring external security team: what you need to know

ninegunpi
2pts0
www.cossacklabs.com 7y ago

Implementing tracing in modern distributed app

ninegunpi
4pts0
github.com 7y ago

CipherSweet: searchable field-pevel encryption for PHP

ninegunpi
2pts1
eprint.iacr.org 7y ago

Analysis of ProtonMail Cryptographic Architecture

ninegunpi
2pts1
blog.lukaszolejnik.com 8y ago

Highlights of french cybersecurity strategy

ninegunpi
2pts0
medium.com 8y ago

Two types of engineering resiliency

ninegunpi
2pts0
andrumyers.wordpress.com 8y ago

Meltdown, Spectre, and why hardware can be correct yet insecure

ninegunpi
2pts0
paragonie.com 8y ago

SecureRandom is now secure in Ruby

ninegunpi
5pts0
www.cossacklabs.com 8y ago

Hermes distributed access control scheme

ninegunpi
2pts0
www.cryptologie.net 8y ago

Disco – mixing Strobe and Noise protocol frameworks

ninegunpi
3pts0
unimplemented.org 8y ago

Analysis of remote DoS vulnerability in VirtualBox

ninegunpi
2pts0
eprint.iacr.org 8y ago

Standardizing Bad Cryptographic Practice [pdf]

ninegunpi
2pts0
www.feistyduck.com 8y ago

Why TLS 1.3 isn't ready yet

ninegunpi
2pts3
security.infoteam.ch 8y ago

An incident response blog post containing 0day vuln

ninegunpi
2pts1
medium.com 8y ago

Why decentralized social services fail

ninegunpi
39pts29
cryptojedi.org 8y ago

Post-Quantum Crypto: From NewHope to Kyber [pdf]

ninegunpi
1pts0
gist.github.com 8y ago

Affected products by Infineon RSA vulnerability

ninegunpi
1pts0
research.kudelskisecurity.com 8y ago

On PGP cipher preferences and OpenPGP compliance

ninegunpi
2pts0
eprint.iacr.org 8y ago

Breaking Ed25519 in WolfSSL [pdf]

ninegunpi
11pts0

tl;dr: Balancing tradeoffs and benefits during disclosure is a hard job sometimes and if authors chosen to do it this way - they could have done it for a reason? You don't have to trust me on this, but it has no commercial agenda behind it.

Disclaimer: I happen to work at the same company as authors, not involved in writing this, but I was witness to all research that led to this post. I have seen huge internal arguments on how much and how should be disclosed, given the context (see below), prior to this article being written.

1. I can attest that all these bugs are found in one physical device. I have seen it. Which is really widely used to this day. Moreover, this device has more relatives than we could easily enumerate, some of them potentially vulnerable to a subset of the bugs identified as well. The "vendor" is aware and nothing is changing for a while, in some ways getting worse (blast radius increases over time). This is result of economic reasons, rather than negligence,- "the vendor" in this case is a mixed bag of responsibility between several parties, not all of them commercial, not all of them actually existing to this very date, I believe.

2. In a normal situation, responsible disclosure path, instead of what you've been reading in a post, would be a right way to go. However, context matters in this case: authors happen to live in a country which is at war now (takes like 5 seconds to figure out, looking at the website), so their ability to talk about security vulnerabilities is a bit different to your expectations for reasons that are not very hard to understand. They use vague language, distort a few important details and focus on frivolous illustrations to avoid unnecessary damage.

Pointing out practical exploitability vectors publicly in a way that is understandable to anyone related to the field of practice is sufficiently helpful:

* Some people will now have explanations why their toy cars were stolen and consider changing their supplier of toy car equipment.

* Some people conducting engineering risk analysis will understand that this is not a "potential theoretical vulnerability", looking at their toy car and some of its settings, and consider alternatives.

Consider blog post and examples to be didactic material for an ongoing discussion about some hardware among field practitioners. Authors needed something to point their fingers at and say "this is how X can be exploited to do Y", without reading 2 hours lecture on cryptographic bugs that have been obvious 15 years ago.

3. Why not point out vendor and device list? Consider the context again, please.

It's easy to wave your hand and say "if people are idiots using hardware and devices that are known to be vulnerable, we should let them screw themselves", disclose the name of the vendor, and go on with your life. However:

* Being pointed out directly, these vulnerabilities could easily lead not only to "market levelling out discrepancies" (which does not always happen harmlessly, as we all know). It could lead to more physical damage and deaths immediately happening around authors of this post because exploitation is so easy.

* Not making it would lead to these devices being used over and over again, and obvious cryptographic bugs being dismissed as "theoretical threats", because remote toy car community is full of "Internet of Stuff" people who are dismissing cryptographic vulnerabilities on basis of "it's crypto, who knows how to exploit it, we've got more important stuff to worry about right now".

Infosec emotional climate always had a certain pessimistic, paranoid and panicky perception from the outside, but it is greatly exaggerated, I think.

FUD, bullshit, lack of skilled people, lack of budgets, lack of understanding from adjacent departments, chaos, mayhem, overtimes, incidents and creeping "I'm not sure what's going on" have always been parts of the profession. Learning to accept frustration, constant change, ill-formed perception and rejection is part of your career choice and a selection factor in the long term. Learning to look at the world from a certain angle which is hard to unlearn (especially if you're good at it) is a mental equivalent of firefighter's calluses.

If you can bear with it all - being on defensive side and being a kind of digital first responder (regardless of where exactly you are in the industry) is a fun job and calling for some.

(Edits: Typos)

Love cryptopals beyond my ability to articulate it well enough. This is monumental work many engineers owe their “cryptography 101-404” education to.

For a long while company I work for used Cryptopals as means to train/qualify interns before letting them touch serious practical stuff.

Not that knowing answers is a problem (there were public solutions, albeit clunky, before), but such careful explanation almost eliminates the fun in solving to some extent.

Gotta come up with our own take w/o public tour now, is anyone aware of any similar sets of challenges? CryptoHack is ok, but fairly deterministic one that removes “oh where do I go now” feeling, which is essential to bear with to learn to love the craft.

Edits: typos.

Isn't RASP just slapping the WAF-like signature detection into your application data streams directly? How would RASP prevent:

1. Insiders having access to database front?

2. Same SQL bypass techniques as employed to bypass WAFs?

3. Mitigate developer errors in query logic which enable custom injections?

If your security strategy relies on one or two security controls, you're doomed most of the time.

We've added SQL filtering as a defense-in-depth measure, having a convenient seat in the architecture, complementing every other mitigation measure proper application developers and DBAs should be doing (and frequently get wrong).

Even ORMs get bypassed once in a while:

- https://github.com/mysqljs/mysql/issues/342 - https://github.com/sequelize/sequelize/issues/5671 - (okay, we can avoid this one by saying nothing "nothing proper exists in NodeJS world) https://bertwagner.com/2018/03/06/2-5-ways-your-orm-will-all...

Dumb concatenation can nullify the merit of quite advanced ORM: copybook example of misusing Ruby's ActiveRecord (is that proper enough) got as far as OWASP testing guide: https://www.owasp.org/index.php/Testing_for_ORM_Injection_(O...

Prepared statements are cooked wrong as well, but rarely, that's why they are viable line of defense, but not the sole one (as nothing should be):

https://www.reddit.com/r/netsec/comments/ww9qm/sqli_bypassin... https://stackoverflow.com/questions/134099/are-pdo-prepared-...

(in fact, I've seen with my eyes exactly what first comment in reddit postmentions).

I actually came to comment on this matter. Anecdotal evidence of several people I know is that playing FPS games with trackpad (pretty much of a torture) improves touchpad intuitive usage to an extent where they don't notice any discomfort with it in daily life.

Perhaps, hand-eye coordianation training that happens in FPS shooters translates to better touchpad usage in normal cases.

(Still, I'm told that trying to competitively play FPS games with it just sucks).

What you are describing is effectively two aspects of the first step of traditional buddhist meditation Shamatha - awareness on chosen object and awareness on present signals of the body, so yes, meditation is is.

1. A "quite a while" is less than a hundred years after Godel and in math? Compared to 2000+ years of Aristotlean logic dominance in hard sciences just because Romans inherited most of their scientific views from Greeks, not from Indians/Chinese?

2. It depends on domains of applicability, if you think of it.

In pure CS and math? Yes, the visible value is limited, because most problems we choose to try to solve can be solved with math apparatus we're armed with. Value I know is mostly limited to optimizing problems that have poor solutions with binary logic.

In practical engineering? ATPG, to my understanding, requires multi-valued logic. Analysis of large phenomena and automated decision making becomes an order of magnitude simpler problems, with better efficiency over chosen metric. Temperature controllers, decisions based on photo-metering (autofocus, exposure adjustment), etc. Somehow, even with lack of readily-available building blocks and tooling, it turns out that there are problems people are motivated to solve from scratch, and MVL/FL comes handy.

It's only stuff I overheard of through my life among bright engineers.

3. Moreover, the biggest impact is not in CS (as original presented paradox isn't, as well), it's on human judgment, decision-making and general assessment of reality, where "neither true nor false" (I don't know) is the first stepping stone to make the world much easier place to live in.

Indeed. Yet, it is still based on True/False pair, which does not reflect neither reality or human experience in most cases. Where it is applicable - it perfectly works. But the scope is limited.

Descendants of Aristotle still find limitations of the system amusing, that’s amusing itself.

I hope to live to the day when philosophical advancements of 20th century (or re-discovery of 2500-old Indian logic, if you like), formalized in accessible forms, get widespread acceptance, could leave plenty of people who’se job it to juggle limited abstractions with the need to pick more useful jobs.

No pun intended, these are terribly useful abstractions we’ve built our world on, but they barely hold up against thorough reality check and leave out a lot as ‘paradoxes’.

1. The problem is that most population is terribly poor at defining and managing risk, by biological design and social selection - those who are good at it are usually not the best neighbors you want to have.

2. In many businesses, the actual customers are not the end-users, whose data is leaked (all the nice free services you're getting over this invisible thing called internet), they are the merchandise business is selling to somebody else (ads, etc.).

3. There are two ways of coping with this:

3.1 darwinian, where stupid users who choose to hand their data to dumb businesses all jump off the cliff holding hands

3.2 paternalistic, where we elect somebody competent to make choices for the rest of the community, which would prevent people's poor judgment to both hand data to insecure businesses and for businesses to be insecure in the first place.

4. We tried darwinian one since the day 1 in many fields. Reverting it comes at cost (antibiotics would be one good example to think of).

You are correct. I get a bit irritated when somebody claims to teach developers "all they need to know about cryptography" and goes on with explaining things they'd be happy to obsess on, instead of explaining things they _need to know_ to use cryptography securely.

These two pages themselves are important enough, these omissions are bad enough to disqualify any other effort in this book - cryptography is a tightly-knit system and making one or two mistakes simply nullifies the effect of making hundreds of correct decisions.

There are books on the subject which get it right, this is not the one.

It's like teaching people chinese gymnastics and saying it will protect you on the street - sooner or later someone has to punch you in the face for that.

Opened the book, read first random page (https://cryptobook.nakov.com/key-exchange/diffie-hellman-key...), closed the book.

If this is what "developers need to know", then explaining why anonymous key exchange is susceptible to MiTM and what can we do about it (PKI/CA/prior key exchange) would be way more useful than providing background of how DHKE actually works (there are way better explanations than repeating copybook examples anyway).

Upd: out of sheer curiosity, opened second page. https://cryptobook.nakov.com/symmetric-key-ciphers/cipher-bl.... Can we at least teach developers about nonce/IV challenges in GCM before saying it's "is highly recommended in the general case"? Perhaps, spending some page length on encrypt-then-sign, sign-then-encrypt and sign-encrypt-MAC merits would be more helpful to developers than CTR block scheme?

I do get your arguments very well: having to advocate ZKPP primitive in our own solution I end in discussions about ‘ZKPP does not prevent brute force’ a lot. But it’s unfair to rule out the analysis because this is a choice - these are weaknesses, they are making the system weaker. The fact that you’re providing ibcremental security in many spheres of your influence does not mean that, when being questioned, they are atill weak against practical risks. ‘Secure against chosen threat model’ is OK when threat model reflects reality, paper’s author, I think, is coming not from basis of your threat models, but from basis of security challenges of modern e-mail.

Quite frequently the difference between what you want to protect against vs real threat landscape is what rules the expert community’s decision.

I feel your pain (I work at company which improves data security of distributed systems in a number of ways, and get into similar disputes all the time), but the fact that you’re mitigating some of the risks really well does not mean that other security properties will not be scrutinized against commonly recognized threat models.

Not too rewarding, yet the whole security engineering is a Sysiphus’ labor fron day 0. Not having enough of in-community pressure (even when sometimes you’re criticized for a wrong cause, which is 50/50 here) would lead to much worse consequences than a few uncomfortable questions asked.

Background in infrastructure is the best you can have - you will be far ahead compared to many newly educated ‘security engineers’, knowing the application domain.

What I would think about if I were you (was so 15 years ago - started as systems engineer in telco, although has been playing around with systems since childhood) is to try and capitalize on knowledge you’ve got - pick entrypoint to secuirty market as ‘security for X’, where X is the type of systems you’ve been administrating. This way, you’ll have a solid base of problem domain experience, and will be able to easily associate new learning material and new work challenges with experience you’ve already got.

Security is a huge domain of knowledge - being able to bite it with digestible chunks is crucial not to turn into another checklist drone or certified skript kiddie.

Yes we do, there are problems which beg to be fixed. Most of current complaints are about security, in one way or another require plenty of CPU horsepower (which most routers don't have - CPU peaks while suddenly switching upling and retriving fullview is still a typical picture in a modern ISP). What it takes to prevent something like NLRI spoofing? Plenty of layers of data security.

And it still won't fix the human problem underneath it.

Security-aware BGP versions like S-BGP, soBGP and psBGP address most of security concerns, add plenty of router load and still... don't solve some of the human problems.

But current publicly made suggestions on replacing it with something completely different even lack proper understanding of design goals of original BGP standard.

I liked the version where Hawaii government was replaced by marionettes under pressure of nuclear attack, the missile exploded in the air (or was fake from the very beginning) and the new government refuted that it was a real message to keep the conspiracy undercover.

Most errors are boring mistakes, tho.

In high risk/high volatility environments, it's either regulation or reputation. That's why the smell of regulation is always telling: the inter-human natural trust scheme can't cope with the risk... or someone is looking to bend it in favor of one side.

I don't think that this leap of efficiency in "exploiting human psychology" is anything different from propaganda/marketing leaps of previous aeons. Reading the books of the past, they felt equally exploitative and novel back then.

We've coped with that, our descendants will cope with social networks we've created, as well. Attention management and rapid critical thinking would become as crucial mental capacities as IQ and EQ are today.

If, of course, smart people acquiring these skills over the next generations are still going to have descendants and the volume is significant enough, because typical "exploited" subjects are going to, you bet.

And then the A.I. will learn to manage humans in subtle ways (like filtering Facebook feed to achieve certain benchmark) and voila!

No need for SkyNet and terminators. ML to build better ML schemes to better control humans - that's a fun apocalypse to watch.

because they're making these compromises to cater to lazy middle-box providers.

Well, as much as I understand - it's not there because they're willing to find secure compromises instead of path of least resistance.