[Interest] Interest Digest, Vol 96, Issue 19
roland at logikalsolutions.com
Wed Oct 2 02:47:59 CEST 2019
On 6/13/19, Thiago Macieira wrote:
> There are three factors to security: authentication, authorisation and
> encryption. TLS by itself performs the encryption for you and QSslSocket will
> default to high security, leaving it to OpenSSL to negotiate which cipher to
> use. The only thing I recommend about encryption is to make sure your OpenSSL
> installation does not enable weak ciphers. Or you can change the cipher list
> in your server application too.
> But encryption alone isn't sufficient. Encryption prevents snooping by third
> parties and secures the communication between you and the end point. You need
> authentication to guarantee that the end point is who it says it is. Usually,
> servers authenticate themselves to clients -- that's how you know that
> yourbank.com is your bank, not a phishing scam. Client authentication, like
> Steve says, is rare, but you may want to do that if you need to ensure that
> only trusted clients are allowed to continue. A client certificate may replace
> a password.
Sorry for the delayed response sir, I've been out of circulation for a
bit with medical issues and death of a friend.
Also sorry for mushing 2 together here, but needed to.
There are actually four factors to security. The one you left off is
"don't be stupid with the data." This is the one factor which is 100%
fixable and 99% ignored. I have a short blog post on it here:
but for those who don't like to follow links I will briefly sketch it
here. If you are using XML, JSON or any of the other trendy text based
open standards for data exchange, you've made it easy for the hackers.
They don't have to put any human noodling into determining if they
cracked your transmission or not. It can be fully automated. As soon as
one of the attempts returns something like this
"firstName" : "John"
a tiny bit of code which runs through the result looking for an opening
tag with a matching closing tag or colon delimited quoted strings can
tell a brute force method to stop and notify the hacker of success. If
anyone is interested there are even white papers on how to use CUDA for
AES so adapting the tech for nefarious means shouldn't be that
difficult, especially if the "research code" is also available.
I do have a pretty decent length essay about this in the new book and no
I'm not going to put the entire thing here, just cover the gist of it.
To really secure transmitted data, you cannot use an open standard which
has readily identifiable fields. Companies needing great security are
moving to proprietary record layouts containing binary data. Not a
"classic" record layout with contiguous fields, but a scattered layout
placing single field bytes all over the place. For the "free text"
portions like name and address not only in reverse byte order, but
performing a translate under mask first. Object Oriented languages have
a bit of trouble operating in this world but older 3GLs where one can
have multiple record types/structures mapped to a single buffer (think a
union of packed structures in C) can process this data rather quickly.
When you wish to be particularly evil to packet sniffing hackers it can
even be fun to begin each packet with a standard XML header and a few
meaningless tags followed by your striped binary data then a proper
closing XML tag.
Striping data is a method as old as the punched cards which used to
accompany phone bills in the mail. Using binary does require both ends
play nice with endian and floating point types or that you convert all
of your floating point to a scaled binary integer but that is not the
problem it used to be.
Yes, your transport layer may be breached or simply expose what the
decrypted packet length is, but even after they successfully decrypt the
packet, they have a lot of work in front of them figuring out what the
data actually is. The larger the record the more scattered the bytes can
be. You also aren't limited to a single "record layout" per packet. The
creator and consumer can support thousands of differing record layouts
without anything existing outside of the binary executable.
> mathematically proven to be safe. In all likelihood, there will be issues
> found. If by that you mean that it's not secure, then yes: it's not secure
> because there'll likely be a new vulnerability discovered.
On 9/17/19 5:00 AM, Thiago Macieira wrote:
> I'll agree with Roland that "use SSL, you're safe" is not a factually correct
> statement. A simple debug-mode "ignoreSslErrors()" left in your code kicks the
> door wide open to attackers. SSL is a component of your security architecture,
> but not the only one.
> But I'll also agree with Peppe that SSL/TLS is as secure as we can make it.
> Claiming otherwise, claiming that there are attacks that slice through up-to-
> date and well-maintained installations like a hot knife through butter,
> without offering proof, is beyond disingenuous. It's positively irresponsible.
That's okay Thiago, I've lived with that a long time. Far too large a
portion of the species considers using Google to be "doing research."
The simple fact is that most of the interesting things which happen at
any given DEFCON don't happen at any presentations or in any of the
reserved rooms. That bluetooth thing I mentioned in yesterday's message
was some dudes acting like 8th graders after the Christmas when Mattel
first introduced that 9 volt hand-held football game.
Somewhere I've actually got one of those. Hope I didn't leave a battery
in it. In their day they were the very definition of "cool tech game."
Mostly the group who was doing the bluetooth thing at the time was
having great guffaws over cloning someone's phone and calling their
significant other. A few claims of cloned phones calling the White House
but nothing solid. Some people saw it and made note of it. Looks like
they are still having some bluetooth fun.
The TLS/SSL story relayed to me had nothing to do with any form of
direct breach. They sniffed some packets with one of the many network
sniffing tools which allows packet logging. Once they had some number
they let someone choose one of the files and let the software chew on
it. In less time than it takes to consume a pre-packaged beverage, it
How did they do this? I don't know. I wasn't in the room, but I'm not
surprised. Decryption tools are getting really really good and the bulk
of the people sending data over the Internet are stupid with the data.
Seriously. I'm just being factual.
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE example [<!ENTITY copy "©">]>
How many of you went to one of the above two links and stole/copied one
or both lines to build your XML with? If you took the second example,
just how many even forgot to change the name of the DOCTYPE?
If they targeted something which uses XML documents to communicate, they
don't need to brute force attempt everything, just the first 120 or so
bytes of each packet until they find the one which returns
and they are done.
Maybe they got really lucky with the sniffer and got the handshake
packets as well? If they couldn't manage to pull the shared secret they
would at least know which algorithm was being used. If you know the
algorithm, what part of the input text was required to be and what the
first N characters are of the packet, it's not a robust problem to solve.
Off-the-cuff while enduring ragweed season . . . You don't need to
"crack" the encryption if you target JSON or XML to decrypt the data.
You need a PostgreSQL database (possibly multiple depending on disk
size). One table.
encrypted_value text/varchar unique key, encryption_key_value
text/varchar, encrypted_length int, algorithm int, hit_count int
The hit_count is there because as your database grows and is utilized I
suspect a bell distribution will occur given how computers suck at random.
I did not go looking at the TLS/SSL code to identify the correct
datatype for the encryption key value. The column is what is important
here, not its type.
You can let it grow slow with one machine for each of the algorithms
coded in TLS/SSL or you can create a BOINC project:
There already are a number of "private" numeric projects.
Depending on which method you use you end up with a good sized database
after a few weeks. You don't need everything to start using it and you
need to get the other part of the code working.
Keep in mind that nothing as-of-yet illegal has been done. It's all just
number crunching research at this point.
Ah yes, the second part.
The encrypted_length field is really there so you can perform a count()
of unique values on the column. You need one thread for each unique key
length. (I'm allowing for an encryption algo which generates more
octates than came in.) Each thread gets handed the first 120-225
octates. The thread uses the unique value size for the size of a sliding
window. It slides the window one octate at a time and performs a keyed
hit against the database. If your window bangs into the end of the data,
then you don't have the correct pair. If you get back a cursor with a
row count of one, you have all you need.
If someone assigned this as a contract research project to me using
packets sniffed from a local network, this is how I would solve it. I
come from the big computer world. We don't waste time walking up a hill
when we can drive there.
Such a database could be hosted anywhere on the Internet. If the person
doing this is doing it only with the number of off-lease computers they
can afford, could be a month before you have a large enough database to
begin using. If they are nefarious with a botnet, especially botnets of
these sizes: (smallest on the list had 6 million, largest had 30 million)
Doling out 100 or so keys to each one at a time (like a BOINC project)
that would get you 600,000,000 - 3,000,000,000 within a few hours.
Remember, they are only encrypting "<?xml version=" so 100 keys won't
take long. Might need to send 1000 at a time so they don't spend so much
time waiting for the dispatcher.
Off-the-cuff you would need 2 databases for JSON. One encrypting " : "
and the same thing again without the space between the quotes and colon.
You have a second step with this one too. After finding a match you have
to perform a QString::count() after getting a row back in the cursor.
You need to ensure there is more than one occurrence in the packet to
ensure you have found JSON data.
So yeah, someone wandering around at a DEFCON with a laptop uses some
kind of sniffer to pull packets from something. The people watching
don't ask much about it because they are just packets off the network.
After a puddle of them are in a directory one or more are chosen and
some other software chews on them. Before they finish what they are
drinking, it is done. They could have used one of the many decryption
tools talked about at DEFCON and on the Dark Web, or they could have
been targeting a network entity which communicates using XML documents
to really wow people.
There are several points here:
1) Don't be stupid with the data. Don't transmit XML, JSON or any of the
other popular text formats if any portion of the data could be sensitive
__OR__ any transmission within this communication session could contain
sensitive data. Since you cannot know what is happening before or after
your application, just don't use these formats. They increase your
2) You don't need _all_ possible encrypted values of the starting xml
string to begin having success with such an approach.
3) They (whoever "they" are) don't need to gain entry or side attack if
they can sniff.
list of the historically known exploits in 2018 actually claimed the
ROBOT didn't effect 1.3 then the March 31, 2019 article had to
say...yeah, it does.
Be sure to read up on HEIST while there. When you have the exact length
of the decrypted packet it's a lot easier to weed out the invalid
decryptions from a brute force method via bot-net.
March 31, 2019
Oh, for those who think using Google is "doing research" and that when
it comes to OpenSource security software there will be more people
trying to improve it than trying to exploit for profit weaknesses
they've found, George Clooney has a public service announcement. I'm not
going to post the link here. Just search for
george clooney climate change youtube
P.S. The owner of the Bredolab botnet, according to the article, was
making US $139,000/month leasing out the botnet.
Roland Hughes, President
More information about the Interest