Over 15,000 Fraudulent PayPal Certificates Issued to Phishing Sites

Schtask

Schtask

Limp Gawd
Joined
Nov 29, 2011
Messages
436
Let's Encrypt was launched publicly in December of 2015 under the premise that websites would be encrypted and served to the end user over Transport Layer Security (TLS). The thought was that TLS would protect user data from pilfering. Many Cyber Security experts expressed fear that free certificates would be abused as the issuance processes are automated. These fears were realized when encryption pro Vincent Lynch confirmed that 96.7% of the 15,270 security certificates including the term "Paypal" were issued to illegal phishing sites. Check out the video.
 
toast0 said:
The certificates aren't really fraudulent, although the sites certainly are. The certificates indicate that you haven't been MITM between your browser and the person who owns/controls the domain.
Click to expand...

You are correct on all counts. It is a valid and trusted certificate. In fact, Let's Encrypt meets all compliance standards in the industry for a CA ..but if the certificate is issued to a phishing or drive by download site and you receive a trusted certificate from that site implying it is from PayPal, the certificate isn't really a trusted certificate. Making it fraudulent. :confused:
 
Last edited:
i'm curious what you mean by "implying it is from PayPal". you mean a typo-squatter or near-squat type of domain that looks like paypal.com but isnt?

edit: i see the linked article that specifically uses a paypal example. i'm going to read that now!
 
Messy said:
i'm curious what you mean by "implying it is from PayPal". you mean a typo-squatter or near-squat type of domain that looks like paypal.com but isnt?

edit: i see the linked article that specifically uses a paypal example. i'm going to read that now!
Click to expand...

:)
 
ok got the answer by reading, haha.

i'm torn on this issue. there is definitely fraudulent misrepresentation of the content of the site. using paypal's logos, acting like paypal, etc. but to me with this issue, i think that's where the fraud ends. i could be wrong and could be convinced otherwise with a good argument though.
i wouldn't call the certificate fraudulent in this case though. i tell my parents, my wife, my kids, my coworkers, etc to all look at the url and what part of the url is important. clearly the intent is fraud, but for the sake of the argument about Let's Encrypt's position in all this i think they are in the clear and want to maintain a "dumb pipe" position on this.

i realize not everyone will get it, or even care, but that doesn't mean it's not important for people to understand a little about what they are doing. also understand that a certificate doesn't mean the site is what they think it is. it just means it is what it really is, so just having a nice green lock doesn't mean "site is good" it just means you're getting an ephemeral vpn between you and the termination point on the other end.

that being said, those with intent to defraud suck eggs. they have always been with us in all of recorded history and will continue to be with us, so at the risk of victim-blaming - it's up to us to know what we are doing and help those around us.
 
People forget that TLS isn't just about encryption. Security has many layers and part of the "web of trust" is that the authenticity of the domain you are visiting is ensured. TLS encryption should be free, domain verification should not. (unless someone wants to do it non profit style) Bias note: Day job. [Check out my several hundred A+'s from ssllabs :D using dual key EC/RSA combos.]
 
Messy said:
ok got the answer by reading, haha.

i'm torn on this issue. there is definitely fraudulent misrepresentation of the content of the site. using paypal's logos, acting like paypal, etc. but to me with this issue, i think that's where the fraud ends. i could be wrong and could be convinced otherwise with a good argument though.
i wouldn't call the certificate fraudulent in this case though. i tell my parents, my wife, my kids, my coworkers, etc to all look at the url and what part of the url is important. clearly the intent is fraud, but for the sake of the argument about Let's Encrypt's position in all this i think they are in the clear and want to maintain a "dumb pipe" position on this.

i realize not everyone will get it, or even care, but that doesn't mean it's not important for people to understand a little about what they are doing. also understand that a certificate doesn't mean the site is what they think it is. it just means it is what it really is, so just having a nice green lock doesn't mean "site is good" it just means you're getting an ephemeral vpn between you and the termination point on the other end.

that being said, those with intent to defraud suck eggs. they have always been with us in all of recorded history and will continue to be with us, so at the risk of victim-blaming - it's up to us to know what we are doing and help those around us.
Click to expand...

