I was trying to figure out where Android devices keep their keystore file for trusted Certificate Authorities (CAs) so I could audit mine. One of the first answers Google brought me was advice from Motorola.
They described exactly what I was thinking about:
"add and remove additional root certificates including self-signed ones. So companies, which release their own root certificates for their employees are able to install them on Motorola phones."
Great, some advice on adjusting who I trust!
Wait!!!!
"Copy the certificate (.p12) file to the memory card. (There is no need to create a unique folder)"
Umm, but a PKCS12 file has to contain the certificate AND the associated private key. Am I expected to just ask the CA operator to had that over? I'm sure they'll be emailing that to me at any moment.
I did a bit more poking around and Motorola may not be the only one to blame. It appears that a few Android implementations are only aware of one certificate format.
Dear Motorola, please do not engage in crypto or crypto advice unless you have a clue. When trusting a CA or a cert explicitly, the file formats are PEM and DER.
I know this topic is boring, but really, if you can't do PKI and basic crypto and you are in any form of IT, your days of employment are numbered.
Sunday, October 28, 2012
Saturday, October 13, 2012
Larry Seltzer have you no shame?
Before we get started, Google this phrase "Advances in attacks on network security over the last few years have led to many"
Look, there's a fairly recent white paper from April of 2012 called, "Spoofing Server-Server Communication How You Can Prevent It"
Never mind, there it is from April of 2011.
No! WAIT! There it is from Decemnber of 2009.
This horrible piece of work came to me by email. I can't blame Symantec or VeriSign for putting it in my face, as it was sent by IDG, but pulling this work of stellar suck out once a year is sad and pathetic.
This is another case where idiots in Marketing get the bright idea to have a "journalist" "report" on something in the news that they think can sell product. I use the quotes in the most condescending manner possible here.
The list of things wrong with this article is incredible.
The clueless author, Larry Seltzer, starts off by building the FUD around developments in the world of SSL. He wisely references the work of the great Moxie Marlinspike.
"A new attack is threatening to expand the potential for attackers to compromise enterprise servers and the critical data on them."
In 2009, the attacks described were new. I can't recall. What is the date??
The real meat of the sadness starts here...
"SSLStrip – A New Type of Man-in-the-Middle Attack
Marlinspike’s SSLStrip attack demonstrated the combination of several attack techniques to exploit the above weaknesses and fool users/client applications into thinking they were using a trusted site/server, when in fact they were using a fake version of that site/server. He combined a number of techniques, including “man-in-the-middle,” fake leaf node certificates and the null character attack."
Moxie's work on x509 certificates with null chars in the Subject Common Name is great! That fantastic bit or work, or rather the tool built around it, is not called SSLStrip, it is called SSLSniff. As my link shows, Moxie also built SSLStrip and it is brilliant, but has nothing to do with null chars in certs. SSLStrip cleverly MITMs the HTTP traffic from a site BEFORE you get sent to the site's HTTPS pages. It then uses several techniques to terminate SSL in the middle and render pages and links back to the victim via HTTP and stripping all HTTPS references The author then goes on to repeat the wrong name over and over, including the yearly reprints...
"SSL and web security are under attack, so what if there was a name slip", you might say. "Larry is trying to help us protect ourselves."
No Larry Seltzer is just a puppet of a vendor. I'm not sure if Larry is stupid or just makes up shit for money. Hell, I will admit here and now; Any vendor who wants to pay me well to blather about their great product should just ask. I love money!
EV SSL to the Rescue!!
"EV SSL – The Antidote for SSLStrip Attacks
We saw that with conventional certificates, especially domain-validated
certificates, there is no reliable information to back up the authentication of the
domain name. To address this critical problem, CAs and software companies joined
to form the CA/Browser Forum and promulgate a new standard called EV SSL for
Extended Validation SSL."
Yes, we are now protected. Wait, how? What? Did the LSD just kick in? I'm not going to get all technical here, but the null char problem has two parts; some CAs accidentally let these certs get issued and all major web browsers handle them badly. Wait, yes this was true in 2009, but not after all the reprints of this "white paper". Then we get to the total lie that is the "Antidote". EV SSL is mostly about stronger vetting before issuing certificates. Yes, there is are special OIDs embedded in the certs that code in the browsers check and if correct, you get some green on your screen. Wow!! Green I am sooooooo safe!!! No one cares about this green. Additionally, if you do MITM one of these sites using a certificate that otherwise is trustworthy, all the site loses is the green. There is no code in the browser that knows if the lack of green is due to evil being afoot, or the site is too cheap to pay for EV SSL.
I am safe!
Ohh, the danger!! Wait, no red X, no exclamation point?? Note the DO NOT TRUST is printed by my PoC tool (Fiddler) in the cert body specifically because the browser will throw no errors and they don't want liability.
Look, there's a fairly recent white paper from April of 2012 called, "Spoofing Server-Server Communication How You Can Prevent It"
Never mind, there it is from April of 2011.
No! WAIT! There it is from Decemnber of 2009.
This horrible piece of work came to me by email. I can't blame Symantec or VeriSign for putting it in my face, as it was sent by IDG, but pulling this work of stellar suck out once a year is sad and pathetic.
This is another case where idiots in Marketing get the bright idea to have a "journalist" "report" on something in the news that they think can sell product. I use the quotes in the most condescending manner possible here.
The list of things wrong with this article is incredible.
The clueless author, Larry Seltzer, starts off by building the FUD around developments in the world of SSL. He wisely references the work of the great Moxie Marlinspike.
"A new attack is threatening to expand the potential for attackers to compromise enterprise servers and the critical data on them."
In 2009, the attacks described were new. I can't recall. What is the date??
The real meat of the sadness starts here...
"SSLStrip – A New Type of Man-in-the-Middle Attack
Marlinspike’s SSLStrip attack demonstrated the combination of several attack techniques to exploit the above weaknesses and fool users/client applications into thinking they were using a trusted site/server, when in fact they were using a fake version of that site/server. He combined a number of techniques, including “man-in-the-middle,” fake leaf node certificates and the null character attack."
Moxie's work on x509 certificates with null chars in the Subject Common Name is great! That fantastic bit or work, or rather the tool built around it, is not called SSLStrip, it is called SSLSniff. As my link shows, Moxie also built SSLStrip and it is brilliant, but has nothing to do with null chars in certs. SSLStrip cleverly MITMs the HTTP traffic from a site BEFORE you get sent to the site's HTTPS pages. It then uses several techniques to terminate SSL in the middle and render pages and links back to the victim via HTTP and stripping all HTTPS references The author then goes on to repeat the wrong name over and over, including the yearly reprints...
"SSL and web security are under attack, so what if there was a name slip", you might say. "Larry is trying to help us protect ourselves."
No Larry Seltzer is just a puppet of a vendor. I'm not sure if Larry is stupid or just makes up shit for money. Hell, I will admit here and now; Any vendor who wants to pay me well to blather about their great product should just ask. I love money!
EV SSL to the Rescue!!
"EV SSL – The Antidote for SSLStrip Attacks
We saw that with conventional certificates, especially domain-validated
certificates, there is no reliable information to back up the authentication of the
domain name. To address this critical problem, CAs and software companies joined
to form the CA/Browser Forum and promulgate a new standard called EV SSL for
Extended Validation SSL."
Yes, we are now protected. Wait, how? What? Did the LSD just kick in? I'm not going to get all technical here, but the null char problem has two parts; some CAs accidentally let these certs get issued and all major web browsers handle them badly. Wait, yes this was true in 2009, but not after all the reprints of this "white paper". Then we get to the total lie that is the "Antidote". EV SSL is mostly about stronger vetting before issuing certificates. Yes, there is are special OIDs embedded in the certs that code in the browsers check and if correct, you get some green on your screen. Wow!! Green I am sooooooo safe!!! No one cares about this green. Additionally, if you do MITM one of these sites using a certificate that otherwise is trustworthy, all the site loses is the green. There is no code in the browser that knows if the lack of green is due to evil being afoot, or the site is too cheap to pay for EV SSL.
I am safe!
Ohh, the danger!! Wait, no red X, no exclamation point?? Note the DO NOT TRUST is printed by my PoC tool (Fiddler) in the cert body specifically because the browser will throw no errors and they don't want liability.
As Larry does mention other developments in security, lets look at SSLStrip seeing how he spells the word repeatedly and never covers it. SSLStrip keeps the victim from ever getting SSL to the target site, so no SSL cert can help us here. The only thing Moxie hasn't solved is the lack of green, but again, no one notices or cares. I am one of the most paranoid web surfers I know, but how would I know if a site should have green or not. It's not that common...
The real tragedy here is that VeriSign commissioned the "white paper" and no one any intelligence reviewed or fact checked it, or wrote it. ;-) Then Symantec re-branded the thing, edited it a tad bit, but still never checked any facts.
All in all, this is what I have come to expect from Symantec.
Saturday, September 29, 2012
Defense in Depth in 9 Steps
Today's lame article, 9 popular IT security practices that just don't work, is a great example of someone who is paid by the word and needs to feed a family.
This is actually the article that inspired this blog. This not because the information is horrible, although it is... The real reason is that the author builds 9 wonderful Strawmen. I will concede none of these 9 technologies will give you 100% protection. Anyone who has been in infoSec, for say 3 weeks, know that defense in depth is vital. Controls will always fail for one reason or another. Proper layering of controls offers very strong security. I'd like to see MR. Grimes live in a digital world choosing not to use any of these technologies. Based on the article, he may be mentally deficient so I suppose he may be doing it.
Here are his absurd contentions... and my comments.
Security fail No. 1: Your antivirus scanner won't uncover real network killers
Yes, there are new viruses every day. However, if we pretend the number per day is fairly consistent, the total number of viruses grows rapidly. The AV vendors get their definitions out very fast these days. As the number total viruses grows every day, but the number of "unblocked" is fairly consistent, the AV products become more effective, by percentage, every day. The WILL UNCOVER 1000s of "real network killers", whatever that even means.
Security fail No. 2: Your firewalls provide little protection
Yes, firewalls are VERY boring. Yes, all the excitement and action are at the app layer now days. However, every hosts runs a huge number of services that do not need to be customer facing. Think remore console, like HP iLo and VNC, or management frameworks like OVO, SCCM, and so on. Surface area is hugely important. Never expose surface, especially administrative surface, to an attacker. The firewall is how you keep from exposing your systems to these "real network killers".
Security fail No. 3: Patching is no panacea
We agree!! Woo, there are no silver bullets. However, is he suggesting we don't patch? The problems described are vendor problems. We can't solve those. There are no alternatives. Patch your systems!
Security fail No. 4: End-user education earns an F
We almost agree here. The education is useless and the users should not be burdened with our concerns However, education is part of showing due diligence. If you are being sued due to a breach, answering to investors, etc., do you want to say you didn't even try. IT risk is part of overall risk and this is one risk you can reduce.
Security fail No. 5: Password strength won't save you
In practice and mathematically this is just horse shit. I'll skip the math, we all know it. As for stealing password via malware, etc., I sure wish I hadn't gotten rid of my AV back at point number 1. Yes, if passwords are your only security control, you are screwed, long or short.
Security fail No. 6: Intrusion detection systems can't determine intent
This is probably the best point in the article. While Mr. Grimes makes no recommendations, I always lean towards proactive controls over detective ones.
Security fail No. 7: PKI is broken
No, the market is broken and IT shops are broken. The folks doing PKI at DoD, etc. seem to be doing pretty well. This is because there is no cost pressure and a driver to sell more at less operating cost. This problem plagues the whole security industry. Read a few of Bruce Schneier's posts on Snake Oil. There are thousands of vendors trying to make a buck off of security while not giving a rat's ass about security. The truth is, certs need to cost more money and there need to be consequences if your CA or enrollment API gets rolled.
Security fail No. 8: Your appliances are an attacker's dream
That's because the vendors went to the same ITT class that Mr. Grimes did. They don't patch or run AV and their management ports are internet facing. The appliance is designed to limit the admin's need to know technical details and keep them from breaking shit and so the vendor has another SKU to push. As few of these "appliances" are anything more than cheap x86 hardware what would you expect. Whether the system is on the appliance or on your "server" if they vendor doesn't patch, you are screwed. Blame the vendor, not the form factor.
Security fail No. 9: Sandboxes provide straight line to underlying system
I have no clue what the author was thinking here. Yes sandboxes get exploited. The accepted paradigm is that all code has flaws waiting to be exploited. Yes, there have been a lot of exploits on them and there will be a lot more, but the only thing worse id not even trying to sandbox the browser Let's make the browser spec require remote code execution via HTML...
Anything that has ever been exploited "Just Doesn't Work", turn off your computer.
This is actually the article that inspired this blog. This not because the information is horrible, although it is... The real reason is that the author builds 9 wonderful Strawmen. I will concede none of these 9 technologies will give you 100% protection. Anyone who has been in infoSec, for say 3 weeks, know that defense in depth is vital. Controls will always fail for one reason or another. Proper layering of controls offers very strong security. I'd like to see MR. Grimes live in a digital world choosing not to use any of these technologies. Based on the article, he may be mentally deficient so I suppose he may be doing it.
Here are his absurd contentions... and my comments.
Security fail No. 1: Your antivirus scanner won't uncover real network killers
Yes, there are new viruses every day. However, if we pretend the number per day is fairly consistent, the total number of viruses grows rapidly. The AV vendors get their definitions out very fast these days. As the number total viruses grows every day, but the number of "unblocked" is fairly consistent, the AV products become more effective, by percentage, every day. The WILL UNCOVER 1000s of "real network killers", whatever that even means.
Security fail No. 2: Your firewalls provide little protection
Yes, firewalls are VERY boring. Yes, all the excitement and action are at the app layer now days. However, every hosts runs a huge number of services that do not need to be customer facing. Think remore console, like HP iLo and VNC, or management frameworks like OVO, SCCM, and so on. Surface area is hugely important. Never expose surface, especially administrative surface, to an attacker. The firewall is how you keep from exposing your systems to these "real network killers".
Security fail No. 3: Patching is no panacea
We agree!! Woo, there are no silver bullets. However, is he suggesting we don't patch? The problems described are vendor problems. We can't solve those. There are no alternatives. Patch your systems!
Security fail No. 4: End-user education earns an F
We almost agree here. The education is useless and the users should not be burdened with our concerns However, education is part of showing due diligence. If you are being sued due to a breach, answering to investors, etc., do you want to say you didn't even try. IT risk is part of overall risk and this is one risk you can reduce.
Security fail No. 5: Password strength won't save you
In practice and mathematically this is just horse shit. I'll skip the math, we all know it. As for stealing password via malware, etc., I sure wish I hadn't gotten rid of my AV back at point number 1. Yes, if passwords are your only security control, you are screwed, long or short.
Security fail No. 6: Intrusion detection systems can't determine intent
This is probably the best point in the article. While Mr. Grimes makes no recommendations, I always lean towards proactive controls over detective ones.
Security fail No. 7: PKI is broken
No, the market is broken and IT shops are broken. The folks doing PKI at DoD, etc. seem to be doing pretty well. This is because there is no cost pressure and a driver to sell more at less operating cost. This problem plagues the whole security industry. Read a few of Bruce Schneier's posts on Snake Oil. There are thousands of vendors trying to make a buck off of security while not giving a rat's ass about security. The truth is, certs need to cost more money and there need to be consequences if your CA or enrollment API gets rolled.
Security fail No. 8: Your appliances are an attacker's dream
That's because the vendors went to the same ITT class that Mr. Grimes did. They don't patch or run AV and their management ports are internet facing. The appliance is designed to limit the admin's need to know technical details and keep them from breaking shit and so the vendor has another SKU to push. As few of these "appliances" are anything more than cheap x86 hardware what would you expect. Whether the system is on the appliance or on your "server" if they vendor doesn't patch, you are screwed. Blame the vendor, not the form factor.
Security fail No. 9: Sandboxes provide straight line to underlying system
I have no clue what the author was thinking here. Yes sandboxes get exploited. The accepted paradigm is that all code has flaws waiting to be exploited. Yes, there have been a lot of exploits on them and there will be a lot more, but the only thing worse id not even trying to sandbox the browser Let's make the browser spec require remote code execution via HTML...
Anything that has ever been exploited "Just Doesn't Work", turn off your computer.
Friday, September 28, 2012
Cryptography from a 0
Today's bad security article, From 0 to cryptography, is a great example of an unqualified enthusiast with little experience or proper perspective. This type of enthusiast can't wait to display their brilliance to those who know nothing about the topic and their ignorance to those with any small amount of industry experience.
The first hint is is that the writer decides to explain the Diffie–Hellman key exchange using colors rather than math. He then follows with this by claiming that DH can resist a MITM attack. WOW!! I suspect the writer is a math enthusiast, as there is a math follow up and a heavy focus on even more math, including RSA.
Then we get gems like this:
Why it is this algorithm important? Because protocols like: SSL, TSL, SSH, PKI or IPSec, all use Diffie-Hellman.
SSL/TLS CAN leverage DH, but the most commonly negotiated cipher-suites do not. PKI isn't even a protocol.
Then we get this flaming line of crap:
The only difference between a digital signature and a digital certificate is that the public key is certified by a trusted international Certifying Authority(CA).
I think the author meant ", larg schmarg, harg trag cluten schnank". At least mine makes more sense. A digital certificate is NOTHING like a digital signature.
When talking about keys and secrets, there is never a mention of "out of band"??? How can we talk about applied cryptography with out that?
The biggest problem I see is all the math and command line examples give the impression, to the target audience, that this article is accurate or authoritative in some way. There is some accurate data here, but one would be FAR better off by just reading the Wikipedia articles on the topics. That is a pretty low bar.
I applaud _no for calling out this horse shit in the comments.
This article reminds me of this SMBC comic.
The first hint is is that the writer decides to explain the Diffie–Hellman key exchange using colors rather than math. He then follows with this by claiming that DH can resist a MITM attack. WOW!! I suspect the writer is a math enthusiast, as there is a math follow up and a heavy focus on even more math, including RSA.
Then we get gems like this:
Why it is this algorithm important? Because protocols like: SSL, TSL, SSH, PKI or IPSec, all use Diffie-Hellman.
SSL/TLS CAN leverage DH, but the most commonly negotiated cipher-suites do not. PKI isn't even a protocol.
Then we get this flaming line of crap:
The only difference between a digital signature and a digital certificate is that the public key is certified by a trusted international Certifying Authority(CA).
I think the author meant ", larg schmarg, harg trag cluten schnank". At least mine makes more sense. A digital certificate is NOTHING like a digital signature.
When talking about keys and secrets, there is never a mention of "out of band"??? How can we talk about applied cryptography with out that?
The biggest problem I see is all the math and command line examples give the impression, to the target audience, that this article is accurate or authoritative in some way. There is some accurate data here, but one would be FAR better off by just reading the Wikipedia articles on the topics. That is a pretty low bar.
I applaud _no for calling out this horse shit in the comments.
This article reminds me of this SMBC comic.
Subscribe to:
Posts (Atom)