Security Analyst – Jeff Soehner CISSP, GXPN,GPYC,GMOB,GCIH

In what I consider to be a concise delivery of how Cybersecurity can affect all of us, this guy has gone in front of the Committee on Public Safety and National Security to tell our politicians why Security is important and what is at stake!

I have known Thomas Davies for several years and consider him well versed in Cybersecurity. He understands how the bad guys continue to penetrate our computers despite the best methods of network defence and has taken the time to share his perspective with our government.

I included this session from April 1 of this year and have snipped a few minutes of what was an hour and a half where many of our Canadian brethren helped hit home the message that ‘Cybersecurity cannot do it alone’. Gone are the days where the masked man on the white horse can swoop in and save the day because there aren’t enough masked men (and women) in our industry, anywhere.

We built a network of interconnected endpoints using a communication method that just wasn’t designed to be secure. We then built applications on top of those networks that were also not designed to be secure. Netscape came along and created a way to provide some security and here we are several decades later. (Not blaming anyone here but this is what we did and now we have to live with the consequences) 😎

My hope is that our government and other countries like ours, will come to understand that without the resources required to ‘try and keep the ship from taking on water’ our electronic commerce will be in jeopardy. It is only a matter of time before a major outage could occur as a result of a major cyber incident.

I am not sure any type of legislation can help us solve this problem in the near future but it might be time for our government to get involved before it’s too late.

Kudos to you Thomas Davies for being part of the solution. I am proud to call you a friend! (we are still friends right?)

I was reading an article on Twitter about heap based vulnerabilities when I came across this descriptive list of explanations and their causes.

Many of these show up as browser based flaws and now hit home why sabdboxing is very important for browser sessions.

This list is a good reference for developers and security professionals and can be useful when searching for bugs.

Whenever I travel and have an opportunity to speak with people from around the world I realize that most of us all have similar issues…

Imagine how lucky I was to find Elvis, alive and well in Vegas during my trip last August.

I am planning to attend Blackhat again this year and I hope he is really still with us 🤔.

If you are planning to be in Vegas the first week in August this year, reach out to me and if we are all very lucky, we might get a chance to see him again.

In this short video article, watch how someone can take a few pieces of your personal data and ruin part of your life!

Trust no one and be careful what you share and with whom.

In this article, we learn about how HSBC lost 14k personal records and they want everyone to know, they have not seen any fraud yet?

With your personal data flying around like this, are you really just worried about one service provider?

https://www.cshub.com/attacks/articles/incident-of-the-week-hsbc-bank-alerts-us-customers-of-data-breach

I have been busy at a new job lately and have not had any time to contribute. I found myself so busy in fact that I had purchased some hardware for a new hash killer and did not even open it for several months. I thought this was as good a time as any to create a writeup on how to make your own hash crack computer.

For anyone who was late to the party – Bitcoin mining could be done by creating a computer similar to the one used below but the cost associated with mining your own Bitcoin has gone up making it cost prohibitive. Here is a great way to put those computers to work for you as a security professional / bad guy by cracking passwords.

Using four graphics cards that can be purchased for approx. 400.00 each, any average hacker could build him/herself a password cracking computer that could brute force your passwords.

Firstly, I used a MSI Z170A Motherboard with four PCI-E slots (first one is x8 and the other 3 run x4). This is fine because the real power comes from the GPU on the graphics cards and passes back to the bus at normal speeds. Next we add a i3 (6100) and some Ram (4x4G). We put it in a nice case with 5 x 120mm fans to circulate the heat (the GPUs will create a lot of heat and can shutdown if you don’t remove the heat from the area). Finally we need a power supply to power all four of the GPUs so I purchased a 1300w EVGA all for a total of approx. 3,000.00 (YMMV).

Approaching speeds of almost 60 billion guesses per second, any mortal could destroy a 9 character Windows password that used ANY combination of upper, lower, number or special characters in about an hour.

It’s as easy as using a free, opensource operating system like Ubuntu and loading some additional software to create your own computer that you *could* use to mine Bitcoin but you could probably make more money cracking hashes for profit!

Every year or so I try to flex my muscles by attempting to obtain another professional certification and 2018 was hardly different. This was the year that really tested my ability to focus and thank god that is now behind me.

I decided to attempt to become more adept at Python coding (and development in general) having learned just enough to understand that I really don’t fully understand coding. Sure I can understand some constructs like looping, etc. but I never really had the knack for it. After 20+ years in this business I decided I could not improve my skills without learning a bit more about coding.

After, what seemed like a few months and as we were full into Spring, I received confirmation of my company’s intention to fund this years choice of my training curricula ‘Automating Information Security with Python’. It couldn’t have come at a worse time, I just received a promotion and had a large task ahead of me, was approved to visit Black Hat and take a short course in August and had several home improvement projects planned and paid for that needed to begin. If I was going to do this it would take a lot of my free time to avoid failing miserably.

I spent a lot of time, reviewing my course material, asking colleagues and with trial and error, I am happy to report that I have just passed my exam!

For those of you who are on a quest for self-improvement, have wonderful partners who are happy to take a back seat to the endless sacrifice you will surely need to accomplish your goals, I say to you – tell them ‘Thank You!’ because behind every great achievement like this sits a wonderful significant other that has the faith to cheer you on to success.

