Heartbleed: A Scrambled Egg with Lots of Ham

CVE-2014-0160The sensational headline news this week was “Heartbleed” security flaw, which was covered by most mainstream and tech sites.  It was an old bug that was accidentally introduced, and just discovered recently1. The report got IT professionals scrambling to fix their systems.

At first glance, the bug is benign enough, with chances of hacking the passwords or SSL keys rather slim. However, like any other hacking issues, if someone is determined (and clever) enough to exploit this bug, they may just get a bunch of useful data. Whether or not they can use the hacked data to steal client information, or use it for a phishing site, it’s unclear. Just the thought of the potential leak scares the daylights out of everyone! It’s also proof that the marketing behind this bug was very effective.

Regardless, the actions need to be taken are as follows:

  1. Check with Qualys SSL Analyzer to determine if your site is vulnerable.
  2. If vulnerable, upgrade OpenSSL to version 1.0.1g, or alternatively recompile OpenSSL without the “heartbeat” option (-DOPENSSL_NO_HEARTBEATS).
  3. Recompile or restart the web server to reload the latest OpenSSL libraries.
  4. Test the site(s) with the Qualys SSL Analyzer again.  Also check if site is functional.
  5. With the new OpenSSL, generate a new SSL key, and re-key a new certificate.  Install the new key/certificate in the web server(s).
  6. Urge the users to change their passwords – which they occasionally have to do, anyway.  This step is tricky considering the PR scare that it’s going to generate when admitting the site is vulnerable.  However, the notification is the responsible thing to do.

When the dust settles, we can look back and use this as an important reminder how fragile the Internet is.  Customers are expected to be cautious of their data being transmitted over the Internet, no matter how secure a company claim they’re being kept.

  1. Introduced in 2011 and found out in February 2014 []

BYOD: Why It Should Be The New Normal

Smartphone UseThere’s been a lot of talk lately about Bringing Your Own Device (BYOD) to work. It’s not a new concept. People love their smartphones, tablets, or laptops. They prefer using a particular brand for personal and work. They bring it to work because it’s convenient to carry just one device, and they can be productive with their own.

Traditionally, companies provide their own “certified” devices to retrieve secured Enterprise data. However, it’s difficult to stop employees from transmitting those data somewhere else, either via E-mail, USB drives, or Cloud Storage, potentially enabling others to see them. A strong privacy policy may be enough deterrent – at least in the beginning. As time goes by, employees will get complacent and too comfortable in taking their data everywhere, not realizing the confidential data may be leaked.

As an IT leader, one can imagine the complexity of supporting multiple devices and worries about zero control over securing protected data. Case in point, the biggest early adopter of BYOD was IBM. They learned valuable (and painful) lessons from it. Employees were not aware of insecure apps, not using secure channels to transmit data, and losing their unprotected/unencrypted devices. These security breaches could potentially cost them, or anyone else for that matter, millions of dollars to repair.

So, why is there growing trend to adopt BYOD? In this tough economic condition, company expenses have to be cut aggressively. The most obvious is to stop allocating budget for productivity machines. Having the cost shifted to the employees, it eliminates the need for company’s machines to be stocked, upgraded, and re-stocked.

Employees have also voiced their concern about the lack of productivity using company issued devices, such as a Blackberry, instead of their favorite iPhone or Android phones. It doesn’t make any sense to have a dedicated, company issued, device just to receive e-mails or phone calls for work, and another for personal use. It certainly becomes challenging to carry two devices, especially when an iPhone, for example, is more than enough to handle all of those tasks and be just as productive.

IT leaders are starting to embrace this BYOD trend because solutions are starting to appear, as the concept become widely accepted. Android and iPhone devices are now equipped with additional security to deter data theft or loss. Both Google and Apple are serious about Enterprise adoption and have updated their OS to be more secure. Now, it’s up to the IT leaders to trickle down the information to users on how to secure their devices, according to the companies’ need.  Instead of preventing employees to bring their own devices, educate them on how to secure the content of their own devices. As Ronald Reagan would say: “Trust, but verify.” There is a level of trust on both sides, but both must remain vigilant.

It is time to stop believing the myths of bringing-your-own-device to work. BYOD is happening, whether or not IT is ready. It is the “new normal”.

