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
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
