Security tools versus SSL hijackers with root certs

You can download Super Fish installer plus a host of other software using Komodia engine for testing in a VM here: https://github.com/hannob/superfishy . Also other incident related data located at that web site including certificates.

Superfish private key here: http://www.reddit.com/r/netsec/comments/2wfiyl/extracting_the_superfish_certificate/

 

Nice find, but Superfish is VM aware.

 

Best way to detect a proxy server on your PC is to use TCPView as I mentioned previously or other IP connection monitoring software and look for outbound connections from application port 80/443/8080. etc. to localhost i.e. 127.0.0.x any port.

Also a good firewall with localhost loopback protection will also alert. Note to PrivateFirewall users. You're out of luck since it doesn't monitor localhost connections; one reason among others I stopped using it.

Unfortunately, determining whether the proxy server activity is bad is not so easy since legit software uses them like Avast's web shield. I also understand that Avast is now monitoring HTTPS connections.

 

Komodia bad guy list expanding. UtilTools Anti-Virus added today.

http://www.kb.cert.org/vuls/id/JLAD-9U8LSK

 

Another way to detect Superfish per: https://www.us-cert.gov/ncas/alerts/TA15-051A .

According to Robtex, the below domain only points to IP 207.182.156.18. So blocking that IP address for all outbound could also be a trigger for further investigation. Best though to block on domain name if your firewall allows it.

To detect a system with Superfish installed, look for a HTTP GET request to:
superfish.aistcdn.com

The full request will look like:
http://superfish.aistcdn.com/set.php?ID=[GUID]&Action=[ACTION]

Where [ACTION] is at least 1, 2, or 3. 1 and then 2 are sent when a computer is turned on. 3 is sent when a computer is turned off.

 

Here's a link to Avast's response to criticism over their HTTPS proxy filter: https://forum.avast.com/index.php?topic=167112.msg1189100#msg1189100

At least in Avast's case, they issue a unique cert. for each installation thereby eliminating the common private key issue. They also state they leave EV certs. alone and exclude banking sites via whitelisting. Hum ................

But it's much worse. From Mr. PrivDog himself here' a link of other security software manufacturer's that use their own certs. to intercept HTTPS traffic: https://www.melih.com/2015/02/25/htpps-proxy-the-insight-what-you-didnt-know/ . Guess he's trying to get some absolution for his tactics in this debacle.

On the list is:

Avast
BitDefender
Bluecoat
Dr. Web
Eset
Kapersky
Symantec

-Edit- Also Trend. Missed that cert. in Melih's blog posting.

 

All right, I admit Avast is so far taking the best approach against this problem within what I've seen, but some points are not yet clear. I'll wait for their official answer, please let us know if they published it.

 

Although all those vendor trying to make it looks like unfortunate bug, it's actually not a bug like coding error, it must be intended design or ignorance.
I.e. either they actually don't take security seriously or they are noob on TLS security. But latter shouldn't be the case in any security firm as it means they are worse than amateur in security.

 

I believe the parties involved response will be similar to Comodo's. That is at present, this is the only way they can inspect HTTPS traffic for crapware. Actually, there is another way; deep packet inspection: http://www.a10networks.com/resources/files/A10-SB-19113-EN.pdf . But that is worse than decryption by certificate.

The real question is should they be doing so in so? That saying "The lesser of two evils" is playing in my mind now ..............................

 

You might be interested in this: https://gist.github.com/Wack0/f865ef369eb8c23ee028

Appears Qustodio contains a rootkit element courteous of the Komodia component.

 

Since Eset is on the list of products that monitor SSL traffic and I am interested in their security suite product for purchase since it has a lot of features I am interested in, I decided to check out their SSL protocol processing.

Downloaded their user manual and went thru the SSL protocol section a couple of times. For the life of me, I could not figure out why that feature exists except to allow for monitoring of malware, etc. HTTPS traffic. All the other features appear to be a carry over from their corporate product. Worse it appears the processing is broken and could leave you in worse shape than if it was never activated. An interesting read here: https://device5.co.uk/blog/do-not-use-eset-ssl-protocol-filtering.html .

 

The blog made a nice point about ESET's downloads offered over HTTP. Unfortunately almost all antivirus products can only be downloaded over HTTP, even though it's already 2015 :S And what is strange is the automatic update function usually uses a secure connection and some signature verification as well, but apparently they don't think it's necessary for the initial product download :S

Ugh, all Komodia's **** should be detected as malware by all AV's.

 

Isn't this DPI doing basically the same thing?

Well, I like EFF's comment that "malware is not the only threat" (see my sig!). And EFF's data collected from HTTPS Everywhere user strongly suggests there have been some actual MITM. So how can these be balanced? IMO it all depends, but at least in my case I much prioritise SSL visibility cuz I have other layer against malware while not many layer against MITM.

Agreed, it's a pity that most AV and other security software installer are delivered via http.

 