And the green lock doesn't mean that if they use crappy ciphers or a weak protocol...

Also: Depending on the font you may not even see a character is different. Think "little L" and "capital I"

Is that url in your address bar https://www.paypal.com or https://www.paypaI.com ?

The first one is an lower case "L". the second one is a capital "i"
 
The question is: Should letsencrypt be responsible for revoking certs for obviously fraudulent domains? They say "no". IMHO they should.
 
/dev/null said:
The question is: Should letsencrypt be responsible for revoking certs for obviously fraudulent domains? They say "no". IMHO they should.
Click to expand...

Either that, or browsers should just start rejecting any cert signed by letsencrypt.

Side note. It takes way too many steps to see who a cert issuer is. I should be able to see this info by clicking in the address bar...
 
Zarathustra[H] said:
Either that, or browsers should just start rejecting any cert signed by letsencrypt.
Click to expand...

And this is the free market solution. Either clean up your mess, or risk you business by having all your certificates marked are invalid.

Unless they make an effort to revoke the certificates that are being used to commit this fraud, Microsoft (and other vendors) should issue a security update that rejects all their certificates as invalid.
 
Zarathustra[H] said:
Either that, or browsers should just start rejecting any cert signed by letsencrypt.

Side note. It takes way too many steps to see who a cert issuer is. I should be able to see this info by clicking in the address bar...
Click to expand...
Then we are right back to where we started before LetsEncrypt opened up, HTTPS is only used for profit, everyone else ignores it. Its not Lets Encrypt's job to be the internet police.
 
For common people this renders it totally unsafe. Either it is safe-4-idiots aka safe-4-all or it simply isnt.

Google and Mozilla should change their certificate policy asap, IE and Safari as well.


People ask me all ther time about security on the web, I always tell them: THERE IS NONE...and this proofs again I am more right than wrong.


I have seen so many broken and dirt cheap certificates (mis)used, not properly implemented, and what not else,.... by financial players of considerable size that I gave up on that. Money rules and fixed..."fixed it will get after we had the headlines" seems to be the motto of our time.
 
nutzo said:
And this is the free market solution. Either clean up your mess, or risk you business by having all your certificates marked are invalid.

Unless they make an effort to revoke the certificates that are being used to commit this fraud, Microsoft (and other vendors) should issue a security update that rejects all their certificates as invalid.
Click to expand...

chrome and firefox have blacklisted a root CA before, i am surprised they have not even done it yet to LetsEncrypt as they are not performing even basic word phishing checks
 
I used LetsEncrypt to get a free certificate for my home server. I wanted to have SSL without always throwing up the self-signed error.

HTTPS is to prevent man in the middle attacks, (privacy concerns) not to prevent all fraud. There are a lot of affordable HTTPS certificates available that could be used for fraud sites, so let's not be too harsh on an organization that is trying to let people encrypt without having to line the pockets of mega corporations.

If I run an office supply store, and people come to me to buy pens and contract forms, and they use those pens and forms to get people to sign fraudulent contracts, who's at fault?
 
SSL certs should cost no more than 5-10/yr to cover the cost of validation of the entity requesting the cert and some profit. Its obscene for them to cost 399/yr (symantec) + for something I can do in 30 seconds with a command line. The only thing you are paying for is the name and the "verification".
 
jardows said:
I used LetsEncrypt to get a free certificate for my home server. I wanted to have SSL without always throwing up the self-signed error.

HTTPS is to prevent man in the middle attacks, (privacy concerns) not to prevent all fraud. There are a lot of affordable HTTPS certificates available that could be used for fraud sites, so let's not be too harsh on an organization that is trying to let people encrypt without having to line the pockets of mega corporations.

If I run an office supply store, and people come to me to buy pens and contract forms, and they use those pens and forms to get people to sign fraudulent contracts, who's at fault?
Click to expand...

Yep RapidSSL's are $10 and are issued within 5 minutes fully automated.
 
kju1 said:
SSL certs should cost no more than 5-10/yr to cover the cost of validation of the entity requesting the cert and some profit. Its obscene for them to cost 399/yr (symantec) + for something I can do in 30 seconds with a command line. The only thing you are paying for is the name and the "verification".
Click to expand...

Hey don't forget that Symantec also offers you a guarantee :D

guarantee.jpg
 
Quartz-1 said:
Ok, I'll bite: how do I get my browser to do this? I use Chrome.
Click to expand...


Good question. I'm not sure how. It would probably require some sort of plugin. Right now in chrome I can't even see who signed the cert for the site I am on.

When I made the comment above, I was thinking of it from a "browser makers need to do this" perspective, but to your point maybe we can do this ourselves.

Maybe someone else with more experience in this regard can answer that one.
 
Chrome made this more difficult, but this is how you do it:

Click 3 dots on the right of chrome -> more tools -> developer tools.
At top next to "elements", "console", "sources" (etc), click the two right arrows -> security.
Click "view certificate"

Enjoy!
 
Also, it loos like "DST ROOT CA X3" is the root of letsencrypt.

Chrome:

3 dots -> settings -> https/ssl (Manage certificates) -> Trusted Root -> (select) DST Root CA X3 -> click "Remove" that should make them untrusted.

This is for Chrome on Windows...

Edit: looks like there may be more than one...
https://letsencrypt.org/certificates/
 
Last edited:
jardows said:
I used LetsEncrypt to get a free certificate for my home server. I wanted to have SSL without always throwing up the self-signed error.

HTTPS is to prevent man in the middle attacks, (privacy concerns) not to prevent all fraud. There are a lot of affordable HTTPS certificates available that could be used for fraud sites, so let's not be too harsh on an organization that is trying to let people encrypt without having to line the pockets of mega corporations.

If I run an office supply store, and people come to me to buy pens and contract forms, and they use those pens and forms to get people to sign fraudulent contracts, who's at fault?
Click to expand...

Having gone through the process of getting real certs, one of the steps is verifying you are who you say you are. They are not doing that job. Also your analogy is shittastic. The proper analogy would be if not only did they buy the forms and pens, but also had you print up branding and ID for a company that never does business for you, and also had marks calling you up to vouch for their identity.

A how to on how to revoke the trust of a certificate on your system (windows centric)

https://certsimple.com/blog/control-the-ssl-cas-your-browser-trusts
 
Zarathustra[H] said:
Well, that's depressing.
Click to expand...
/dev/null said:
The question is: Should letsencrypt be responsible for revoking certs for obviously fraudulent domains? They say "no". IMHO they should.
Click to expand...

Certificate authorities have few responsibilities -- even the ones you pay for. There is no responsibility to authenticate an owner or to audit the subject matter. The sole responsibility of a TLS CA is to match a domain to a key and "sign it" by generating the pair to host their copy, to which Let's Encrypt does flawlessly. Just because the paid variants have additional fields for personal information does not enforce any additional authentication. Thus, Let's Encrypt is not an inferior cert authority. A TLS encrypted connection does not (and should not) provide an additional inkling of trust. In other words, just because you see the little TLS lock icon in your browser shouldn't make you feel safe. It doesn't mean anything beyond "endpoint encrypted" and the endpoint server could still be full of shit. It's up to the user to make sure they are on the correct site, and the correct site to audit their code. The only side effect is that there are cheaper opportunities for fraudulent sites to take advantage of people's dumb trust in that little lock.

nutzo said:
And this is the free market solution. Either clean up your mess, or risk you business by having all your certificates marked are invalid. Unless they make an effort to revoke the certificates that are being used to commit this fraud, Microsoft (and other vendors) should issue a security update that rejects all their certificates as invalid.
Click to expand...

All HTTP traffic should be using TLS, regardless of the subject matter. It's not up to a CA to audit and it never was. If browsers start pulling Let's Encrypt from their default CA lists, then they too are derailing the purpose of TLS. This type of fraud is nothing new, TLS CAs are not there to stop it, and $10 a year to a "reputable" CA will not help mitigate the amount of stupid managing millions of small servers susceptible to hijackings and fraud.
 
/dev/null said:
And the green lock doesn't mean that if they use crappy ciphers or a weak protocol...

Also: Depending on the font you may not even see a character is different. Think "little L" and "capital I"

Is that url in your address bar https://www.paypal.com or https://www.paypaI.com ?

The first one is an lower case "L". the second one is a capital "i"
Click to expand...

If you type in www.paypa capital I .com into your browser and hit enter, since domains are lower case (for now,) the domain you end up at in your address bar is www.papai.com If a person wanted to obfuscate URL's there is a billion ways to do it and none of it has anything to do with SSL or TLS.
 
Bounty said:
If you type in www.paypa capital I .com into your browser and hit enter, since domains are lower case (for now,) the domain you end up at in your address bar is www.papai.com If a person wanted to obfuscate URL's there is a billion ways to do it and none of it has anything to do with SSL or TLS.
Click to expand...

That sounds buggy. It's probably worth mentioning which browser this works in, what language you are inputting, and to submit a bug report. It isn't completely outside of the realm of possibility that your ISPs DNS is poorly configured, but it's the browsers responsibility to send a sensible request. DNS domain names should be entirely case-insensitive. Even with IDN domain names there is special concern for possible mixing of input language, and the browser needs to determine the language before submitting the request to a domain server.
 
velusip said:
Certificate authorities have few responsibilities -- even the ones you pay for. There is no responsibility to authenticate an owner or to audit the subject matter. The sole responsibility of a TLS CA is to match a domain to a key and "sign it" by generating the pair to host their copy, to which Let's Encrypt does flawlessly. Just because the paid variants have additional fields for personal information does not enforce any additional authentication. Thus, Let's Encrypt is not an inferior cert authority. A TLS encrypted connection does not (and should not) provide an additional inkling of trust. In other words, just because you see the little TLS lock icon in your browser shouldn't make you feel safe. It doesn't mean anything beyond "endpoint encrypted" and the endpoint server could still be full of shit. It's up to the user to make sure they are on the correct site, and the correct site to audit their code. The only side effect is that there are cheaper opportunities for fraudulent sites to take advantage of people's dumb trust in that little lock.



All HTTP traffic should be using TLS, regardless of the subject matter. It's not up to a CA to audit and it never was. If browsers start pulling Let's Encrypt from their default CA lists, then they too are derailing the purpose of TLS. This type of fraud is nothing new, TLS CAs are not there to stop it, and $10 a year to a "reputable" CA will not help mitigate the amount of stupid managing millions of small servers susceptible to hijackings and fraud.
Click to expand...

From a purely technical standpoint, I agree.

But would you then be OK with, say, a chinese ca issuing a microsoft.com certificate if requested & then not revoking it? How about someone who gets into microsofts dns and creates a subdomain (or maybe even a rogue employee) "patches.microsoft.com" that directs to a malware site. Should the CA revoke it or say "not my problem" ?

If someone owns a vacant property & it becomes a nuisance or dangerous, I believe the property owner is responsible. Why not in this case?
 
This discussion about what CAS to trust or not is interesting. I saw another article today stating that Google Chrome is considering a reduction in the level of trust for Symantec certs claiming they aren't being properly validated... On the surface, it would seem that this is rather similar to what is being claimed here...

I'm kind of agreeing with a few posts that I see here that website validation or anti phishing is sort of separate from the validation of the certificate... Really all that certain says is you are talking to the server in the address bar and not something else (mitm). At least that how I understand it. We already have extra layers of website filtering via things like Microsoft Smart screen, Chrome's built in anti-phishing / security warnings or enterprise URL filtering systems.
 
Well I hope they don't block let's encrypt... But I use the service.

I have a couple hundred networked boxes that benefit from TLS, but I don't want to charge the customers for the certificates. And I don't want to talk customers through installing a new root CA onto their devices so they don't get warnings... Let's encrypt finally solved the problem I've been struggling with since about 2000. How to issue valid certificates hassle-free for services customers run on their own home or business internet connections.

If somebody knows another way I'm open to hearing it. What I do now is issue a dynamic dns address with my own dns servers and domains for each physical host and then use let's encrypt to grab a certificate for that host. I can force everybody to log in via my own portal and then I'm just maintaining those certificates, but it's pretty nice that you can securely log into a device over the internet with a valid certificate.

