
Obtaining Wildcard SSL Certificates from Comodo via Dangling Markup Injection - pfg
https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard-ssl-certificates-from-comodo-via-dangling-markup-injection/index.html
======
0xmohit
The timeline looks awesome:

    
    
      June 4th, 2016 – Emailed security@comodo.com and reached out on Twitter to @Comodo_SSL.
      ...
      July 25th, 2016 – Robin from Comodo confirms a fix has be put in place.
    

50+ days! Funny that the entity in question is the biggest CA.

That said, one should never click on links and buttons in emails. It's more
comforting to be able to copy a link instead.

~~~
mikeash
I wouldn't even copy links. Too many unicode shenanigans and other URL display
problems out there.

I made an exception for sites I was going to immediately use 1Password's
autofill with, trusting its URL validation to save me from fakes. I hadn't
considered that merely loading a malicious URL could cause trouble. I think
I'll have to reconsider my policy on that.

~~~
tedmiston
I don't even open links from emails anymore, just login to the company's
dashboard and find it instead. :/

~~~
wahern
That's how I handle phone calls, too. For example, if I get a call from a bank
then as soon as they begin asking for personal information I inform them that
I'll have to call them back. I do this even if I was _expecting_ a call from
them.

I've never had a representative balk at this, but many times they'll give me a
number and extension to call. But that would defeat the whole purpose. I tell
them that I need a published number that I can independently confirm. Usually
they just say it's fine to go ahead and use the number on their website.

None of this is foolproof. My confirmation of a phone number is usually rather
cursory--a quick Google search comparing results with what I find on the
company's website. But infosec crimes are becoming increasingly common and I'd
rather not be the low-hanging fruit.

~~~
Buge
I heard of an attack that causes even calling back to fail. Because with some
phone providers, when you hang up, it doesn't actually hang up. So you dial
the new number thinking you are making a new call, but you are actually on the
same call and they just play ringing sound effects for you, and have a new
person "answer".

~~~
tedmiston
Can you provide more details? I haven't heard of this one and hope to educate
myself better if it really is possible.

~~~
toast0
This is a potential concern with traditional analog POTS. There isn't an
explicit signal to end the call on the analog side. Some switches take longer
than others to detect when your phone goes on-hook and end the call. If yours
takes a long time, then on the plus side, you can hang up one phone, walk to
the other side of your house and pick up the other to continue a call, but on
the minus side, an attacker could play a dial tone at you and trick you.

This can happen with connections between switches too, potentially; but modern
(like 1980s modern) out of band signaling techniques on trunks generally
prevents this type of thing.

------
AndyMcConachie
What's particularly terrible about problems like this is an organization with
absolutely no relationship with Comodo is vulnerable. The CA system is so
horribly broken.

