[Interest] Interest Digest, Vol 96, Issue 19

[Roland Hughes]

On 6/13/19,  Thiago Macieira wrote:
> Right.
>
> 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:

http://www.logikalsolutions.com/wordpress/information-technology/you-are-the-security-breach/

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</firstName>

or 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.

https://pdfs.semanticscholar.org/944c/447afff53e13921ac828c24f875000b8acae.pdf

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.

http://www.timidfutures.com/wp-content/uploads/2013/02/Mattel-Football.jpg

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.

https://www.youtube.com/watch?v=Ibia1Bn2Er8

https://www.youtube.com/watch?v=_Z4gYyrKVFM


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 
was done.

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.

https://www.w3schools.com/xml/
<?xml version="1.0" encoding="UTF-8"?>

https://en.wikipedia.org/wiki/Root_element
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE example [<!ENTITY copy "&#xA9;">]>

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

<?xml version=

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:

https://www.google.com/search?client=ubuntu&channel=fs&q=boinc+projects&ie=utf-8&oe=utf-8

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)

https://themerkle.com/top-4-largest-botnets-to-date/

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 
vulnerability exponentially.

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.

https://www.cloudinsidr.com/content/known-attack-vectors-against-tls-implementation-vulnerabilities/

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

https://www.acunetix.com/blog/articles/tls-vulnerabilities-attacks-final-part/



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
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