Understanding The Ransomware Attacks Of 2017

What Happened?

In 2017, we saw two large scale Ransomware attacks. The first began on May 12th, and was caused by a malware called “WannaCry”. The WannaCry attack affected over 230,000 computers in about 150 countries, including the National Health Service of the UK, forcing it to operate in a state of emergency. Just over one month later, on June 27th, another large scale attack occurred, with around 80% of affected machines in Ukraine. This attack is being called the “NotPetya” attack because it used a heavily modified version of ransomware from the Petya family of malware. It is believed to have originated from a compromised update of a Ukrainian tax accounting package called “MeDoc”. About 90% of firms in Ukraine use MeDoc, allowing the malware embedded in the update to travel quickly. Most notably affected was the radiation monitoring system at Ukraine's Chernobyl Nuclear Power Plant, causing to go offline. It also affected several Ukrainian ministries, banks, metro systems and state-owned enterprises. 

What Is Ransomware And How Does It Work?

Ransomware is a type of malware that works by infecting a Windows computer and encrypting the hard drive’s file system, making it impossible for the operating system to start up. In this state, the only thing the computer can do is prompt the user to pay a ransom, usually in an untraceable  cryptocurrency such as Bitcoin. Once the ransom is paid, the attackers promise to decrypt the file system, returning the machine to a usable state. In the case of the WannaCry attack, users were advised not to pay the ransom of $300. Most who tried to pay were unable to when the Bitcoin wallet, setup for receiving the ransoms, was shut down. Luckily a sort of “kill switch” was built into the virus which slowed the spread.  

In the case of NotPetya, instead of only encrypting data on the computer, important computer files were completely overwritten. The overwritten files could not be restored with decryption. This has lead experts to believe that the attack was only meant to look like a ransomware attack with the real intentions being to cause damage, not make a profit. Evidence suggests the attackers responsible for NotPetya compromised MeDoc’s servers more than a month before the attack leaving the server susceptible to additional attacks. NotPetya does not appear to have a “kill switch”.

How Was It Able To Infect So Many Computers?

For WannaCry, Petya, and it’s modified version NotPetya, machines running the Microsoft Windows operating system were susceptible due to something called the EternalBlue exploit. The exploit takes advantage of a vulnerability in how Microsoft implements the SMB protocol (Windows network and file sharing protocol). On March 14th, 2017, Microsoft released a security announcement about the vulnerability and patches that were available for all supported versions of windows, nearly two months prior to the first attack. Many users had not installed the patches, leaving their PCs susceptible to the WannaCry. Microsoft also released emergency patches during the attack for some of their unsupported operating systems including Windows 7, Windows 8, Windows xp and Windows server 2003. The Verge stated that nearly all victims of WannaCry were running Windows 7. 

According to security expert Lesley Carhart, "Every method of exploitation that the attack used to spread, was preventable by well-documented means," claiming the damage done in the attack could have been avoided with the available security patches. As more users and organizations applied security patches, and with the discovery of the “kill switch” the WannaCry attack slowed and had nearly been halted four days after the start of the attack. For the NotPetya attack, Ukraine announced that the attack was stopped only one day after it started. MeDoc’s compromised servers were seized in efforts to ensure no other attack would originate from them. 

In order to keep your own machine safe from similar attacks, it is important to stay informed and up to date on cyber security news and events. It’s recommended to always apply any security updates as soon as they become available, and to use a quality security system. 

What's behind SSL and how does it keep me secure?

You’ve probably heard of SSL before, but might not have actually known what it was. Well, if you’ve ever used the Internet (and we're assuming you're doing that right now), you’ve already benefited from SSL.
 
So what is it? It stands for “Secure Sockets Layer”, and it's a protocol that creates an encrypted connection between a client and a server, Google Chrome and Facebook for example. Ultimately, by protecting and encrypting connections, users benefit from greater security.

Am I Using SSL?    

If you use Google Chrome, have you ever noticed that green padlock that shows up when you type in a URL? For example, if you head over to Google.com, you’ll immediate notice the green padlock followed by “https” in the address bar. Both of these signs indicate that the server is using SSL for connections and is therefore most likely a trustworthy site. As we will learn later, an SSL certificate does not a secure website make, but the Certificate Authority who vouches for that certificate.
 
When you log into your bank account, your login credentials are passed over the internet as an encrypted string. For example, if your password is “Password” (which it shouldn’t be), it will be encrypted with the bank’s public key; to anyone listening, your password may look like “%17(a0L” which is indecipherable to anyone except the bank server, only after decrypting it with a private key. 

SSL Mechanisms

In order to establish SSL connections, there are a few players involved, with the most significant player being the Certificate Authority (or CA). The CA is a trusted third party entity that can vouch for the identity of a specific website by issuing and signing a “Certificate” which contains information about the website and server, but more importantly, public and private keys; these keys are involved in protecting the data passed to and from the server. The public key is usually available to anyone, while the private key is known only to the server. The former is responsible for only encrypting messages, while the latter is responsible for only decrypting those messages. This is also known as “asymmetric cryptography” because there are different keys for encrypting and decrypting. 
 
Here is a well-known example: Alice wants to send an encrypted message to Robert. She obtains his public key, encrypts the message and then sends it out. Robert will receive the encrypted message and will decrypt it using his private key. Now the CA is important because they validate the server’s keys, thus establishing the server’s trustworthiness. Imagine the CA is your best friend: if your best friend introduced you to someone new at a networking party, you would trust that newcomer because you trust your best friend – that trust is what SSL is built on. 
 
Web browsers (Chrome, Firefox, etc.) have a built-in list of trusted CAs called the “Trusted Root CA”. Only certificates signed by one of these trusted CA’s will be accepted. If the browser encounters a certificate that is not associated with a trusted CA (such as Comodo, Symantec, DigiCert), the browser will present a warning to users, if not completely blocking them from connecting. There are ways to circumvent this security measure, but it is highly discouraged, unless you have expert knowledge navigating the vast space of the Internet.
 
Now that you know the basic components of SSL, let’s talk about how SSL is established. The “SSL Handshake” is a series of interactions between the client / browser and the server: 
 
DigiCert, one of the most well-known CA’s, has an informative diagram depicting the SSL Handshake.

Step 1. The browser connects to a SSL secured website (HTTPS://example.com)
Step 2. The server sends its certificate, which includes its public key
Step 3. The browser checks if the CA is a trusted CA in the Trusted Root CA store. If it is an accepted CA, the browser encrypts a symmetric session key* using the server’s public key, and then sends it to the server
Step 4. The server decrypts the browser’s key and sends a notification that is encrypted with the session key back to the client.
Step 5. Communication is now encrypted using the symmetric session key

Convinced Yet?

SSL allows sensitive data like credit card information, social security numbers, or passwords to be sent securely and confidently. Remember, the CA is like that best friend who you trust, so if your browser trusts a CA, the browser will be willing to shake hands with whoever the CA trusts. Next time you wander the Internet and worry about your security, take a peek at the URL, check for the padlock or HTTPS. Here’s a worthwhile motto to teach new Net surfers: “If you want to avoid a security mess, always go with HTTPS”. 
 

*“Symmetric Cryptography” involves using one key to both decrypt and encrypt messages; this is essentially insecure if that key is made public, but it can be very secure if it is only known to the server and client.
 

 

Citations

[1] https://www.digicert.com/ssl.htm
[2] https://www.instantssl.com/ssl.html

Privilege - Less is More

In The Battle Between Security And Convenience, Security Always Wins

“Least Privilege” is a guiding security principle of systems and solutions. While there are different ways to word it precisely, the idea is the same:

"Do not allow or release any more than absolutely necessary."

It’s a simple principle, but without keeping careful watch, you might find convenience popping up as a good reason to not worry about it.

The Why

Security

Security is at the heart of Least Privilege - never leave a solution with a gap that could be exploited by someone with malicious intent. Consider application service accounts: Applications use them to connect to resources as part of normal operations. Since you can never know which accounts might be compromised beforehand, you need to treat them all as though they could be. You mitigate risk by granting a given service account only with the permissions it needs to function. An account like this should never use a super-user account by root access - this is the worst type of access an attacker could have.

This is also true of end user interactions and APIs. For example:

• A login screen should not inform the user if the entered username is invalid

• A password reset endpoint does not need to reveal if the user entered an already-registered email

• A proxy should not unnecessarily reveal hostnames of back-end servers.

• URLs and cookie names should not noticeably reference the applications to which they belong.

Each of these endpoints would provide information to a potential attacker, helping them to identify the product (and perhaps a vulnerability) or lend credence to a phishing attempt. For some of these situations, maybe the business wants to make it easier for the end-user. For others, maybe it is a deadline, a knowledge gap or a product limitation that provides an opening. You don’t want that risk in your system, and if you phrase it to the business in the right way, neither would they.

Development

Granting only Least Privilege is not just for production - good security practices during development turn into good practices in subsequent environments. Start by granting only the privileges you need and, if is not enough, add to it as little as possible. This will ease migration to your new environments, as not only will you know what your application needs, you know how to make it happen. You will not be hampered later by difficult-to-diagnose errors - possibly caused by using a super-user account in Development, but getting a read-only account in Stage.

Damage to your systems may always not be malicious. An inappropriately scoped account could ruin a system during development or migration because of a code error. A script to clear out a directory might speed up development; however, if left in by accident, could have devastating effects on Production. Sticking to Least Privilege could save a system that may take significant time to rebuild if something goes awry.

The Take-Away

Cutting corners is convenient and there will always be a deadline to meet or a case where it “just isn’t worth it.” Good practices in production come from practicing security earlier on. Do not release unneeded information. Do not allow unneeded permissions. It could mean the difference between a secure system and one with the door blown wide open.

---

 PROFESSIONAL SERVICES - SENIOR ARCHITECT

MFA: The New Security Standard

As The Techniques Of Cybercriminals Advance, So Should Your Security.

Multi-factor Authentication (MFA) is a security solution designed to combat the ever growing threat of cybercriminals, providing a second authentication layer to the standard username and password authentication. MFA can have many forms, typically falling into two categories: Device Security and Security Tokens. MFA Device Security uses a device, such as a fingerprint reader, or requires a specific machine used in order to authenticate. In contrast, MFA Security Tokens require users to enter a secret token, known as a random one-time password (OTP), sent to them via text message or email in order to authenticate. Many online banks are already using MFA Security Tokens as a security solution. The benefits of using one form over another are usually quite minor. 

As the threat to our online assets grows, more and more organizations are implementing MFA as an additional layer of security to protect customers’ information online. Cybercriminals such as terrorist organizations, independent criminal actors, even nation-states, all seek to exploit technological vulnerabilities to gain access to our sensitive data. Financial institutions and financial online services are a major target for these cybercriminals. 

Cybercriminals can cause substantial financial losses to individuals they steal from. On September 13, 2016, New York announced the first-in-the-nation comprehensive cybersecurity regulations which mandate minimum security standards for thousands of institutions. MFA is one of these required standards. In addition to almost all major banks, technology organizations, such as Google and Facebook, are also currently utilizing MFA. With new laws like the cybersecurity mandate being created, it won’t be long until MFA is considered common practice for any online service handling sensitive data. 

Integrating MFA into current systems isn’t as difficult as one might think. Developers need only to integrate an existing MFA technology into their systems, rather than develop one themselves. Developing MFA is the hardest part, but luckily, security experts have done the hard work for us and made it easily obtainable online through various companies. These companies (e.g., Authy) provide developers with the needed code (or APIs) for integrating a MFA solution. These APIs are provided in several coding languages and designed to be easy to use. No special security know-how is required and can be easily deployed into your environment in a non-intrusive way. 

Using a 3rd party company to implement MFA doesn’t mean you have to trust them. Because these companies only have access to the MFA tokens, they do not have access to any other private information upon implementation. They only have access to one of the two layers of authentication required for MFA. If a MFA provider ever became compromised, accounts would still be safe, as username and password is still required in addition to the token. 

Take a look inside Multi-Factor for DB, providing Multi-factor Authentication for IDCS and on-premise Oracle Databases!

Even though integrating the MFA code into Oracle Middleware may be simple, adjusting configurations inside Oracle products can be perplexing for the average developer. Here at Hub City Media (HCM), we have developed a way to integrate Multi-factor Authentication into Oracle Middleware Homes quickly and easily. Not only has HCM written integration code for Oracle Fusion Middleware products, we have integrated MFA solutions! Integrating MFA into your Oracle Middleware Home can be a simple and quick solution to protecting your sensitive data. 

MFA is the new security standard and investing in this type of security solution is a simple and recommended investment. It may seem like something that can be put off until tomorrow; however, security of private information is not something to wait to protect. The best time for implementation is now. Every day your current system’s vulnerability is increasing, as technology and cybercriminals advance. 

Benjamin Franklin once said, “Never leave that till tomorrow which you can do today.” Take action now! 

If you have an Oracle environment that needs a Multi-factor Authentication security solution, contact us for a free consultation. 

---

PROFESSIONAL SERVICES - LEAD SYSTEMS ENGINEER

Confidentiality and Ethics: When Outside Consultants have Inside Access

Ethics Through The Eyes Of An IAM Consultant

As Identity and Access Management (IAM) consultants, we spend a significant amount of time in differing client environments, often having access to databases, directories and applications containing very sensitive user data. 

For example, we might be at a client site with full access to their Human Resources application. These applications contain very sensitive user information, including home addresses, social security numbers, salaries, etc. I can personally recall several instances where I was on a project with all of this data accessible.  

With increasing security concerns in both consumer applications and large-scale enterprise deployments, it becomes even more critical as professional consultants to adhere to a code of ethics that maintains end-user privacy, preserves confidentiality and protects against information leaks.

A few things to keep in mind: 

1. We have a responsibility to our clients and their user base to maintain privacy. User data, not just personally identifiable information, should always be respected. User data in Development and Quality Assurance environments is often directly copied from Production. This is a great security risk, as non-Production environments are often less secure and have greater levels of access within an organization, making them prone to misuse. Clients are advised to invest time in sanitizing data in these environments (e.g. scrambling SSNs or changing birth dates). With a bit of work, it is very much possible to maintain and mirror Production level data in Test environments.

2. While working on client projects, we have an obligation to keep information that we discover confidential. For instance, a consultant might have access to a client's IAM system and see a familiar employee in a 'Disabled' state with all access revoked. While it might be tempting to share this information with colleagues, it is highly unethical to do so. Often, we are asked to sign non-disclosure agreements; however, even if we are not, there is still a strong responsibility to keep private information private.

3. We also have an obligation to report when confidentiality might be at risk. For example, if you received an improperly distributed spreadsheet containing very sensitive information, such as employee salaries, you should quickly realize the error and immediately inform someone who is able to intercede before that information is leaked. If not, extremely sensitive data could be severely compromised.

Computer systems can be used to violate the privacy of others. As consultants, we have an obligation to maintain confidentiality. In the end, it’s about being professional and respecting the value of privacy.

For further reading about this topic, please refer to Software Engineering Code of Ethics and Professional Practice by the Association of Computing Machinery.