If you open a website that Windows doesn't have a valid root cert for, that CA/Root cert will be looked up from the list (which is cached localy as far as I understood)
I'm still working to integrate the "Certificate Trust List" into this process, because that's the one that actually gets pulled during (for example) the process of executing the Kebrum installation binaries, above.
From the pcaps, here's what happens (apart from the pulling of the 'authroot.txt' file, which is outlined in full above:
1. A process within the instantiated installer initiates a DNS resolution query via...
Code: Select all
User Datagram Protocol, Src Port: blackjack (1025), Dst Port: domain (53)
2. DNS query syntax is as follows:
Code: Select all
95 15.546665 192.168.56.101 192.168.56.1 DNS 76 Standard query 0x6bfc A crl.verisign.com
3. primary nameserver indicates a CNAME alias to:
4. that hostname, in turn, is a CNAME alias to:
5. That, in turn, resolves via A Record to:
6. HTTP request of:
Code: Select all
GET /msdownload/update/v3/static/trustedr/en/authrootstl.cab HTTP/1.1\r\n
Here's a screenshot of the underlying wireshark'd packet flow:
Which IP address - 18.104.22.168
- is indeed located in an Akamai-controlled block
. It's also an IP address that is associated with a mix of (Verisign-affiliated, as Symantic now owns GeoTrust, Thawte, RapidSSL, and Verisign CA businesses) hostnsames that have resolved to it in the last 18 months alone...
VirusTotal's passive DNS only stores address records. The following domains resolved to the given IP address.
An awful lot of nasty stuff has been communicating with that specific IP address recently (although it's of course quite possible that all that badware is simply doing routine background Windows cert-update stuff entirely unrelated to any badness, in which case this exact pattern would appear but would indicate nothing improper on the part of ):
Latest files submitted to VirusTotal that are detected by one or more antivirus solutions and communicate with the IP address provided when executed in a sandboxed environment.
13/56 2015-02-26 15:41:56 fd54cc6001a6dd809672dac15d97890a8738bcb701680210879acb79fed7f0ee
37/47 2013-05-21 23:42:34 97d56e716e29f566bd227c17f1531b11f3f66678bb53e156f7e66b66d1038c8a
3/47 2013-05-21 23:31:52 be0bb1db750c0a7c29d3db1af20b4b6fc407bf01a901a7d699006657717f8853
3/47 2013-05-21 23:31:42 ac0c23dfaf427190de25e915ad3f30da85753e60d8b91cef0dcad40854f0753b
5/47 2013-05-21 23:24:33 7e4be4daf139b3c79a532e02fae4810ea9408a3598050b94590ed67811e649dc
5/47 2013-05-21 23:22:28 617ade6180c64f8dc07ad38847f0749520f13e8e74c5a4a59489f716525b6c08
5/46 2013-05-21 23:19:51 20c0ab864a4338b714c299716fe9fc488768d01a1fad9fee6c6288e2536eec02
36/47 2013-05-21 23:17:11 ac4bffc0b2c321db9bc516acf8371cfc311d5ee3f25100af30869a5fc71c22d1
3/47 2013-05-21 23:16:29 1c096e8eb3af484fd9667bbb3c626eb1db44a0fad0fa1e67b7d1c8c7ef5aa7c4
35/46 2013-05-21 22:42:48 e2ec948c1bb9bb08f5608b6c93484bf7b26cc673c130ed1403491cf27ea5148a
36/47 2013-05-21 22:41:23 8eae3d417cd295581be4648d811cce0801e35b285f2243b9818983aa0d892d01
38/47 2013-05-21 21:58:54 1cd07c608c6b046db532f17f1f24654291fe762eea8f437b92171bbcce460da9
3/47 2013-05-21 21:55:29 b709088c6b681912a7e4a0c8e28acf51e6c410f3d9223b8b2056a1e3a0dcfef9
8/47 2013-05-21 14:06:12 636898c5358a35856e37a6f22ea1f840cd7343e71e64df98fb08260029513dc7
8/47 2013-05-19 00:36:08 469fbe016536dbb42266f38147dd07578a21e048217d84b17c9b4f1cc0fd7151
1/47 2013-05-18 15:34:09 f968f6102333afe793d8cce85d35b89a77130e182e6dc473b7e51f5971dcf228
32/46 2013-05-16 09:16:54 60a9e49e8007429a4bdd6a52d9541a38662d241f2653c2ed010f280e92658e7b
1/46 2013-05-15 04:43:19 52070c17d639df3fd921bb1d0c52c13220aa9e84fe1dc20ca7a8eab53712ac0b
I still don't understand what purpose the complex welter of subhostnames serves in this: wouldn't resolving crl.verisign.com
to 22.214.171.124 directly be more secure, less complex, and easier to administer? I say that with an awareness of these things given our use of similar layered hostname-IP resolver pools (our Hostname Assignment Framework
), so I'm as much curious as anything else - assuming it's legitimate, then there's some reason they add that extra layer of arbitrary subhostnames into the process flow). Of course, I do understand the benefits of putting akamai in as one lookup layer... sorta. Only not really.
Do you really want to outsource to an amorphous cloud-based CDN the delivery of... CRLs? Or in this case CTLs (certificate trust lists)? These aren't exactly multi-gigabyte streaming video files. They don't change every 5 minutes (do they?), and they aren't subjected to enormous pressure to cut every millisecond from RTT pingtimes (are they?). They're compact, relatively static files that are extremely - extremely!
- security-relevant given that they control what root certs are or are not injected silently into the windows trust store locally on countless millions of PCs.
Subvert that process, and you've got one bad-assed exploit avenue. You can now do things with those PCs unimaginable without that subversion... like, ooooh, MiTM all of their https sessions invisibly, without any hint it's going on. At massive scale.
It would seem to me, naive as I am, that Symantec/Verisign/Thawte Corporation would - given that they are a Certificate Authority
- want to actually manage the process of controlling and delivering those CRLs and CDLs themselves, in-house, firsthand. Managed closely, with audit trails and accountability. Maybe a hostname like svrintl-t1-aia.verisign.com
helps that, via some internal tracking process. Seems alot of complexity just asking to be broken, to my way of thinking - but then again my world includes a different mix than that of the folks at Symantec who likely designed this.
Finally, for this point anyhow, I'm really not sure how one would do an audit trail given that this is Robtex's graphical representation
of what happens to get a request from a Windows machine wanting a CRL (version 3, which dates back to 2006... because of course, that makes sense?) and asking the DNS system to give it an IP address to which packets can be sent:
. . .
Anyway, so presently
we see that crl.verisign.com
resolves via a somewhat complex, multi-step process, to IP address 126.96.36.199.
That's not always been the case; a look back through records shows that
these mappings have been noted as in effect at in the past 18 months:
Which is twenty different IPs - all ending in 163, what are the chances? - since August of 2013. So each IP lasted less than a month, on average. They are:
I haven't looked into all of these yet - they should all cleanly WHOIS to either Akamai, or Symantec... right?
I'd have more confidence - and perhaps not include the question mark - if stuff like this didn't show up in my research on this post. First, malware that explictly calls some of these verisign.com CRL hostnames:
Second, this anomaly when checking the WHOIS records for crl.verisign.com (yes, doing WHOIS lookups for subdomains is a bit nonstandard, but it can still provide hints of interesting things):
This, I don't even remember where I screenshotted it tbh, so I'm sticking it here to remind myself (or anyone else curious) to follow up and see what's in the file referenced. That version is also very old, isn't it?
Oh, and here's the "CSL" that comes out of that cab at the "windowsupdate.com" URL (which itself cascades, via a series of DNS zone file records returned in response to the initial resolver request, from CNAME www.download.windowsupdate.com
to CNAME www.download.windowsupdate.nsatc.net
- both of which are subdomains, not http-based resources... which is not supposed to be possible, is it? - to CNAME download.windowsupdate.com.edgesuite.net
to CNAME a767.g.akamai.net which is actually - woohoo! - a real A Record listing IP address of 188.8.131.52, which is the actual IP address that actually provided the below-attached file to the test run we did of this installer - pulled out of the full-payload pcaps gathered during the process) discussed earlier in this thread...
That, in turn, unpacks to this .stl:
..which, and you'll get used to reading this alot, I've not been smart enough to unpack using any tool I can find (though I'm not a Windows native, so perhaps it'll be easy for others - I hope so!). It's pretty big for a "certificate trust list," in any case. Not a CRL, remember... a trust list
(incidentally, IP address 184.108.40.206 a little odd in that it's been the answer to DNS resolution requests for domains nextgennbn.gov.sg, abercrombie.com, caranddriver.com, rediff.com, mashable.com, a184-25-56-93.deploy.static.akamaitechnologies.com, and nfl.com... all since December of 2014. That's quite a record! Now Akamai is a CDN, of course, so they can remap IPs to client domains as often as they want, and perhaps they've been fast-fluxing this stuff in the last few months because, ummm... something something. Because of some obvious corporate reason I'm not smart enough to figure out by myself, obviously.)
Anyway, authroot.txt & authroot.stl both come down as confirmed by pcaps. They come from deep within Akamai, via a series of CNAME redirects that's pretty impressive. They end up at IP addresses that are impressively ecumenical in the sorts of domains (and subdomains) to which they'll answer.
And it's all related to the authority to inject root certificates into the Windows trust store arbitrarily, without any approval (or even admin access) from the user required. Which is to say: figure a way to hijack, even temporarily or ephemerally, that process and you've got the door open to root cert inserts at an unmatched scale... it makes Superfish seem a drop in the bucket, in comparison.
Has someone managed that trick? Is there evidence of it in these files? I honestly don't know. Personally, I can't rule it out based on the data I've collated thus far... nor can I say I've got the proverbial smoking gun that it has taken place (or is taking place). Additionally, it fails to pass my tech-world sniff test... admittedly not terribly objective, and far from a perfect metric: I'm a bit jaded after years of network security front lines & yes I have been known to see ghosts in the shadows when there's only shadows.
Even so, this is all... so terribly ripe for exploitation. Were it my job to figure out how to inject root certs into alot of Win machines without causing a fuss, I'd sure as heck be checking this whole complex, unstable, multi-entity, http-encoded mess really closely for any little corners to pry up and use along the way. That smells like ripe ground for exploits to me... and I've had enough time around exploits to have a half-decent gut sense on that sort of thing, albeit far from perfect.
Whatever the case, it's fascinating. It's very instructive, in terms of the layering of DNS and CA-based certification that produces certificates in the local trust store, and thus the magical "green lock in the browser" that means https is secure. Only, of course, it doesn't... not at all.
edited to add
: these are recently-enumerated
examples of malware that have the hostname "crl.verisign.com
" embedded in their post-compile strings somewhere; as noted before, that could simply be a result of them including routine CRL administrative matters in pre-compile code that comes through as binaries and thus pops up as this kind of list (indeed, on the same virustotal page one can see a list of non-flagged binaries that include this URL in strings but haven't raised red flags on virus scanning sites - which may or may not indicate they're clean files, tbh)... but it's something I'd be remiss not to at least note. I've not gone to them and checked each one to see if they'd have a legitimate reason to be calling a verisign CRL hostname as part of their compiled-in duties...
Latest files that are detected by at least one antivirus solution and embed URL pattern strings with the domain provided.