I get the fraud angle, but I'm not sure how any other domain validated cert is more secure. eg RapidSSL

Thoughts?
 
What about all the free "flexible" SSL certs that are given to Cloudflare users? I'd be willing to bet there are many, many phishing sites on CloudFlare as well.
 
Seems like someone is not happy that simple Domain Validation is free of charge. Judging by the comments here they are being successful... Shame.

Charging for Domain Validation is a racket. Show me a CA that carries out manual checks for DV certificates.

Domain Validation certificates already have a "lesser" status than Extended Validation certificates and this is displayed by a browser. Just compare how https://hardforum.com and https://www.paypal.com encryption status looks in your browser.
 
The other thing to consider is if I were running phishing sites, before Let's Encrypt, I'd get *.phishersrus.example.org and use paypal... bigbank... etc; and you wouldn't have the slightest idea by looking at certificate transparency records; but since LE only issues individual name certs, you can go through the records and see all the cool phishing domains have been used. Paypal can (and should) be running alerts off of that, and getting the sites shut down -- once the sites are shut down, who cares about the certificates? Certificate revocation doesn't have a very good story either -- it barely works, unless the cert is high profile enough to get added to browser's delta pushed blacklists.
 
Spire3660 said:
Then we are right back to where we started before LetsEncrypt opened up, HTTPS is only used for profit, everyone else ignores it. Its not Lets Encrypt's job to be the internet police.
Click to expand...

Not really.

Get on a Military domain and every single site is HTTPS, every one. Not the internet and those public facing bullshit info pages, I mean on the real DoD Domains.
 
/dev/null said:
Also, it loos like "DST ROOT CA X3" is the root of letsencrypt.

Chrome:

3 dots -> settings -> https/ssl (Manage certificates) -> Trusted Root -> (select) DST Root CA X3 -> click "Remove" that should make them untrusted.
Click to expand...

Thanks, but will that just not make Chrome prompt to import the certificate next time? How do I get it into the Untrusted Certificates section?
 
This is nothing to be concerned about. The actual encryption doesn't need signed certificates, client and host typically negotiate a shared secret via DHE or ECDHE and that shared secret is what is used for the encryption.

All the certificate does is tell the client they really are communicating with the server that has the host name shown in the URL bar. And that is exactly what is happening.

Is fraud taking place at these sites? certainly, but that's not the job of the certificate authorities to worry about. They are not domain name cops and I do not want them to be.

Someday (I hope) certificate authorities won't be needed because DNSSEC and DANE will have taken over (I see hardforum uses DNSSEC but not DANE) and self-signed certs will be enough. Self-signed certs won't care what the domain name is, and neither should certificate authorities now. All they should care about is validating that the CSR comes from someone authorized to request a signed certificate for the domain. Anything else really is beyond their scope.

So no, Let's Encrypt is not responsible.
 
The problem really is education of end users. They have been conditioned for _years_, as a basic precaution to trust https not http. They know to "look for the lock" to "trust" a website.

if I have to go into a description of "domain validation" vs "extended validation", ciphers, connection protocols, browser version & upgrades/compatibility, etc then the battle is lost and you'll kill internet commerce where nobody trusts anybody.

There has to be a layer ABOVE the user to protect the user (with of course, controls to turn that stuff off). That layer has to be invisible to the user. It might be a ssl cert + dns + dnssec + certificate fingerprint. It could be something else.

When i say a way to turn it off -- I mean it. How many of you guys have run into "appliances" with no internet access but use "ssl" to secure a management page & chrome/firefox can't get you to the management page because it's using a weak cipher or ssl 3.0 or....whatever? I run into this daily with all types of internal only appliances...
 
Quartz-1 said:
Thanks, but will that just not make Chrome prompt to import the certificate next time? How do I get it into the Untrusted Certificates section?
Click to expand...
On mac, It looks different. I open up mac keychain and I can set it to "never trust" & that seems to work.

Chrome then gives me "NET::ERR_CERT_AUTHORITY_INVALID"

When I get on windows box (I control) I'll give it a shot.
 
You must log in or register to reply here.
Back
Top