Samba and Windows 7

Windows 7 has upgraded security.  This will effectively cause trouble in making connections to legacy apps (ie. Windows XP supported).  One of them is Samba on Unix.

Fortunately, there’s a solution to this:

  1. Open Control Panel.
  2. Choose Administrative Tools.
  3. Click Local Security Policy.
  4. Under Local Policies and Security Options:
    1. Change Network security: LAN Manager Authentication Level to “Send LM & NTLM responses”
    2. Change Minimum Session Security for NTLM SSP to disable “Require 128-bit encryption” into “No Minimum Security”.

Illustrations below:

Operating System and Web Apps Hacking

A lot can be learned from a hacker (albeit a convicted hacker).  Here are some of his thoughts on OS and web application security:

Securing a system:

I keep my services to a minimum, and I keep them updated. On my Linux box I use custom kernel hardening patches to make memory corruption bugs pretty hard to exploit. OpenSSH is firewalled and only accepts a connection from your ip if you visit a custom port-knocking page on my webserver. Basically the only service listening is apache, without PHP.

On my desktop and laptop I don’t have any services listening at all.

Public computers:

… I try to avoid public computers. If I really have to log in from an untrusted terminal I use otp authentication.

Modern website’s security:

Not very secure. SQL-injections are everywhere.

Discovering SQL injections vulnerabilities:

I don’t know of any specific papers, SQL injection is such a simple concept so you can pick it up in a matter of hours. The best method of finding them manually is to simply insert ‘ and ” union select(..” at random in parameters and see if things break.

Local source disclosure vulnerabilities:

Yes, sure. You can do a lot with config.php + phpMyAdmin.

What to do in a hacked machine:

1) Find a custom admin interface.

2) Get read access to a db from an SQL-injection.

3) Find tables corresponding to the custom admin interface.

4) Crack the admin password.

5) Log in and upload a new picture, containing PHP.

6) Exploit buggy custom cron-scripts that delete directories in /tmp once a day.

7) Wait for exploit to trigger..

8 ) Infect a binary on an NFS-share.

9) Wait for someone to use the binary..

10) Enjoy access to the main servers.

Something like that 😉

Operating System:

Personally I use Linux. I don’t consider Linux especially secure, just look at the number of local kernel root vulns found in the last year. I do however know that this is because there are so many people auditing Linux every day. I’d rather use an OS that has a few serious public vulns each year than one where the vulns are still there but aren’t found.

If you make a new operating system, how long it takes for someone to exploit vulnerabilities depend on how secure your code is and how much someone would want to exploit it. A local root vulnerability in QNX isn’t as “popular” as one in Linux, so more people are looking at Linux.

Tools used:

Exploits, network scanners, rootkits, google (perhaps the best network scanner).

And a voice recorder. They are essential when hacking banks.

More security holes:

Yes, I’ve written exploits for most types of bugs. Buffer overflows, format strings, int overflows. I have discovered some holes myself. Nowadays the most popular thing to audit is webapps. The age of remote root holes in popular ftpds is gone.

Government computers:

Personally I think that there are government agencies in the US, China, Russia etc. that have already backdoored each other to hell and back.

Stopping a hacker from coming in:

In short, if you have a network that is connected to the internet and someone wants to get in, they will eventually get in. If you are running the latest versions of all possible software you might think you are safe. But what if someone comes along with a 0day, or someone hacks the home computer of one of your administrators?

Tracing a hacker:

I got too comfortable with my setup and thought I was untraceable. It turns out that, given enough incentive, some people will analyze router logs from all over the world for months until they find you.

PHP:

Make sure whatever PHP software you are using is always up to date. PHP stuff has a tendency to be written very poorly. Install some custom hardening patches like Grsec.

… I’m a big fan of Python. It’s much easier to write insecure software in PHP than in Python.

Security Industry:

I think has become less about knowledge and innovation and more about hype. Extreme hype. Everyone wants to make money off their name. Bugs become a commodity that is sold to companies that charge subscription fees for advance notice, etc..