~~~
acd
Here is a graph of CA authorities. Who do you trust?
[https://notary.icsi.berkeley.edu/trust-
tree/](https://notary.icsi.berkeley.edu/trust-tree/)

See also Comodo vs Letsencrypt. [https://letsencrypt.org/2016/06/23/defending-
our-brand.html](https://letsencrypt.org/2016/06/23/defending-our-brand.html)

~~~
detaro
Funny to see the giant swirl that is DFN with all its individual children.

(DFN is the "Deutsche Forschungsnetz" ("German research network"), and it
gives out sub-CAs to the individual member institutions. Which apparently is
an uncommon practice)

~~~
lorenzhs
I talked to the CA guys at my university once and they don't have access to
the keys. They do identity verification and send the documents onwards to some
other CA folks at DFN for the actual signing. Makes the whole thing rather
pointless imho.

~~~
yuhong
Of course, this remind me of the ANSSI fiasco in late 2013 where one of the
intermediates was used for MITM. From
[https://bugzilla.mozilla.org/show_bug.cgi?id=693450#c29](https://bugzilla.mozilla.org/show_bug.cgi?id=693450#c29)
: "I received email from the CA representative that said that the decision to
include this root IGC/A 4096 SHA2 is discontinued (reason is the complexity of
the operation and the associated costs)."

------
greglindahl
To somewhat avoid email-based attacks like this, I asked my email client to
show me the text instead of html email when both are provided. It's pretty
clear to me that not that many people do this... many major websites send me
emails where the text version is empty, truncated, completely different
content, or a message like "Your email client is misconfigured, it should be
showing you the html version".

~~~
monorailz
I have mutt configured to open the html email in lynx and dump the text. Lynx
is a terminal browser and does not support images and does not execute
javascript. Prior to configuring mutt this way, I frequently encountered the
kind of bad content you talk about in mail, but now I get the content and can
still feel safe. I am still vulnerable to HTML parsing bugs in lynx, but I
don't think the risk of anyone targeting lynx is all that big.

To read and send mail, I ssh to my mail server and use mutt there. For the
most part it works great, except when I receive links I need to visit longer
than about 70 characters because then I have to copy the URL in parts rather
than all at once due to the plus signs inserted by mutt to indicate that the
line continues.

~~~
greglindahl
I'm a mutt user, too. I think

set markers=no

in your ~/.muttrc will get rid of the plus signs.

~~~
monorailz
That removed the plus signs. Thanks! :)

------
retox
Incompetence, from top to bottom. If you are in a position to deny them money
you owe it to the internet to divest asap.

~~~
chinathrow
I did exactly that - went with Let's encrypt for my latest site and ditched
them for good.

------
deathanatos
> _Peeking at the above raw email we notice that the HTML is not properly
> being escaped._

While I don't believe the author is mistaken that he successfully injected
HTML into the email, the email snippet quoted in the article _is_ properly
escaped, because none is needed, because the email is not HTML:

    
    
      Content-Type: text/plain; charset=UTF-8
      Content-Transfer-Encoding: 8bit
    
      [ snip ]
      Subject:
      <h1>Injection Test</h1>
      <pre>This order was placed by</pre>
    

This is correct for plain text as <h1> has no special meaning. That said, this
is a multipart/alternative email:

    
    
      Content-Type: multipart/alternative; boundary="(AlternativeBoundary)"
    

"multipart" meaning the email contains multiple parts, "alternative"
indicating that they're the same semantic things, but alternate
representations of it. We're looking at the plain text representation, when we
should be looking at the HTML representation.

(These are so email clients that don't support HTML — or are configured to
ignore — can fall back on something.)

~~~
myworldplz
Oops you're right, I snipped the wrote part of the actual email I received.
There's an HTML block below the text/plain block :) nice catch! I'll update it
shortly.

------
martinald
This is so bad. I used to think a while back that SSL pinning was over the
top. It looks like we as an industry need to move to SSL pinning asap
wholesale.

~~~
shawkinaw
The problem with pinning, as I understand it, is that it prevents me from
being able to see traffic from my own computer (via HTTPS proxy). Pinning is
fine as long as I can turn it off, but I don't want to completely lose the
ability to audit the traffic coming off my computer, phone, etc. Related is
the recent supposed change in Android disabling the ability to add a trusted
root certificate, that also screws the ability to audit.

~~~
nitrogen
For better and for worse, installing a private root in most browsers causes
pinning to be disabled (for certs signed by that root?).

~~~
niij
From what I can tell from my former employers HTTPS MITM was that websites
with certificate pinning turned on had to be exempted from the TLS proxy,
otherwise browsers would throw pinning errors.

~~~
cbr
"Chrome does not perform pin validation when the certificate chain chains up
to a private trust anchor. A key result of this policy is that private trust
anchors can be used to proxy (or MITM) connections, even to pinned sites.
“Data loss prevention” appliances, firewalls, content filters, and malware can
use this feature to defeat the protections of key pinning."

[https://www.chromium.org/Home/chromium-security/security-
faq...](https://www.chromium.org/Home/chromium-security/security-faq#TOC-How-
does-key-pinning-interact-with-local-proxies-and-filters-)

------
hannob
A very obvious mitigation to this and similar issues seem to be to forbid HTML
in domain validation emails. I don't see a reason not to do this and I totally
expect that Comodo is not the only CA having such issues.

------
Fej
Another day, another CA problem.

I'm almost desensitized to it at this point. Despite the fact that these
problems are potentially Web-breaking.

------
strommen
Wow, this attack was XSS 101.

And it could have been mitigated with _anti_ -XSS 101: rejecting all form
posts containing angle-brackets.

~~~
moloch
This is insufficient to prevent XSS, or DMI -the de facto anti-XSS is
contextual (generally HTML) encoding, and it is the only proper mitigation.
Blacklisting specific characters such as angle brackets is not safe, and will
end in tears.

~~~
strommen
Yes, blacklisting is insufficient in general. But it covers many cases,
including the one here. Contextual encoding must be done each and every place
you emit user input into HTML, and it's easy to screw this up. Character
blacklisting provides an extra layer of protection.

Unless you're intending for your user to post HTML, or math inequalities, or
diff patches - there's no reason to allow angle brackets on a form post.

~~~
moloch
> Yes, blacklisting is insufficient in general. But it covers many cases,
> including the one here. Contextual encoding must be done each and every
> place you emit user input into HTML, and it's easy to screw this up.

Blacklists are only acceptable if you do it in addition to contextual encoding
wherever you emit user controlled data, and even then a much stronger
protection would be to whitelist acceptable characters. Either way, contextual
encoding whenever you emit user data is the only real protection. --And even
then it's not a good fallback protection, a strong Content-Security-Policy
should be your fallback protection.

> Unless you're intending for your user to post HTML, or math inequalities, or
> diff patches - there's no reason to allow angle brackets on a form post.

Form posts are not the only vector for XSS, any HTTP request can be
potentially exploited to perform XSS (and any part of an HTTP request),
doesn't matter if it's a Form, an AJAX request, an HTTP header value, or a GET
parameter, they're all potential attack vectors.

------
fred256
Why does the title specifically mean wildcard SSL certificates?

~~~
omeid2
I think the author is using "wildcard" in general sense of "any value you
fancy" rather than a "wildcard certificate".