There has been a lot of science that goes into making the web a safe place to do commerce with your desktop computer thanks to Netscape when they created Secure Socket Layers (SSL – 1994). In 2007 we entered the world of the Smartphone thanks in part to Apple (we should leave ‘Simon – 1992’ out of this discussion). It wasn’t until 2015 when the IETF released its vision for sessionless tokens that we found another way to manage a session but is this really more secure?

Current technology utilizes cookies that manage the ‘state’ of your connection in order to prevent you from having to login every time you press a button (imagine how painful that would have been?). We have created many controls that help protect cookies curing transmission and at rest but it still requires users to login to obtain a valid session cookie every time. Mobile users would not be happy so we needed a better solution.

Browser -----------(send login request) ---------------> Server
        < -----------(send cookie) -------------------- (create session)
         ----------------(sends authentication) --------> (validate)
        <-------------------(send response) -----------

A JSON Web token is similar to a session cookie and in order to protect them, we decided to create three types of security with it. First option is no security at all (null) and there is nothing secure about that right? These were created to manage other types of data exchange where other security controls were used.

The second type can use a signature to be sure that it cannot be modified. (There is also a third type that uses public key encryption and is preferred but can add significant overhead to the developer and is not widely adopted yet). Lets focus on the second type.

Browser -----------(send login request) ---------------> Server
(first use) <---------(send JWT) -------------------- (create JWT)
(if exist) -------------(sends authentication) -------> (validate sig)
        <-------------------(send response) -----------  (valid user)

Ensuring the integrity of the message can be done by signing the JWT with a message authentication hash which can be created by adding up all the data and hashing it with a secret passphrase. If the developer does not use a strong passphrase and we can guess it, an attacker (that’s me!) can modify the message. Cracking that hash and determining the secret that was used is a lot like guessing what password you use to login. We can use the same method we use to crack your password to determine what secret was used to create the hash for your signature!

Cracking JWT using hashcat with 4 GPU

For a mere 3,000 dollars, I built a computer that can guess the secret that was used to create the hash at speeds of 250 million guesses per second. If the developer does not choose a good long password, they cannot expect to have a high level of trust that users are, who they think they are, when they login.

Now, because the token is transmitted to the client and then accepted whenever the connection is made, the server has no way of knowing that I am not you (after I capture your token or after I compromise your device and steal the token). Using tokens that live on the (untrusted) client is far riskier that using cookies that are stored on your (supposedly secure) server.

Don’t get me wrong, I think the advantages of tokens over cookies helps offset the risk but my lesson here is that we must ensure the integrity of our security controls when it comes to using JWT. They solve many problems that traditional session management has including;

• cookies can be disabled (such as 3rd party cookies across domains)
• cookies are per device whereas tokens can work between your desktop and your mobile device to create a seamless experience
• memory issues server side for cookies but tokens reside on the client

With great power comes great responsibility so we must take additional steps when deciding to use tokens in place of cookies. Our infrastructure will be slow to provide protection for these as they did for cookies so the responsibility is on the app developer to use strong passphrases and to implement encryption when using sensitive claims with the tokens.

In short, if you read the RFC for JWT, you will find the following statement;

The contents of a JWT cannot be relied upon in a trust decision unless
its contents have been cryptographically secured and bound to the
context necessary for the trust decision.  In particular, the key(s)
used to sign and/or encrypt the JWT will typically need to verifiably
be under the control of the party identified as the issuer of the JWT.

This means that your developers must be following best practices when choosing their pass phrases. A good rule of thumb is to use one bit of entropy for every byte data you wish to protect. If you are using 256 bytes of a payload you should consider making your pass phrase, 32 bytes long. You should also carefully consider ‘pass phrase/key’ rotation and token expiry policies. Session hijacking is one of the most important tools in the hackers toolbox and is easily executed if session management is not done right!

Its here! – The new world of Transport Layer Security (read more)

July 1 2018 marks the birth of a more secure world for users of credit cards. Almost every vendor, merchant and client of the Payment Card Industry (PCI) should now be using TLS 1.2 without RSA encryption in order to avoid attacks being leverage against your implementations of secure sockets.

If you have migrated away from DHE/3DES/CBC/RSA/TLS1-1.1 in favour of TLS 1.2 using Elliptic curve cryptography you might already be missing attacks like DROWN, BEAST, Lucky Thirteen, Logjam and even the stealthy ROBOT but you can rest assured that you have a secure method of connecting. Our next milestone will be the adoption of TLS 1.3 which can prevent attackers all together.

If you are a large and slow moving enterprise, you might have decided to utilize some customized patches from the likes of F5, Fortinet. You may also be hoping that content delivery networks like CloudFlare or Akamai are going help thwart these attacks. Managing these customized patches can contribute to security burnout or worse, you could be vulnerable to one or more of these attacks.

As we get ready for the second half of 2018, cvedetails already shows us with almost 60% of last years total amount and we have surpassed any other year in the past 15 years of reporting. Lets end this year right by removing bad cipher suites in all of our web services.