Decrypting usenet headers

[Somnambulist]

I am trying to decode some of the headers from some posters on usenet, to determine if they post from the same host. One is using individual.net as provider and the other is using eternal-september.

Does anyone know what kind of encryption they use? Here is an example individual.net header I am trying to decode:

Code:

X-Trace: individual.net q8cNyBZr8H6vQw1XWBg3Lw/QBrMuMlRjgDz4A0vDV6dfOCokS6

And here is the eternal-september header:

Code:

Injection-Info: mx02.eternal-september.org; posting-host="3a7acd6b6bbfe9e4e33e3a357762cf34"; logging-data="10878"; mail-complaints-to="abuse@eternal-september.org";    posting-account="U2FsdGVkX19bCgrkbEjt4gDrFKNANCce"

Where the relevant part is "U2FsdGVkX19bCgrkbEjt4gDrFKNANCce", which is the "posting-account" part. The posting-host part is irrelevant in my case.

The eternal header is base64 and starts with "Salted__" so I am assuming some form of AES encryption, but I'm not sure. According to a source, this string contains the account name of the poster, but no personal information, so the idea here is to find out if several persons using eternal-september are posting from the same account.

Any ideas are welcome.

[radix]

Code:

echo -n 'U2FsdGVkX19bCgrkbEjt4gDrFKNANCce' | base64 -d | xxd
00000000: 5361 6c74 6564 5f5f 5b0a 0ae4 6c48 ede2  Salted__[...lH..
00000010: 00eb 14a3 4034 271e                      ....@4'.

If we pull out the Salted__ bit then you get a len consistent with a number of hash types (32).  However that means the salt is hiding elsewhere.  Without seeing the source it would be hard to figure out a) the hashing, b) what value in the header is the salt.

[Somnambulist]

If we pull out the Salted__ bit then you get a len consistent with a number of hash types (32).  However that means the salt is hiding elsewhere.  Without seeing the source it would be hard to figure out a) the hashing, b) what value in the header is the salt.

Well, we do have the logging-data="10878" part, also the date of the post, which in this case has the header:

Injection-Date: Thu, 19 May 2016 14:16:57 -0000 (UTC)

[radix]

Sure, but without seeing the source you have no idea if those have any relation.

[pragmatic]

This looks like symmetric encryption to me as first suggested, sleep walker. This certainly appears to be the default openssl format, where the first 8 bytes after the "Salted__" piece will be the salt, and the remaining (8) bytes are the encrypted data.

This does tell you a few things:

• This is most likely a block cipher, and moreover one that uses 8 byte blocks. DES or 3DES would be the most obvious candidates.
  
• The presence of this "Salted__" piece means that this was generated using a "passphrase" argument, rather than supplying a raw key.
  
• The underlying plaintext is 7 or fewer bytes. If it were 8 or longer there would be another ciphertext block (assuming standard/openssl default padding rules). This seems short for a unique account identifier but maybe they don't have that many, or maybe the "plaintext" is actually a packed int or long or something in which case it would be plenty. If it's truly an "account name" as you suggest, it's a short one.
  

What is doesn't tell you is what exact algorithm was being used, or what block mode was being used. My first guess would be CBC just because it's probably the most common, but there's no way to distinguish that here.

Your theoretical attack path looks like this:

• Attack the passphrase. This means you need to understand the key-derivation algorithm OpenSSL uses (which is here apparently) and then use the resulting key material (and IV material when testing non-ECB modes) to attempt to decrypt the ciphertext. If the output padding is correct, looks reasonable in terms of an identifier, and the passphrase looks like something a person would type then you've probably found the passphrase.
  
• Attack the key itself. Try every key and see if you get meaningful results. This will only work for DES and only in ECB mode. The upside is that it has a finite run time so you will either find it or you won't in a somewhat short order depending on your hardware, but truthfully this option isn't particularly realistic as I'll discuss below.
  

Now, you'll notice that I said "theoretical" attack path, because you have some serious problems here:

• I don't know of any tool to do either of the above attacks in any reasonably performant way. You can fairly easily write a program to do this, but it's going to be dog slow. Neither hashcat (nor John) can do what you're looking for to my knowledge.
  
• Perhaps as part of why no standard tool chains exist to do this, you are going to get tons of false positives like this. The only real sanity check you have is that the padding is correct, which is a very weak check. Beyond that you might be able to assume something about the underlying plaintext structure but then again maybe not. If you're doing the passphrase attack, for any passprase which generated a "valid" output you could attempt to decrypt a different ciphertext with that same passphrase and see if it also generates a valid output with the same basic account info structure, but long story short, this is going to be messy. For the attack against the key directly you can't even do this, hence why it's not really a viable option.
  

As for the "individual.net stuff", that's even more opaque. Assuming that encoding is base64, the output is 37 randomish bytes with no obvious meaningful structure. Without more samples I got nothing.

TL;DR version of your original question: it's very doubtful you're going to be able to make this correlation, at least not without more information.

I did recover the posting-host, but you said that was irrelevant so i'm assuming that won't help you.

[Somnambulist]

TL;DR version of your original question: it's very doubtful you're going to be able to make this correlation, at least not without more information.

Thank you for that very informative post, I assumed as much but I still wanted to see if there was someone out there that could give me some more infromation, which you did, unfortunately it was the same conclusion...

I did recover the posting-host, but you said that was irrelevant so i'm assuming that won't help you.

Yes, it's just a md5 IP, so that cracks in under a second with hashcat.

As for the "individual.net stuff", that's even more opaque. Assuming that encoding is base64, the output is 37 randomish bytes with no obvious meaningful structure. Without more samples I got nothing.

Well, for what it's worth, here are the X-Trace headers from my last individual posts:

individual.net OeIYWJPyf5rdp0IlMHyBPAFnfp+RA412tm285iqgU5R6GiiRk=
individual.net LOkweuyhAZuVtYh9sAtC5AJeEIgSU2RT25gUNxzG0xx1ze9j0=
individual.net do7lyjDwZBsEDkl3V3q0Jg27QQiDB1Q/brYTJlqRdlnKr/Skw=
individual.net KAJewCub4zOMAv+7HVArZw+ysZQhuLv37WsdhQE5gOshhPV88=
individual.net AIIglA/DMVTRxkskLXEyLAG3ukdyoCF4SPzBmP8zSfxajJIpk=
individual.net wBJOpYtROJaMKAjShzcN3ggCHF0w5HTy8TxTjXMcau0woXlZY=
individual.net tK0QZOrtHraHc8fegGuEGANQGNuTmZq+dQpPojyyM3alEel8U=
individual.net r5L2+sLwdfJH+cnD7gCQ7wILmf9fQym1/Arh9hMwmSpBp91As=
individual.net OVsCAsn++wCb53848c8NmQ09ttXdO1Y0jKKg46nQ2kfzX2OgI=
individual.net 4TPo539ILKqS7CsJ8U5xsAweUszdWqVRh58abc8milnuIX2ko=

If the IP is in there, it's the same for all of these.

[rico]

Yes, it's just a md5 IP, so that cracks in under a second with hashcat.

I'm intrigued. Do tell.

[Somnambulist]

Yes, it's just a md5 IP, so that cracks in under a second with hashcat.

I'm intrigued. Do tell.

Using hash cat and two dictionaries, both identical and each containing 1.1 -> 255.255 cracking md5 ipv4 is super fast. You can read a bit more about it here: https://www.phillips321.co.uk/2012/04/04...p-address/

[pragmatic]

I used the ip address hcmask file, but yes it's very quick.

[pragmatic]

Thanks for the samples, Somnambulist. I'm not seeing any obvious patterns, but it's strange though, it seems like every one of them is missing at least one character.

Even the original sample seemed to be a character short, although at the time i assumed it was just dropping the second equals sign. But for these, assuming this really is base64 which it certainly appears to be, it's missing at least one (non-equals) character to be valid base64.

Any chance there's a character getting lost in translation somewhere?