[Interest] TLS/SSL XML encryption security

Tue Oct 8 18:26:19 CEST 2019

On 10/8/19 5:00 AM, Thiago Macieira wrote:
> On Monday, 7 October 2019 15:43:21 PDT Roland Hughes wrote:
>> No. This technique is cracking without cracking. You are looking for a
>> fingerprint. That fingerprint is the opening string for an xml document
>> which must be there per the standard. For JSON it is the quote and colon
>> stuff mentioned earlier. You take however many bytes from the logged
>> packet as the key size the current thread is processing and perform a
>> keyed hit against the database. If found, great! If not, shuffle down
>> one byte and try again. Repeat until you've exceeded the attempt count
>> you are willing to make or found a match. When you find a match you try
>> key or key+salt combination on the entire thing. Pass the output to
>> something which checks for seemingly valid XML/JSON then either declare
>> victory or defeat.
> That DOES work with keys produced by OpenSSL that was affected by the Debian
> bug you described. That's because the bug caused the problem space to be
> extremely restricted. You said 32768 (2^15) possibilities.
Unless the key range 2^15 has been physically blocked from the 
generation algorithm, the database created for that still works ~ 100% 
of the time when the random key falls in that range. The percentage 
would depend on how many Salts were used for generation or them having 
created the unicorn, a perfectly functioning desalinization routine.
>
> A non-broken random generator will produce 2^128  possibilities in 128 bits.
> You CANNOT compare fast enough

Does not matter because has nothing to do with how this works. Not the 
best, not the worst, just a set it and forget it automated kind of 
thing. It's taking roughly 8 bytes out of the packet and doing a keyed 
hit on the database. If found great! If not, it slides the window down 
one byte and performs a new 8 byte keyed hit.

This is *NOT* a real time attack. Everything is independent. The sniffer 
wakes up once per day, checks how much space is left in one or more 
directories, if there is room for more packets, it reaches out and 
sniffs a few more. Either way, it goes back to sleep for a day.

>
>> These attacks aren't designed for 100% capture/penetration. The workers
>> are continually adding new rows to the database table(s). The sniffed
>> packets which were not successfully decrypted can basically be stored
>> until you decrypt them or your drives fail or that you decide any
>> packets more than N-weeks old will be purged.
> You seem to be arguing for brute-force attacks until one gets lucky. That is
> possible. But the chances of being lucky in finding a key are probably worse
> than winning $1 billion in the lottery. Much worse.
Not really, but I haven't had time to write this stuff because people 
keep interrupting me with direct mails. There are several things I want 
to deep dive on first. One of which is poking at some desalinization 
routines. The other, which really shouldn't be because such a thing 
would be taking us back to the 1970s is the few things I ran made it 
seem like the Salt had a ToD sensitivity.
>
> So it can happen. But the chance that it does happen and that the captured
> packet contains critical information is infinitesimal.
When you are targeting a DNS address which has the sole purpose of 
providing CC authorization requests and responding to them, 100% of the 
packets contain critical information. Even the denials are important 
because you want to store that information in a different database. If 
you ever compromise any of those cards, sell them on the Dark Web cheap 
because they are unreliable.
>> The success rate of such an attack improves over time because the
>> database gets larger by the hour. Rate of growth depends on how many
>> machines are feeding it. Really insidious outfits would sniff a little
>> from a bunch of CC or mortgage or whatever processing services,
>> spreading out the damage so standard track back techniques wouldn't
>> work. The only thing the victims would have in common is that they used
>> a credit card or applied for a mortgage but they aren't all from the
>> same place.
> Sure, it improves, but probably slowly. This procedure is limited by computing
> power, storage and the operating costs. Breaking encryption by brute-force
> like you're suggesting is unlikely to produce a profit: it'll cost more than
> the gain once cracked.
>
> Crackers don't attack the strongest part of the TLS model, which is the
> encryption. They attack the people and the side-channels.
Kids do.
>> If correct that means they (the nefarious people) could have started
>> their botnets, or just local machines, building such a database by some
>> time in 2011 if they were interested. That's 8+ years. They don't_need_
>> 100% coverage.
> No, they don't need 100% coverage. But they need coverage such that the
> probability of matching is sufficient that it'll pay the operating costs. In 8
> years, assuming 1 billion combinations generated every second, we're talking
> about 242 quadrillion combinations generated. Assuming 64 bits per entry and
> no overhead, that's 2exabytes to store. Current cost of Amazon S3 Infrequent
> Access storage is 1¢/GB, so it would cost $20M per month.
>
>
> Calculating assuming an infinite Moore's Law is left as an exercise for the
> reader.

Nah, this isn't a lease storage space type of attack. If they are well 
funded and willing to risk their own computer room with a rack they will 
get one or more of these.

https://www.bhphotovideo.com/c/product/981583-REG/promise_technology_j930sdqs4_vtrak_jx30_ultra_dense.html

But it will take them some time to get there. Not so much the money 
thing as once you get a rack and space with that much power you are no 
longer nimble or under the radar.

The lone hacker who doesn't want to spend all of their time trying to 
direct attack things and risk getting caught by not knowing enough won't 
do that.

They will start out with an HP or other SFF desktop and a 6+TB drive. 
Something which will fit into a large backpack easily. Write their 
software. Spend $20 for the cheapest domain name which comes with around 
4Gig of storage for a year and MySQL preloaded. Toss up a few Web pages 
and one page/service to collect data from their botnet. Oh yeah, for the 
botnet they will buy one or more cheap botnet email attachments and use 
a Dark Web spamming service (or just send them to people they know). The 
bot will periodically reach out to the Web service to request another 
100 combinations to generate, generate the results and send them back. 
When there is 1Gig or so in the database on the Hosting site Geek will 
transfer it to their local machine, keeping disk usage on the host 
service low. If anyone looks at the site it will look like one of 
thousands of research projects created by college kids. They might not 
even bother with a botnet just ask their friends to join their BOINC 
like project.

Eventually they will start worrying about the life of the one internal 
drive all of this is being stored on. They will buy a USB 3.x external 
RAID device. Something small like this 6TB roughly 9lbs device. (I just 
went to this one site because they had a bunch of these things and I 
wanted to see just how much RAID storage one could obtain in a 
"portable" container.)

https://www.bhphotovideo.com/c/product/1496989-REG/oyen_digital_3r2_2c_6tb_mobius_usb_c_raid_2_bay.html

56TB - ~9lbs
https://www.bhphotovideo.com/c/product/1466481-REG/owc_other_world_computing_owctb2sre56_0s_56tb_thunderbay_4_raid.html/specs

80TB - 23 lbs
https://www.bhphotovideo.com/c/product/1412298-REG/rocstor_gp3511_01_rocpro_t38_80tb_7200.html/specs

168TB - 48.4 lbs
https://www.bhphotovideo.com/c/product/1452318-REG/lacie_stfj168000400_168tb_12big_thunderbolt_3.html

The bigger devices would require they have some level of success at 
cracking CC xml packets. Otherwise it is just a research project run 
amock. 50lbs would be the far edge of easily portable. A pair of the 
56TB would keep the weight to < 20lbs plus the SFF desktop.

In order to plan against attack one has to profile just who the attacker 
is and what motivates them. For the large "corporate" organizations, you 
are correct. They are looking to score a billion dollars per week and 
aren't interested in a slow walk. The patient individuals who aren't 
looking to "get rich quick" are much more difficult to defend against. 
The really stupid ones get caught right away. The really smart ones take 
a slow path like this.

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog