IT. SECURITY. OPEN SOURCE.

Tag: Security

Restrict AWS Console Access Based On Source IP Address

Zero trust, or risk-based authentication, can be hard to achieve (You can read more about it here). Organizations must trust the identity being used and the location from where the user is authenticating. Many cloud-based services, like AWS, have functionality built in to help protect your account. This is a must in preventing account takeover (ATO) while protecting the confidentiality, integrity, and availability of your AWS systems.

AWS’ built-in tools help protect your account which is easy to use. It is an automated process to validate that your Root account has multifactor authentication turned on, the Root account does not have programmatic access, etc. One function that is missing from the GUI is protecting accounts from untrusted networks. To do this, go to IAM and click on Policies. Create a new policy and use the JSON editor to paste the following:

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {"NotIpAddress": 
    {"aws:SourceIp": [
      "Source IP Address"
    ]}}
  }
}

Replace “Source IP Address” with your source IP address(es) of your corporate network.

Once the policy has been created, attach the policy to either a user account or a group that users are apart of. Now when someone tries to log in, from outside the network, the person will receive an “Access Denied” while trying to access any AWS resources.

For the latest on this policy, or other AWS policies, please check out the GitHub Repo.

Building Zero Trust in Authentication

Building Zero Trust

When you think of zero trust, you tend to think of network segmentation. Creating communities of interest (COI’s) and segmenting servers away from each other to prevent lateral movement within one’s network. Network segmentation is just the first step in a zero-trust model. Others include authentication, segregation of duties, and cryptographic certificates. Though all are important, authentication is a difficult one to get right.

Secure Shell, or SSH, is an authentication mechanism used for remote connectivity mainly to UNIX and Linux based operating systems. SSH creates a secure, encrypted, connection between the administrator’s endpoint to a server. Though SSH is heavily used for connectivity it does have one major flaw, you must trust the certificate presented to you upon the first login. Trust On First Use, or TOFU, requires the administrator to initially trust the server they are connecting to without knowing the validity of the certificates being presented. Once trust is given to an unknown certificate, the administrator is allowed to continue with their username and password.

Trust On First Use

TOFU is nothing new in terms of security and is widely used throughout information technology. Take for instance setting up a new firewall or other types of security appliances. Security appliances are designed to encrypt administrative connections to the management plane. Most, if not all major players use self-signed certificates in order to encrypt that communication. This is another example of TOFU where a firewall administrator must first accept an unknown security certificate prior to being allowed to connect to the device. Accepting unknown, or unverified, TLS certificates are something we tell end users not to do all the time. So why is it Ok for us to do so? How do we know whether our connections are trusted and not being compromised by a man in the middle attack?

How Do I Trust My Connections?

Unfortunately, there is no easy answer to this question. Systems are designed to create new private and public certificates upon installation. This is to ensure that no two private certificates are identical and not re-used between systems. When these certificates are generated for the first time, an administrator has no other option but to trust the certificate being handed out.

Cryptographically signing certificates is one such way that could be used to overcome this problem. This is performed on software package installation and patching. Microsoft, Red Hat, Ubuntu, and Apple all cryptographically sign their software. This prevents the operating system from installing applications that could have been created by a malicious user, potentially infecting one’s machine.

Organizations can perform the same level of trust for authentication. Creating an internal Public Key Infrastructure, or PKI, can reduce that uncertainty. PKI’s can provide validity in those connections as one has to first trust the root certificate authority. Once trust has been established, certificates generated and signed by the root certificate authority will also be trusted by the system. Though getting it right the first time might seem to be difficult. Once established, it can prove to be one of the best assets security professionals have in their arsenal.

Password Rotation And The Problem Of Not Doing It

Since the release of NIST SP 800-63-3 I have been asked, “Why does our company still perform password rotation?” This question is easier said than done. It is one that requires user awareness training, implementation of auditing and alerting software, and most importantly – multifactor authentication. All of which are necessary, though it can take months to years to implement depending on a companies resources and regulatory requirements.

User Awareness

We still seem to be failing at user awareness training. Our parents, grandparents, kids, co-workers, and yes even us still use easily guessable passwords. Studies have shown that for the past 5+ years the top passwords being used on the internet are, “123456”, “password”, “qwerty”, and “111111.” Talk show host Jimmy Kimmel and his television crew have shown how easy it is to social engineer someone to give up their password. These episodes also show the simplicity of the password with some saying their password is a pets name and a birth date.
Companies such as Microsoft have developed ways to prevent its users from picking simplistic passwords. With its new, “Password Protection for Azure AD” service, it prevents users from creating easily guessable passwords. This is performed by Microsoft’s massive database of commonly used passwords. If a user were to pick a password that was found in the database, the service presents an error message and the user must pick another one.

Auditing and Alerting Software

