Tag Archives: hackers

Russians used non-public exploits to hack governments; Debunking: skill vs. budget

blind-men-and-the-elephant

Organizations being hacked is not always the result of superior adversary, but more often than not (I think the figure is closer to 85% defender mistakes vs. 15% “very skilled) the result of poor defenses. The recent Russian hacking highlights against the White House website (note that GAO rated MOST Federal agencies as failing w/ regards to their information security postures) was noted as skilled, because they used yet known vulnerabilities. This is a generous leap in conclusion.

Their sophistication is not a factor here, but they have budget to buy such vulnerabilities off the open market. These are easily available and a successful attack could be orchestrated with less than $10k. According to public sources, the very expensive vulnerabilities cost around $100k. Easily within the reach of any financed attack group.

As we enter the week of RSA, and likely a slew of discoveries that are released this week let’s be pragmatic on their impacts and the defenders role.

They’ve determined that APT28, a politically-motivated Russian hacking group, used unpatched exploits in Flash Player and Windows in a series of assaults against a “specific foreign government organization” on April 13th. Patches for both flaws are either ready or on the way, but the vulnerabilities reinforce beliefs that APT28 is very skilled — less experienced groups would use off-the-shelf code.

via Russians are using undiscovered exploits to hack governments.

See you at RSA!

James @jdeluccia

Change all your passwords, now.. it is that simple

There is a lot of reason to change passwords and in most business settings passwords are requested to be changed every 90 days. This is usually for the end users and rarely for the system to system accounts. A recent vulnerability creates the possibility that any account that accesses a system on the internet (specifically using HTTPS w/ OpenSSL, but lets not complicate the clarion call here) is exposed and known by someone other than the owner.

By that very condition the password should be changed, and now.

So if you are a person reading this …

  1. Pull up your accounts and begin methodically changing them to a fresh new version (there is a condition here that the site you are updating at has already fixed the vulnerability and has internally followed good practices, but lets presume best scenario here)
  2. Add a note on your calendar 3-4 months from now, to again change the passwords

If you run an technology environment that had OpenSSL installed and was vulnerable, grab a cup of coffee and sandwich, then…

  1. Begin the methodical (perimeter first .. working your way in through layers) and careful task of updating all of the certificates, credentials, and end-user accounts. Also consider end-users too.
  2. Write amazing and clear explanations to the need, value, and importance of this process to your users
  3. Set all users that have accounts accessing your services, to be forced to reset.
  4. Log out (invalidate sessions) all Apps and online cookie sessions (revoke, etc..)
  5. Reissue your private key and SSL certificate
  6. Review and examine your API and third party connections to confirm these are updated, reset, and secured
  7. Add a bit of extra monitoring on the logs for a bit

This is all the result of the Heartbleed.com disclosure, but lets not get technical here .. these are good practices, but now with the probability above 'unlikely', it is a timely habit to re-embrace.

 

Stay safe,

 

James