Kebrum - raw data - cleanVPN, or not?

[Pattern_Juggled]

{direct link: cleanvpn.org/kebrum}


I've got alot of raw data here, and currently this one for me rates as:

unable to verify clean status with current analysis

Here's a list of links I've been using:
https://www.virustotal.com/en/file/0a24 ... /analysis/


Note these binaries are code-signed by a cert with a trust chain that goes back to one of the seriously dodgy "USERtrust" certificates that are tangled up in the NSA/DigiNotar root CA compromise of 2011:

Here's the root cert that one of the kebrum installers has been reported to drop during installation; it's categorised as a full CA, so if it's injected into the Windows trust store, it can be used to sign other certs, enable full 'ssl kneecapping' MiTM capture of plaintext https, etc
:
https://github.com/cryptostorm/review/b ... umroot.crt

Here's the openvpn.conf that unpacks from one of the installers...it's certainly a minimalist approach to openvpn parameters

https://github.com/cryptostorm/review/b ... lient.ovpn


This is a CRL that comes down from a "microsoft" URL, and when it is unpacked it's... not a CRL?

https://github.com/cryptostorm/review/b ... 2009-2.crl


That CRL-maybe is flagged by Sonicwall as malware:

http://software.sonicwall.com/applicati ... v_id=56997

We sent out a tweet recently seeking advice in untangling this particular mystery. Edited: see follow-on posts in this thread for additional data on this question that has since come to light.

Here's some analytic files on that www<dot>download<dot>microsoft<dot>com URL mystery:

https://www.virustotal.com/en/url/eecf4 ... /analysis/

https://web.archive.org/web/20140615000 ... ootseq.txt
https://www.virustotal.com/en/domain/ww ... formation/

...I felt I was close to untangling that mystery, but in the end it remains a nagging open question to me. Currently, the page loaded from this wget...

Code: Select all

view-source:http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt

Returns:

Code: Select all

1401D035E9E03F64E5

...legit? If it is, it's not mentioned anywhere in any MS or Tech Net or other resources I could find. And I looked. Alot. Like... alot. Maybe it's legit. It's not confidence-inspiring that, if you go to the HTTPS version of that strange microsoft URL, you get the somewhat dodgy "akamai" cert. It's dodgy in that it's not actually listed as issued to Akamai - but rather "Cybertrust Inc." - and that it's CRL distribution point is listed as "http://crl.omniroot.com/PublicSureServerSV.crl" with no other URLs for root CA confirmations, and the omniroot.com domain itself resolves to exactly nothing when visited (although crl.omniroot.com does resolve to a directory of CRL stuff, seemingly currently-maintained... and you can make of that what you will - yet another side-channel mystery to untangle for those curious about such oddball situations):

Code: Select all

view-source:https://download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt

Certificate:
Data:
Version: 3 (0x2)
Serial Number:
02:00:00:00:00:01:46:91:cb:0b:26:5b:ef:fe
Signature Algorithm: sha1WithRSAEncryption
Issuer: O=Cybertrust Inc, CN=Cybertrust Public SureServer SV CA
Validity
Not Before: Jun 12 20:35:45 2014 GMT
Not After : Jun 12 20:35:45 2015 GMT
Subject: C=US, ST=MA, L=Cambridge, O=Akamai Technologies, Inc., CN=a248.e.akamai.net
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:b1:50:be:18:42:78:da:59:48:15:14:be:23:84:
d5:9b:b5:7c:d6:fa:5d:62:c3:1a:00:ec:d0:70:03:
0e:74:00:1e:cf:73:ed:21:c6:af:90:d8:7f:d0:b0:
dc:99:55:c8:e1:e8:a9:28:83:79:ee:89:9c:e5:72:
16:40:45:90:ca:0f:a7:a6:b1:39:f2:c3:34:83:86:
de:74:c6:48:10:d3:e8:8d:81:0c:88:b7:40:0a:b5:
1b:30:77:72:45:8b:ee:69:57:99:eb:90:c2:76:4b:
f9:e0:ee:eb:b8:4f:1d:d8:2c:aa:f5:49:08:e7:5a:
09:ff:a3:39:96:be:44:e2:0a:ce:4b:6a:f7:02:c1:
ae:00:03:aa:e5:b2:aa:be:07:a7:25:30:c5:4e:01:
d5:e0:df:c8:7d:d0:db:35:2b:5e:d9:08:27:75:0b:
41:36:83:b0:bd:e1:a4:d0:1f:8e:2e:57:d5:13:9d:
d3:1b:5b:f0:22:e9:1d:58:df:f2:8d:7e:90:ee:90:
3a:4c:13:40:99:b1:a2:e2:26:f4:8696:7c:9c:
21:ca:73:7e:40:2e:b4:f0:9e:90:9d:26:44:86:9d:
fe:60:fa:f0:1f:eb:96:70:aa:d3:1c3b:da:e8:
d9:95:4c:8c:b5:df:df:85:b3:5f:60:b2:67:c1:b0:
04:1b
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Authority Key Identifier:
keyid:04:98:60:DF:80:1B:96:49:5D:65:56:2D:A5:2C:09:24:0A:EC:DC:B9