Hi itman. Melih's post has since been removed. Besides what you've posted, was their anything else of interest?

 

I guess the real question is if using HTTPS to "protect" normal web traffic is appropriate and was the move by content providers to do so purely based on security reasons?

HTTPS, SSL/TDS, and digital certificates were originally designed as a method to allow for safe e-commerce activities on the Internet. Their application was limited in scope and I believe it is safe to assume that the designers felt that nefarious activities by an e-commerce site would be self-defeating since they could be easily traced and the site would lose a customer. The increased use of HTTPS for non-e-commerce activity however is another matter since it does open the door for possible exploitation by the content providers. Hence, the current situation where the security industry has reacted by developing methods to intercept HTTPS traffic for web filtering purposes and as been has shown, not doing so properly. In other words, making the situation worse.

It is getting to the point that digital certificates have evolved into PGC - Pretty Good Certificates akin to PGP - Pretty Good Privacy which is 100% trust based.

 

This is interesting.

This month's MSRT download has SuperFish removal: http://blogs.technet.com/b/mmpc/archive/2015/03/10/msrt-march-superfish-cleanup.aspx .

However from this excerpt, only applies to Lenovo PCs:

Microsoft worked with Lenovo and Superfish to add detection with a root trust repair solution for Superfish to our real time protection products on February 19. At the same time, we shared detection guidance through our MAPP and VIA partner programs to drive an industry cleanup. Our cleanup targets Lenovo machines as this is the only place the vulnerable version of Superfish is encountered. The graph below shows the number of Superfish encounters since detection was added.

Not according to Malware Tips: http://malwaretips.com/blogs/superfish-fs-removal/

 

FYI, here is an Avast knowledge base article explaining its HTTPS in more detail: https://www.avast.com/FAQ/AVKB190

Cheers,
Vlk

 

I congratulate Avast on the detailed explanation of the web shield HTTPS processing. There is enough information there for a user to make an intelligent decision on if using the feature is in their best interests.

I found the following excerpt from the Summary section to be illuminating:

Avast detects an average of 30,000 infected and blocked unique HTTPS URLs every day. Currently Avast prevents nearly 2 million users from downloading malware, or accessing malware distribution sites using HTTPS every month.

It goes without saying that industry reform is urgently needed since current secure protocol data transmission processing is clearly broken.

 

Hi Vlk,

While you're here, even though your site is HTTPS, products installer downloads still go over HTTP.

 

Also appears Avast's approach is "all or none" in this area. Whereas with Eset Smart Security, I can chose to turn on web filter of HTTPS, port 443 but turn off SSL protocol checking and prevent Eset from installing it's own certificate in my root certificate store. Also with Eset, you can control what will be filtered via application, IP address, or domain what is allowed or not allowed. I prefer to be in control of my Internet financial/e-commerce site checking hence I use EMET's certificate pinning.

 

All our binaries are digitally signed (and check their integrity) so we don't rely on HTTPS to do that for us.
We are using Akamai for distribution of binaries and unfortunately, their CDN still heavily favors HTTP traffic over HTTPS -- I mean economically, as HTTPS downloads are about 4x more expensive than HTTP -- which makes quite a difference: for example, just in 2014, we pushed out more than 180 PB (i.e. 180,000 TB) worth of binaries so you can imagine the cost... (or you probably can't ;-)).

Thanks
Vlk

 

"Food for thought" when evaluating if any entity should be fooling around with your encrypted traffic.

Here's an important question to ask when assessing if a service or app that uses encryption is secure: Is it possible for the service provider itself to circumvent the encryption? If so, you cannot trust the security of the service. Many services like Skype and Hushmail promise "end-to-end" encryption, but often times it still means that the services themselves have the keys to decrypt the product. True end-to-end encryption means that the service provider cannot look at your communications even if they wanted to.
Ref: https://freedom.press/encryption-works

The NSA spends $250m a year on a program which, among other goals, works with technology companies to "covertly influence" their product designs.
Ref: http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryption-codes-security

 

Thanks for informing us, I'll look it

But don't most common people know code signing? So if they are attacked via MITM, and attacker replaced official download with malicious Avast which have different sig but still trusted in OS, then most people would be compromised.

I understand cost aspect, and have to admit don't know those actual economy thing, so my question is isn't there other alternative way? SFTP or FTPS is also expensive, or have another problem?

Thanks in advance.

I don't see why you posted that here, That theme had discussed in other threads like encryption and NSA thing but do not directly related to "Security tools versus SSL hijackers with root certs".

 

Or no sig at all, probably most users won't notice the difference between a UAC popup from a signed program compared to not signed.

 

This drives home the point I am trying to make; that current digital certificate processing is flawed. One of those flaws is no mechanism to verify that the certificate chain has not been altered. As I noted previously, EMET certificate pinning although only applicable to web site verification won't protect you against that either. What is needed in that regard is some type of two factor authorization whereby the OS verifies the web site or download certificate path to one stored on the originator's server for example.