People often make mistakes, that is a given. Companies make similar mistakes as well. Facebook recently announced that the company was storing user passwords in clear text. What can be worse than that you ask? That database had been queried over 9 million times by Facebook staff. Facebook has been on the defensive stating that this was not a breach. While technically no it was not a breach, it shows how lacking they are in their security and privacy.

There are similar cases where companies lax in their security policies. It certainly opens the question of how we can protect ourselves online. With users picking easily guessable passwords, and the reuse of those passwords, auditing and alerting tools are a necessity. Organizations need tools in place to be able to send alerts when an account is being brute forced. They also need to alert when someone is logging in from a country where there is no organizational presence. These are key indicators of account takeovers. Without this in place, a security operations team will never know if an account has been compromised.

What Is Multifactor Authentication

Multifactor (also known as 2 factor) is defined as:

  • Something you have
  • Something you know
  • Something you are

To suffice this definition, one must utilize two of the three listed. Something you have and something you are is the most common. How does this protect against account take overs? If one were to use a semi-guessable password and configured multifactor authentication, account take over would be extremely difficult to pull off. The reason is that even if someone were to have your password, that person could still not log into the account as the second factor has not been met. The second factor in most instances is something that you have. Examples of this are a smart app on your mobile device, a hardware device such as a YubiKey, or a text message. Though using text messages as a form of second factor is now highly discouraged. Without having physical access to any of these devices, it can be nearly impossible to log into an account. There is a website dedicated to help in configuring multifactor authentication by heading on over to Two Factor Auth List. This website will show you which popular online services allow for multifactor authentication, and if they do not, you are able to send a message to the service asking them to enable it.

Final Thoughts

Password rotation is an evil necessity without properly thinking things through. Yes it does not prevent an account take over, however rotation will eventually keep an attacker from logging in. The use of multifactor authentication, auditing and alerting, coupled with user awareness training are essential to good password hygiene. Without these in place, the organization will be stuck on rotation – like a broken record.

Facebook Exposes Millions of Passwords in Clear Text

Facebook has been under the spot light for quite some time now for its poor security and privacy practices. With this latest privacy blunder, its obvious that the company has not learned from its past. Last week it was uncovered that the company is storing passwords in clear text. This not only affects Facebook users, but InstaGram users too. It was not revealed as to why these passwords were stored in clear text, however what is known is that it affects millions of the company’s users.

In a Facebook blog post by Pedro Canahuati, VP Engineering, Security and Privacy mentioned that the company uncovered the error in January during a routine security review. Canahuati also stated that these clear text passwords were only viewed by those who worked for the company.

At least LinkedIn has your back… Oh nevermind.

Let’s not forget the many security breaches which affected passwords in the past. LinkedIn in 2012 had millions of passwords stolen from the company by hackers. In the breach, the passwords had been hashed, but with a low grade hashing algorithm. At least in LinkedIn’s case we can say the passwords were somewhat protected. In Facebook’s instance, they did not even bother to encrypt the passwords. If the passwords were ever stolen we would see another Yahoo! breach in the making.

Protecting Yourself Online

Canahuati did not mention in his post how to remedy the issue other than to say that the passwords are hashed and salted when an account is created. I would still suggest that everyone change their passwords anyway along with activating multifactor authentication for their account. This way even if someone were to have the password, they would not have the secret token generated by a smart app or hardware token like YubiKey. This also includes those who have InstaGram accounts as well since they were also affected.

One cannot trust the privacy and security that a service provider offers. We must take it upon ourselves to better protect our online identities from mishaps of the services we use. By using password managers to ensure we do not reuse the same password between services to ensuring multifactor authentication is used on every service that offers it is the only way to protect ourselves.

State Sponsored Probing Internet of Things Devices

In order to beef up security of consumer based Internet of Things devices, Japan will now scan IoT devices within its borders. Beginning mid-February, the National Institute of Information and Communications Technology will attempt to break into an estimated 200 million devices. The institute has compiled a list of generic usernames and passwords commonly used by manufacturers for default login credentials. Is this a good thing?

In 2018, the FBI warned citizens of a potential threat to their home routers to reset them (Why the FBI wants you to reboot your router — and why that won’t be enough next time). In 2016 Duetsche Telekom in Germany was down due to an infection of consumer based routers which affected 900,000 consumers (900,000 Routers Knocked Offline in Germany amid Rumors of Cyber-Attack). It took the telecom provider two days to get the word out as most, if not all, of its customers used it for data and voice. Why did it take so long and how did 900,000 routers get infected? One simple answer, the management interface was exposed to the public internet. This allowed the botnet to quickly infect consumer based routers. Once a router became infected, it then scanned the internet looking for other routers to infect.

Japan’s attempt to detect unsecured IoT devices is a good thing, to a point. The Institute has not come out to say what they will do when an unsecured device is detected. Will they send notices to citizens? How will manufacturers be held accountable? What types of fines will be given for poorly secured consumer IoT devices? This is definitely a step in the right direction however it does not appear at this time that they have fully thought through the repercussions.

© Copyright 2020 – Jason Brown