X509v3 CRL Distribution Points:

Full Name:
URI:http://crl.omniroot.com/PublicSureServerSV.crl

X509v3 Subject Key Identifier:
70:14:DB:83:91:FF:BC:43:DF:68:99:38:06:D6:5C:C7:14:47:AE:C2
X509v3 Basic Constraints:
CA:FALSE
X509v3 Key Usage: critical
Digital Signature, Key Encipherment
X509v3 Extended Key Usage:
TLS Web Server Authentication, TLS Web Client Authentication
Netscape Cert Type:
SSL Client, SSL Server
X509v3 Subject Alternative Name:
DNS:*.akamaihd.net, DNS:*.akamaihd-staging.net, DNS:a248.e.akamai.net, DNS:*.akamaized.net, DNS:*.akamaized-staging.net
Signature Algorithm: sha1WithRSAEncryption
46:e7:ad:32:dd:81:cf:50:bb:58:31:f4:59:93:8a:4f:6c:58:
c8:12:52:a2:af:b0:1c:72:20:ff:d5:1c:d5:2a:39:59:12:8a:
56:d8:af:45:c5:fb:ae:f0:62:c2:6e:40:5a:cc:c3:b7:67:e4:
87:da:80:9c:c2:c0:10:30:04:e1:5e:bf:ee:a7:19:36:2d:b9:
29:9a:b9:21:bc:36:22:0d:d4:a2ce:ec:02:97:c2:db:3e:
4d:e7:99:78:19:4e3f:ca:5f:62:61:23:1f:a3:48:ec:3a:
32:f5:4e:e2:b2:24:a2:f6:a4:41:3b:5c:46:07:31:13:81:b0:
a5:ca:51:8f:1b:60:22:ed:f8:60:1c:3f:fd:62:18:f0:0e:2e:
b6:44:f2:43:03:4a:a5:ac:1b:29:a8:ef:99:ea:bf:8c:30:70:
00:c5:2e:28:a1:0f:00:bc:fd:61:be:b1:4f:5f:a5:76:99:a6:
fe:08:89:2f:2d:ed:2b:ec:d6:07:f9:61:fd:3b:21:1a:67:fe:
4a:d1:1b:6c:00:1e:28:46:59:c6:cc:a6:a14e:85:49:0a:
2e:52:dc:d0:6d:f5:6d:b6:d2:82:cc:e0:8e:a2:c1:40:17:06:
09:fb:0f:85:15:dd:a8:b0:78:1b:26:6d:74:15:26:14:0e:46:
07:ba:b5:0f


-----BEGIN CERTIFICATE-----
MIIDUjCCArugAwIBAgIJANIa+D/u9pZ8MA0GCSqGSIb3DQEBBQUAMHoxCzAJBgNV
BAYTAlNDMQswCQYDVQQIEwJTQzERMA8GA1UEBxMIVmljdG9yaWExFTATBgNVBAoT
DEtlYnJ1bSBDb3JwLjETMBEGA1UEAxMKa2VicnVtLmNvbTEfMB0GCSqGSIb3DQEJ
ARYQYWRtaW5Aa2VicnVtLmNvbTAeFw0xMTAxMTUxOTE3MTBaFw0yMTAxMTIxOTE3
MTBaMHoxCzAJBgNVBAYTAlNDMQswCQYDVQQIEwJTQzERMA8GA1UEBxMIVmljdG9y
aWExFTATBgNVBAoTDEtlYnJ1bSBDb3JwLjETMBEGA1UEAxMKa2VicnVtLmNvbTEf
MB0GCSqGSIb3DQEJARYQYWRtaW5Aa2VicnVtLmNvbTCBnzANBgkqhkiG9w0BAQEF
AAOBjQAwgYkCgYEAykuEqVd8lEKKR0Fqzh9j+LuQF8v8L0U9MxXuytXjcNjM4GO0
PHtvaLQa3xH5b80u9fgoJ9PqTPSk7CUx7wo2IMpaIzlnDcxcCeXXWtpCxhuT1nYc
BdHKHXfMw3n5MdBx32mL+jittLx9ujOeTBvBjPnF72th+SimWTGP6fosZqECAwEA
AaOB3zCB3DAdBgNVHQ4EFgQUuwWDbr+bFADFS8rwZgGQFOK03bcwgawGA1UdIwSB
pDCBoYAUuwWDbr+bFADFS8rwZgGQFOK03behfqR8MHoxCzAJBgNVBAYTAlNDMQsw
CQYDVQQIEwJTQzERMA8GA1UEBxMIVmljdG9yaWExFTATBgNVBAoTDEtlYnJ1bSBD
b3JwLjETMBEGA1UEAxMKa2VicnVtLmNvbTEfMB0GCSqGSIb3DQEJARYQYWRtaW5A
a2VicnVtLmNvbYIJANIa+D/u9pZ8MAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEF
BQADgYEApyiSIezMgY9MtnS50qGTbXhSXg2y2IctVRidVlMZpNFqv6hM84+auyF3
dGEVkmtwz0JXNNnPeW/ZJH6SmV5/TjZ227QzxqgMNk95+QJCUcjWeZZGmw5QJMbh
DEaGKzFjgBO9GLT3LLUpm3k/WnZgQvz7/bEcbKHkKPPOkCmgzDM=
-----END CERTIFICATE-----

