[Interest] TLS/SSL XML encryption security
roland at logikalsolutions.com
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.
>> 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
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.
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
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
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
56TB - ~9lbs
80TB - 23 lbs
168TB - 48.4 lbs
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
More information about the Interest