Personally I am a blackhat. I loathe the cesspool of inflated egos that is the computer security industry. Therefore, I would never ever advise them to become “whitehats”. As for a more rewarding way to use their skill and curiosity, I can’t think of a good answer. Hacking into computers is simply the most rewarding experience I have ever had. I don’t see it as a problem if you are hacking big companies or governments for the sake of adventure, you are not out to hurt people.

Just make sure not to make money from your hacking, be it selling out to the security industry or selling botnet-stuff to russians. Both will destroy your passion.

Sysadmins:

I understand that ultimately some admin will have to take care of cleaning up after the breach, but it’s a part of their job. If one of the main reasons not to hack is that some administrator, whose job it is to maintain the servers, has to do his job.. I just don’t see that as a very compelling reason not to hack.

Hacking:

The incentive was the thrill of breaking into something that could sometimes have taken over a month of preparation. Looking at information that you weren’t supposed to be looking at. I suppose it’s the same feeling you get when solving any complex problem. It’s better than sex. I mostly worked alone, and I was not hired for anything.

Operating System hacking preference:

I almost exclusively hacked *NIX machines. Mostly Linux and Solaris, but also a lot of IRIX/HP-(S)UX/AIX. I would however definitely say that it is easier to hack a Windows PC, given their history of remote “root” vulnerabilities in default services.

OpenBSD is not secure at all. At least they changed the text on their front page to “Only two remote holes in the default install, in a heck of a long time!”. There’s a reason Theo DeRaadt has been hacked a number of times, his ego is enormously inflated. OpenBSD is 10 years behind grsec for example.

The most important part is the anti-exploitation techniques like ASLR, PIE, etc. What I meant to say was that GRsec has always been in the forefront when it comes to those. GRSec, RBAC and SELinux also have MAC capabilities but these are extremely rarely used correctly and to their full extent, since they are so hard to configure right.

Got Hacked?

Green Lock (via Flickr)The talk around Twitter right now is the phishing scam via Direct Message, as reported by many including Read Write Web, Mashable, and Chris Pirillo.  The victims include Twitter accounts for Barack Obama, Fox News, Britney Spears, and Rick Sanchez of CNN.   Getting their Twitter account hacked is a potential public relations nightmare.  The bait was a simple message to direct recipients to a fake Twitter login page, and enters their Twitter passwords.  Unsuspecting users went ahead and entered their information.  A similar trick was done in e-mail for the longest time using pages that looked like E-Bay, PayPal, or a banking site.

I get similar complaints with the websites that I maintain.  What can server administrators do to figure out who’s behind these attacks?   Here are the steps I take:

  1. Ask the business or customer when the suspecting hack happened.  Find out the exact date and time, if possible.
  2. Comb through the web server logs to find the IP addresses of the hackers using the date and time range reported by user.  For example, in Apache HTTPD, the file is normally called “access_log”.
  3. Most hackers try multiple times, in quick successions.   In this case, running through web logs through an analyzer like Webalizer or Awstats will reveal the IP address with the most hits, within a specified time range.
  4. Find out who the IP belongs to using tools like dig or nslookup.
  5. Report the offending IP address to the Internet Service Provider (ISP) as indicated by the lookup tool.  It can be done via email to postmaster@<isp.name> or abuse@<isp.name>.
  6. Depending on the severity, a fax or a phone call to the ISP may be required.  This is usually done when the hacking continues and there’s no indication of the ISP intervention to stop it.
  7. Start using the web server IP filtering features to blacklist the offending IPs.  For example, in Apache it can be done via Deny directive for doc-root in httpd.conf or .htaccess file.
  8. For known hackers’ IP addresses, make it permanent by blacklisting them in the firewall or router level.

Users do get complacent with their username/password.  They type (or even share!) passwords to others without thinking twice.  With more and more sites requiring a login, it’s easy to forget about checking the legitimacy of the page presented on the web browser.  Proactively, the web applications need to be modified to prevent login hacking such as:

  • Using Secure Socket Layer (SSL)   With SSL, most phishing sites will not bother with it because of the cost involved.  If logins are not done securely, users need to be extra careful.
  • Using OpenID, the open standards user login.  A site needs to be registered with OpenID to be able to use this service.  This removes the guesswork if the site is legitimate or not.

Hopefully the word is out for both users and web developers, to do whatever is required to secure login passwords.

Image Credit: Ashenzil