If you do load it via https despite the fake cert, you get this:

Code: Select all

<HTML><HEAD>
<TITLE>Service Unavailable - Fail to connect</TITLE>
</HEAD><BODY>
<H1>Service Unavailable</H1>
The server is temporarily unable to service your request.  Please try again
later.<P>
Reference&#32;&#35;6&#46;44301602&#46;1425174712&#46;7817c19
</BODY></HTML>

But yeah, there's something fishy here. This is the ssl-labs test:

Code: Select all

https://www.ssllabs.com/ssltest/analyze.html?d=download.windowsupdate.com

Maybe Microsoft just has some old server sitting around that is handling these requests, and it's got a bad cert, and it's... umm. Something something something. And it's all standup. Except it gets pulled by alot of verified malware during their installs, or C&C, or... something.

But why, then, does the SSL certificate one is served when one visits the https version of the page have organization name that's not even Akamai, let alone Microsoft? These questions become fractal in nature, branching off into more and more sub-sub-questions that each has its own nest of strange occurrences. Some of those strange occurrences are, most certainly, legitimate once researched a bit: there's many strange things in the world of CAs that are legitimate even if pretty odd.

But, for every one of those I've chased down to an explanation that was credible and well-documented if not terribly elegant, there's one that just keeps forking into more and more strange side-channels. It becomes a question of time constraints, in terms of chasing them all to ground - something I don't claim to have done personally. However, of the ones I have chased to ground, there's been a roughly equal mix of legit albeit needlessly complex explanations, and complete mystery answers that themselves are confirmation of something untoward going on.

Note that follow-on posts in this thread now explore in much more detail this www.download.windowsupdate.com mystery and track fractal fronds deep into several well-documented families of malware in the process. Rather than making this post longer by pulling those data up into it, I've let the extra data accrue in subsequent posts.


But that's not the only odd certificate-related hostname that appears in the Kebrum installers activities once it's run and packets are logged. Here's the other mysterious hostname called during one of the install actions.

Code: Select all

https://www.virustotal.com/en/domain/crl.verisign.com/information/

This was tweeted recently, as well, in terms of one of the reply elements from WHOIS...

Currrently that weirdly-formed subdomain resolves to 23.9.85.163:

Code: Select all

https://www.virustotal.com/en/ip-address/23.9.85.163/information/

And there's a bit of weird in those results, if you look closely. But look one back in time, to what it used to resolve to: 23.7.69.163

Code: Select all

https://www.virustotal.com/en/ip-address/23.7.69.163/information/

So, yeah, someone's doing something clever here. Don't ask me how, I've not untangled it thus far. But it's not legit, despite being clever!


Here's an old marketing brochure from now-AWOL AddTrust - complete with striding, purposeful businessmen! - bragging how "AddTrust ensures that its root keys are embedded in ubiquitous software packages and Internet browsers," and that the "AddTrust business concept is entirely geared towards minimizing your time to market, so that in literally a month you can start providing services and generate income."

That service was selling root CA signing authority to anyone who could pay for it. The bunk root certs that resulted from that orgy of cert-signing are still very much alive and kicking today, as evidenced by their appearance in the Kebrum installers, as root certifying authority for the code signing process itself. Yay.

Code: Select all

http://web.archive.org/web/20071027161952/http://www.addtrust.com/tsp.shtml

Here's a still-legit AddTrust root cert...

...and here's a notably non-confidence-inspiring AddTrust root cert...

Code: Select all

https://ssl-tools.net/certificates/02FAF3E291435468607857694DF5E45B68851868.txt

See the difference? All but identical... but divergent MD5s and other cryptographic materials. Took me a few hours to figure that one out... more than I care to admit. There are three legitimate (Swedish) Addtrust entities in the official root CA records. Here they are, with their respective root signing certificate fingerprints (SHA1):

• AddTrust Qualifi­ed CA Root 4d23­78ec­9195­39b5­007f­758f­033b­211e­c54d­8bcf
  AddTrust Public CA Root 2ab6­2848­5e78­fbf3­ad9e­7910­dd6b­df99­722c­96e5
  AddTrust Class 1 CA Root ccab­0ea0­4c23­01d6­697b­dd37­9fcd­12eb­24e3­949d

edit: this is somehow related to the USER trust CA compromise, but to be honest I am not going to burn more time figuring out exactly how.


edited to add: here is the official CA information on the legit "AddTrust Class 1­ CA Root" entity, which is - inexplicably - Swedish)...

Code: Select all

https://ssl-tools.net/certificates/ccab0ea04c2301d6697bdd379fcd12eb24e3949d.txt

Are those code-signing trust chains legit, or are there compromised Comodo/DigiNotar root authorities involved? I have not done enough validation of this step in the process, as of yet, to say definitively either way. For now, let us say that the code signatures on these binaries are not proved to be illegitimate, but at the same time aren't 100% confidence inspiring either.

Here's the code blobs I've found, which include both an earlier version (sometimes called "version 1") and the later version. This later one is almost 20 megs; the earlier one is closer to 16. Those are the only two I've been able to find thus far. The naming gets mixed up alot, tbh, but the hashes tell the distinction:

KebrumVPNSetup2.exe

(19.12 MiB) Downloaded 1721 times

malwr.com analysis:

Code: Select all

https://malwr.com/analysis/OGFkYzg0M2Q5YTViNGZlMmJjZGIxOWE2Y2RjM2Y3N2I/

pcap from the install process as captured by the cuckoo sandbox VM used by malwr.com (SHA256 hash of the file: 211691d624089f7e9e7c9d05805a5c49d45c68f8782c895a2b9d1160e3c3f782):

211691d624089f7e9e7c9d05805a5c49d45c68f8782c895a2b9d1160e3c3f782.pcap

(110.98 KiB) Downloaded 1442 times

Note that the pcaps confirm direct contact to and download of files from the two mysterious hostnames explored in more detail above.


Next, here's a different version of the Kebrum installer this one approximately 16 mb:

setup.exe

(15.83 MiB) Downloaded 1668 times

And the virustotal run on it:

Code: Select all

https://www.virustotal.com/en/file/0a24d048e5d98660495cc7d102dfd5a10023fdd6f2c75fb813192c3a0cac12d6/analysis/

Feel free to run all the scanners on each of the files, and the stuff that unpacks when you execute them in a VM. I have - if you do it, you'll see the results already precomputed in all the major scanner engines. Been there, done that.


So... clean?

Cheers,

~ pj

[marzametal]

version 3? Wow, that smells like hmmmm, W7 is v6, so Vista is 5, XP is 4... no way, Windows 98?

[Pattern_Juggled]

version 3? Wow, that smells like hmmmm, W7 is v6, so Vista is 5, XP is 4... no way, Windows 98?

Yep, it dates back a long, long time.

It's obviously not being used for any legitimate Windows purpose any longer... which begs the question: what use is it serving?

Because someone's still using it. For something.

A great next step is to visit all the archive.org snapshots of the page it links to and collect the text it's been serving over all those years. The way in which those characters change will likely help sketch out a pattern.

Remember those old spy agency "code broadcasts" on shortwave radio? Can't help but be reminded of them....

Cheers,

~ pj

[marzametal]

We need Maxwell Smart!

This has peaked my interest. I was looking for a reason to install VirtualBox and I still perve in WireShark from time to time. OMG, I never knew the VT website could look up IP address history. That is friggin' handy! I will have a look at the other sites too (malwr, archive).

I was not suprised to see Akamai pop up. I HATE CONTENT DELIVERY NETWORKS!

[Pattern_Juggled]

I was not suprised to see Akamai pop up. I HATE CONTENT DELIVERY NETWORKS!

You only think you hate them now... if you get a bit deeper into this, you'll see the central role they play in the entire process. I've noted elsewhere how counter-intuitive it is to be using CDNs - legitimately or not - to distribute such things as certificate revocation lists. That just doesn't make much sense, and leaves open the door for all sorts of clever exploits that make use of the fluidity of CDN-based data delivery.

Cheers,

~ pj

[Pattern_Juggled]

I've taken the liberty of splitting off the "funky CRL subdomains" topic into its own dedicated thread, as it had basically taken over this one. I may go back and pull some of the findings still in posts above, relating to the CRLs, and move to the new thread, but that seems a spot of work so I'll avoid doing so for now

Do keep in mind, however, that it's the Kebrum installers calling these mysterious subdomains during their setup process - so this is directly relevant to the Kebrum analysis itself. At the same time, we've noted it's not only the Kebrum installers that make such calls; thus, having a standalone thread for that work makes sense as it can be managed and maintained independently, and referenced as needed.

Cheers,

~ pj