OWASP Top Ten 2021 (Major Update from 2017)

Someone once said never commit to memory what you can write down. So here is the OWASP Top Ten for all those attending interviews and need to brush up what the current order of the OWASP Top Ten Application vulnerabilities. This is the current 2021 OWASP Top Ten.

(1) A01:2021 Broken Access Control

Moves up from the fifth position; 94% of applications were tested for some form of broken access control. The 34 Common Weakness Enumerations (CWEs) mapped to Broken Access Control had more occurrences in applications than any other category.

Access control refers to a system that controls access to information or functionality. Broken access controls allow attackers to bypass authorization and perform tasks as though they were privileged users such as administrators. For example, a web application could allow a user to change which account they are logged in to simply by changing part of a URL, without any other verification.

Access controls can be secured by ensuring that a web application uses authorization tokens* and sets tight controls.

Many services issue authorization tokens when users log in. Every privileged request that a user makes will require that the authorization token be present. This is a secure way to ensure that the user is who they say they are without having to constantly enter their login credentials.

  • – Allows access to restricted resources

(2) A02:2021 Cryptographic Failures

Shifts up one position to #2, previously known as Sensitive Data Exposure, which was a broad symptom rather than a root cause. The renewed focus here is on failures related to cryptography which often leads to sensitive data exposure or system compromise.

(3) A03:2021 Injection

Slides down to the third position. 94% of the applications were tested for some form of injection, and the 33 CWEs mapped into this category have the second most occurrences in applications. Cross-site Scripting is now part of this category in this edition

If web applications don’t protect sensitive data such as financial information and passwords, attackers can gain access to that data and sell or utilize it for nefarious purposes. One popular method for stealing sensitive information is using a man-in-the-middle attack.

Injection attacks happen when untrusted data is sent to a code interpreter through a form input or some other data submission to a web application. For example, an attacker could enter SQL database code into a form that expects a plaintext username. If that form input is not properly secured, this will result in that SQL code being executed. This is known as an SQL injection attack.

Injection attacks can be prevented by validating and/or sanitizing user-submitted data. (Validation means rejecting suspicious-looking data, while sanitization refers to cleaning up the suspicious-looking parts of the data.) In addition, a database admin can set controls to minimize the amount of information an injection attack can expose.

– LDPA
– SQL
– OS
– XSS
– Log

(4) A04:2021 Insecure Design

A new category for 2021, focusing on risks related to design flaws. If we genuinely want to “move left” as an industry, it calls for more use of threat modeling, secure design patterns and principles, and reference architectures.

(5) A05:2021 Security Misconfiguration

Moves up from #6 in the previous edition; 90% of applications were tested for some form of misconfiguration. With more shifts into highly configurable software, it’s not surprising to see this category move up. The former category for XML External Entities (XXE) is now part of this category.

Security misconfiguration is the most common vulnerability on the list and is often the result of using default configurations or displaying excessively verbose errors. For instance, an application could show a user overly-descriptive errors, which may reveal vulnerabilities in the application. This can be mitigated by removing any unused features in the code and ensuring that error messages are more general.

(6) A06:2021 Vulnerable and Outdated Components

Many modern web developers use components such as libraries and frameworks in their web applications. These components are pieces of software that help developers avoid redundant work and provide needed functionality; common examples include front-end frameworks like React and smaller libraries that are used to add share icons or a/b testing. Some attackers look for vulnerabilities in these components, which they can then use to orchestrate attacks. Some of the more popular components are used on hundreds of thousands of websites; an attacker finding a security hole in one of these components could leave hundreds of thousands of sites vulnerable to exploitation.

Component developers often offer security patches and updates to plug up known vulnerabilities, but web application developers don’t always have the patched or most-recent versions of components running on their applications. To minimize the risk of running components with known vulnerabilities, developers should remove unused components from their projects, as well as ensure that they are receiving components from a trusted source and ensuring they are up to date.
Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.

  • NIST NVD
  • Shodan

(7) A07:2021 Identification and Authentication Failures

Previously Broken Authentication and is sliding down from the second position, and now includes CWEs that are more related to identification failures. This category is still an integral part of the Top 10, but the increased availability of standardized frameworks seems to be helping.

Vulnerabilities in authentication (login) systems can give attackers access to user accounts and even the ability to compromise an entire system using an admin account. For example, an attacker can take a list containing thousands of known username/password combinations obtained during a data breach and use a script to try all those combinations on a login system to see if there are any that work.

Some strategies to mitigate authentication vulnerabilities are requiring 2-factor authentication (2FA) and limiting or delaying repeated login attempts using rate limiting.

  • Weak Password Policy
  • Weak Cryptography
  • User Access Controls

(8) A08:2021 Software and Data Integrity Failures

A new category for 2021, focusing on making assumptions related to software updates, critical data, and CI/CD pipelines without verifying integrity. One of the highest weighted impacts from Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) data mapped to the 10 CWEs in this category. Insecure Deserialization from 2017 is now a part of this larger category.

(9) A09:2021 Security Logging and Monitoring Failures

Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.

SIEM

App Logging

Crash Logging

Exception Handlling

(10) A10:2021 Server-Side Request Forgery

Added from the Top 10 community survey (#1). The data shows a relatively low incidence rate with above-average testing coverage, along with above-average ratings for Exploit and Impact potential. This category represents the scenario where the security community members are telling us this is important, even though it’s not illustrated in the data at this time.

The official OWASP PDF for the OWASP Top Ten 2021 can be found here.

Advertisement

Security Assertion Markup Language (SAML)

SAML Security we got this.

What is SAML?

SAML is a (XML) open standard for the digital mechanics when performing and sharing Authorization and Authentication between two parties, namely (SP) Service Provider and (IdP) Identity Provider.

How does the SAML Work?

1. User initiates a request to a resource (www.mybankApp.com)

2. (SP) Service Provider picks up the request (should be from behind a API gateway protected by a WAF and Edge controls) , checks to see if the request needs to be authenticated, if so the SP will send a SAML request to the IdP via the users browser.

3. Users browser forwards the SAML request to the IdP.

4. IdP sends a HTTPS request to the user with a SAML authentication request. User responds with valid authentication credentials (USER && PASS && OTP).

5. If authentication is successful the IdP will send a response back to the SP via the users browser.

6. User browser forwards to the authenticated response back to the SP to request the restricted resource.

7. SP will check if the authenticated user has the rights to access the resources if so an authenticated session will be established with the user and resource via the SP.

Key Terms relating to SAML

SAML TERMDescription
IDPIdentity Provider responsible for Authentication
SPService Provider responsible for managing authorisation of resources.
SAML RequestIssued from SP to user’s browser for redirecting to IdP
SAML ResponseTrusted response sent from SP to requestor with access to the requested resource or failed response with no access to the resource. Should always be signed by a private key
AssertionSecure encrypted XML entity with sensitive data
XML Signature (DSIG)Typically a configuration of a shibboleth library within the SP to carry out hashing
AttributesUser attributes encrypted within an assertion
Relay StateUsed for pre authed users requests, set to use once to stop replay attacks
SAML TrustTrust store and configuration for certificates. (Certificate Trust configuration)
MetadataXML Configuraiton files for discover and configuration convenience.
Core SAML terms and descriptions

What is SAML used for?

It’s basically a standard way of using XML to facilitate SSO.

SAML is used to authenticate users in a (SSO) Single Sign On scenario. As we explained more technically above, it passes user identity credentials between a SP and IDP such as Azure AD.

SAML can be configured to be IdP initiated or SP initiated these are the 2 uses case flows for SAML. Both have different use cases:

Use case 1 IdP Initiated: Used for protected resources, only a valid authenticated response is needed to access the resource.

Use case 2 SP Initiated: is used to access the resource directly, the SP will determine if the user is needed to authenticate before accessing the resource. If the resource is protected (non public data) a request will then be sent to the IdP in order for the user to authenticate first with the IdP in order to create the correct assertion to be sent to the SP to allow access to the resource.

A modern based cloud architecture for SAML SSO via application proxies with AAD on Azure Cloud.

SAML Architecture is based on existing standards such as:

Security Concerns & Best Practices for SAML

Denial of Servicce (DOS) – Parsers should be reviewed for unused functions, design review of the request creation and parsing technologies used.

Flawed assertion validation – Signature checks, Assertion Consumer Service insecure configuration, Trust Store, SAML Response validation

XML Parser – Unused functions, known vulnerabilities, Document Type Definition (DTD) Fetching see XXE. Canonicalized XML (comment stripping)

XXEXML External Entity (Injection) – Due to the fact that SAML Responses are deflated and base64’d XML documents, we can test for XXE by manipulating the XML document sent as the SAML Response. Example:

Schema Validation – Signature Wrapping (XSW) Attacks, Signature Validation & Function Validation, Explicit Expressions

Validate Every Signature – Limit Algos (SHA256), None =(,

HTTPS – Not self signed

Validate Parties – Destination, Issuer, Recipient,

Validation Window – Session Time

Historical Cache – No Duplicates (Replay Attacks)

Limit Buffer Size – DOS, Biuffer Overflow.

Cypherpunks Mailing List

Although originally formed of members from the Bay area of San Francisco the movement began to take off and it was soon decided to set up a mailing list to reach out to other like minded folks or should I say Cypherpunks.

The mailing list soon expanded and included hundreds of subscribers, keen to discuss developments in Mathematics, Computer Science, Cryptography, Politics and Philosophy, to debate, exchange ideas, and test cyphers on a daily basis.

The new, PGP encryption method was used to ensure complete privacy to the exchanges which meant ideas could be freely discussed and shared. It became an open forum where personal privacy and personal liberty were held above all other considerations.

The Cypherpunks mailing list consisted of many notable names still active today…. let’s take a look at the original bad boys and see how they have shaped today’s technological society….

  • Jacob AppelbaumTor developer, political advocate
  • Julian Assange: WikiLeaks founder, deniable cryptography inventor, journalist; co-author of Underground; author of Cypherpunks: Freedom and the Future of the Internet; member of the International Subversives. Assange has stated that he joined the list in late 1993 or early 1994. An archive of his cypherpunks mailing list posts is at the Mailing List Archives.
  • Derek Atkins: computer scientist, computer security expert, and one of the people who factored RSA-129
  • Adam Back: inventor of Hashcash and of NNTP-based Eternity networks; co-founder of Blockstream
  • Jim Bell: author of Assassination Politics’
  • Steven Bellovin: Bell Labs researcher; later Columbia professor; Chief Technologist for the US Federal Trade Commission in 2012
  • Matt Blaze: Bell Labs researcher; later professor at University of Pennsylvania; found flaws in the Clipper Chip
  • Eric Blossom: designer of the Starium cryptographically secured mobile phone; founder of the GNU Radio project
  • Jon Callas: technical lead on OpenPGP specification; co-founder and Chief Technical Officer of PGP Corporation; co-founder with Philip Zimmermann of Silent Circle
  • Bram Cohen: creator of BitTorrent
  • Lance Cottrell: original author of the Mixmaster Remailer software; founder of Anonymizer
  • Matt Curtin: founder of Interhack Corporation; first faculty advisor of the Ohio State University Open Source Club; lecturer at Ohio State University
  • Hugh Daniel (deceased): former Sun Microsystems employee; manager of the FreeS/WAN project (an early and important freeware IPsec implementation)
  • Suelette Dreyfus: deniable cryptography co-inventor, journalist, co-author of Underground
  • Hal Finney (deceased): cryptographer; main author of PGP 2.0 and the core crypto libraries of later versions of PGP; designer of RPOW
  • Eva Galperin: malware researcher and security advocate; Electronic Frontier Foundation activist
  • *John Gilmore*: Sun Microsystems’ fifth employee; co-founder of the Cypherpunks and the Electronic Frontier Foundation; project leader for FreeS/WAN
  • Mike Godwin: Electronic Frontier Foundation lawyer; electronic rights advocate
  • Ian Goldberg*: professor at University of Waterloo; designer of the off-the-record messaging protocol
  • Rop Gonggrijp: founder of XS4ALL; co-creator of the Cryptophone
  • Sean Hastings: founding CEO of Havenco; co-author of the book God Wants You Dead
  • Johan Helsingius: creator and operator of Penet remailer
  • Nadia Heninger: assistant professor at University of Pennsylvania; security researcher
  • Robert Hettinga: founder of the International Conference on Financial Cryptography; originator of the idea of Financial cryptography as an applied subset of cryptography
  • Marc Horowitz: author of the first PGP key server
  • Tim Hudson: co-author of SSLeay, the precursor to OpenSSL
  • *Eric Hughes*: founding member of Cypherpunks; author of A Cypherpunk’s Manifesto
  • Peter Junger (deceased): law professor at Case Western Reserve University
  • Werner Koch: author of GNU Privacy Guard
  • Paul Kocher: president of Cryptography Research, Inc.; co-author of the SSL 3.0 protocol
  • Ryan Lackey: co-founder of HavenCo, the world’s first data haven
  • Brian LaMacchia: designer of XKMS; research head at Microsoft Research
  • Ben Laurie: founder of The Bunker, core OpenSSL team member, Google engineer.
  • Moxie Marlinspike: founder of Open Whisper Systems (developer of Signal); author of the Convergence SSL authenticity system, co-author of the Signal Protocol and the Double Ratchet Algorithm (with Trevor Perrin).
  • Morgan Marquis-Boire: researcher, security engineer, and privacy activist
  • *Timothy C. May*(deceased): former Assistant Chief Scientist at Intel; author of A Crypto Anarchist Manifesto and the Cyphernomicon; a founding member of the Cypherpunks mailing list
  • *Jude Milhon* (deceased; aka “St. Jude”): a founding member of the Cypherpunks mailing list, credited with naming the group; co-creator of Mondo 2000 magazine
  • Vincent Moscaritolo: founder of Mac Crypto Workshop; Principal Cryptographic Engineer for PGP Corporation; co-founder of Silent Circle and 4th-A Technologies, LLC
  • Sameer Parekh: former CEO of C2Net and co-founder of the CryptoRights Foundation human rights non-profit
  • Vipul Ved Prakash: co-founder of Sense/Net; author of Vipul’s Razor; founder of Cloudmark
  • Runa Sandvik: Tor developer, political advocate
  • Len Sassaman (deceased): maintainer of the Mixmaster Remailer software; researcher at Katholieke Universiteit Leuven; biopunk
  • Bruce Schneier: well-known security author; founder of Counterpane
  • Nick Szabo: inventor of smart contracts; designer of bit gold, a precursor to Bitcoin
  • Zooko Wilcox-O’Hearn: DigiCash and MojoNation developer; founder of Zcash; co-designer of Tahoe-LAFS
  • Jillian C. York: Director of International Freedom of Expression at the Electronic Frontier Foundation (EFF)
  • John Young: anti-secrecy activist and co-founder of Cryptome
  • Philip Zimmermann: original creator of PGP v1.0 (1991); co-founder of PGP Inc. (1996); co-founder with Jon Callas of Silent Circle

The mailing list continued after the 90’s using different formats.

Who would you add to this list, past or present? (leave comments below) follow on @Twitter the #CryptoGirlGang @HODLER_J @BITCOINSHELLY @SARAH_SATOSHI @CrypoQueen___

A Brief History of CypherPunks & Crypto Currency

Dr David Chaum1980’s, Dr David Chaum wrote numerous papers on subjects including; “Security without Identification: Transaction Systems to Make Big Brother Obsolete” and “Numbers Can Be a Better Form of Cash than Paper. Chaum basically predicted the anonymous use of electronic money as opposed to paper money, which we all now know, as Crypto-Currencies.

Eric Hughes1992, Eric Hughes, drafts the Cypherpunks Manifesto in which he states ‘privacy in an open society requires anonymous transaction systems. Until now, cash has been the primary such system. An anonymous transaction system is not a secret transaction system. An anonymous system empowers individuals to reveal their identity when desired and only when desired; this is the essence of privacy.’

Adam Back1997, Adam Back creates Hashcash an anti-spam mechanism which adds a time and computational power cost to sending email, making the sending of spam uneconomical. The sender would have to prove that they had expended computational power to create a stamp in the header of an email (similar to the proof of work (POW) use in Bitcoin) before they can send it.

Wei Dai1998, Wei Dai, publishes a proposal for B-Money. This included two methods of maintaining transaction data; a) every participant to the network would maintain a separate database of how much money belongs to users and, b) all records are kept by a specific group of users. WithIn the second option the group of users who have custody over the records are incentivised to be honest because they have deposited their own money into a special account and stand to lose it if they are not. This method is known as “proof of stake” (POS) and the specific groups of users (or master nodes) will lose all the funds they have staked if they attempt to process any fraudulent transaction.

Hal Finney2004, Hal Finney, created Reusable Proofs of Work which borrowed from the principles of Backs’ Hashcash

Nick Szabo2005, Nick Szabo publishes his proposal for Bitgold, built on previous ideas developed by Hal Finney and others.

Satoshi Nakamoto2008, Satoshi Nakamoto, an anonymous individual or group of individuals, sends a paper to the cypherpunk mailing titled, “Bitcoin: A Peer-to-Peer Electronic Cash System”. This paper makes direct references to b-money and hashcash and addresses many of the issues that previous developers had such as, double spending (the risk that a single token is used multiple times to purchase goods). Even though the papergarnered a lot of criticism from sceptics, Nakamoto continued on and mined the genesis block of Bitcoin on 3 January 2009.

Follow on Twitter @Hodler_J @Sarah_Satoshi @CryptoQueen___ @BitcoinShelly #CryptoGirlGang for more info and NFT cypherpunk collectibles.

LDAP Injection Attacks Explained

Bad Injection

Injection or code injection are the most common attack types against web applications, mobile applications, desktop applications, API’s, Databases, web servers and everything around or in between that takes code as an input.

One of the most common type of injection attacks, LDAP Injection, is outlined in this article. I will explain some of the common reasons why this vulnerabilities exist and I will discuss and show examples of common attack vectors and methods used to exploit these vulnerabilities to either extract data or compromise the system entirely.

According to the OWASP Top Ten Injection attacks have been the most dangerous cause of attack against web based applications since 2007 and continue to hold the number one spot on the OWASP Top Ten for 2019.

LDAP Injection: First we will discuss what LDAP is before we look at how we can attack it. LDAP stands for Lightweight Directory Access Protocol, which basically means it a mechanism to look up directory listings in a LDAP database or server and because of its lightweight design it’s well suited and used amongst many systems. LDAP is generally used for a central repository for users on a intranet or internet based application(SSO).

A LDAP directory consists of a set of attributes based off a defined schema. Each entry into this schema/directory has a unique identifier called a DN. The example below shows an entry for John Doe a fake user in a fake organisation directory.

 dn: cn=John Doe,dc=example,dc=com
 cn: John Doe
 givenName: John
 sn: Doe
 telephoneNumber: +1 888 555 6789
 telephoneNumber: +1 888 555 1232
 mail: john@example.com
 manager: cn=Barbara Doe,dc=example,dc=com
 objectClass: inetOrgPerson
 objectClass: organizationalPerson
 objectClass: person
 objectClass: top

LDAP is an open source technology so the best place to learn about it is at LDAP website here.

Ok so what about LDAP injection and how can it affect a user, business or organisation? Taking the example above we can see that the information typically associated with LDAP is sensitive data, this is usually the data a malicious user is after. So let’s say we wanted to look up users on a LDAP system.

Enumerate Users Attack

A normal LDAP query for an application would look something like

http://www.softwaresecurity.blog/people_search.aspx?(name=Shah)(zone=public)

A malicious query on the same URL would be to change the zone attribute and instead of the public value we change it to * which is most parser engines is the command for ALL. Our new query looks like this

http://www.softwaresecurity.blog/people_search.aspx?(name=Shah)(zone=*)

The result is we can return all users for SHAH in every zone in the directory, when we should only be able to return the user SHAH in the public zone. How to protect against this? Use parameterised queries or a framework that will help you validate and sanitise your data before processing. Check out the OWASP Cheat sheet for LDAP Injection prevention here. Also for common testing payloads you can refer to this cheetsheet.

Access Control Bypass Attack

Again an LDAP query is used for validating a users credentials on a successful match the user is logged in, if the match is un-successful the login process fails and an error message is returned. Sounds standard but lets see how we can exploit a vulnerable implementation of the login functionality.

A normal query would look like

https://softwaresecurity.blog?(&(name=SHAH)(password=My5up3rSecureP@55w0rd))

A malicious query on the same URL would insert an ampersand & between the name and password attributes, because only the first two attributes are parsed this would change the statement to read if name = SHAH & nothing = nothing. Executing this query on the LDAP Directory would result in a true result and therefore pass our authentication gate. Our new query looks like this

https://softwaresecurity.blog?(&(name=SHAH)(&)(password=ANYTHING))

Although the above are trivial attack vectors the impact of these exploits can lead to a full breach or compromise of a system using LDAP as an authentication mechanism. Some advice is to improve your SSDLC methodology.

  • Define a secure coding standard for developers to work from. (ASVS)
  • Carry out Threat Modelling (Threat Modeller)
  • Create secure user stories based on requirements you are developing & threat modelling out comes. (JIRA)
  • Automate the use of SCA (Whitesource)
  • Automate Static Application Code Testing(SAST)
  • AutomateDynamic Application Security Testing(DAST)
  • Have a single pane of glass for all security issues (VMS)
  • More….

Feed the results into your bug tracking system to allow for remediation actions to be part of the backlog for the following sprints. Security doesn’t have to be a blocker to development teams, it can be an integral part of the agile processes used for todays development teams.

An Introduction to Kubernetes (K8S)

Kubernetes (K8S) is derived from the Greek meaning, ‘captain of the ship’. An analogy for Kubernetes (K8S) being that containers that are loaded onto the ship managed by the captain are like docker containers loaded into the Kubernetes (K8S) container orchestrator, managed by the kubectl captain. K8S is the shorthand name for Kubernetes used mainly in the development community.

Kubernetes is used for automating deployment, scaling and management of containerised applications.

Kubernetes started life as a Google project called Borg also known as “The Borg Project”. Google created ‘The Borg’ project to manage their rapidly growing container environments running their Google apps infrastructure. Kubernetes is an open source project branched from ‘The Borg’ project. The main contributors were originally google employees and then more and more a community was created and today Kubernetes has a vast eco system.

Comparing the technologies used for container orchestration we soon see Kubernetes is the main player in this space. Kubernetes solves the problem of management when you have 100’s , 1000’s or millions of containers in your environments.

  • Borg
  • Mesos
  • Kubernetes
  • Omega

Borg: As we have mentioned Borg is a closed source project created at Google. Borg was the original code base for Kubernetes released to the public by Google around 2014. Google stated “We are not sure where the ultimate scalability limit to Borg’s centralized architecture will come from; so far, every time we have approached a limit, we’ve managed to eliminate it.

Mesos: Is another container orchestrator created over at the Apache Foundation. Mesos is built using the same principles as the Linux kernel, only at a different level of abstraction. The Mesos kernel runs on every machine and provides applications (e.g., Hadoop, Spark, Kafka, Elasticsearch) with API’s for resource management and scheduling across entire datacenter and cloud environments.

Docker Swarm: Docker swarm is a native component of docker. Docker swarm allows you to manage a cluster of docker engines called swarms. There are pro’s and cons against using docker swarm over Kubernetes it all depends on the goals of your distributed system.

Cloud Foundry: Cloud Foundry is a PaaS for applications deployed to the cloud. Cloud Foundry supports a DevSecOps methodolgy due to it’s internal continuous delivery systems supporting the SDLC, from initial development through all testing stages to deployment.

Omega: Omega is Google’s next generation cluster management system. Considered to be underdevelopment and still in theory state. If Borg is anything to set the standards by then Omega could blow everything out the water (Pun Intended).

The current problem architecture google predict Omega will resolve. Aiming to go from the current 2 state architecture to a shared state architecture.

The Kubernetes Architecture

Head (Master) Node: The head, AKA Master node, is the brain of Kubernetes. The Master node is responsible for running the API server, Scheduler, Controller Manager, Datastore(ectd), kubectl, docker. These are the only processes you will see running on the head node at any time. We’ll define each of these processes in more detail after the high level review of the kubernetes arcbitecture.

Worker Node: The worker node is what it says, this does all the work for your application. This is the home for your application and this is where the resources for your application are taken from. The worker node is one of many worker nodes within the kubernetes orchestration stack. All worker nodes within a kubernetes deployment are managed by one head node. Security and redundancy will be discussed in detail in the next post so keep reading and following to catch these posts.

The worker node has the following processes kubelet (talks to the api server), KUBE-PROXY manage the ip tables in that node?, docker (pods) the container that holds the application.

This is a Seagulls view of K8, I hope this has given you a little background into where Kubernetes has come from, what is the main architecture of Kubernetes and also what are the key components of kubernetes. In my next post I will be discussing the security best practices when working within a Kubernetes infrastructure.

Breaking Down the TLS Handshake

When asked “Can you tell me how the TLS handshake works?” Ask in reply “Are you referring to Mutual TLS Authentication or Server Side TLS Authentication?”

In the above diagram we show the most popular of the two handshakes, Server Side TLS Authentication. Mutual TLS Authentication is also known as Client Side TLS Authentication.

About the Protocol

The TLS protocol sits between the Application Layer and the Transport Layer. It is divided in two main sublayers. This is the general structure of the protocol, and its place in the network stack:

The TLS handshake uses both Symmetric and Asymmetric encryption. Symmetric means you have one key to encrypt and decrypt the secret (data). Asymmetric means you have one key to encrypt the secret and a different key to decrypt the secret.

Explaining the Handshake Stages

Client Hello: This is a message originating from the client in order to ask the server for a certificate and secure connection in which to send data. The Client Hello message contains some key pieces of information, Handshake(SYN), TLS Version, Cipher Suites, Compression Method, Extensions.

  • Handshake (SYN, SSL/TLS Version)
  • Cipher Suites (Length, Cipher ID)
  • Compression Methods (Length, CMP-ID)
  • Extensions (Length, Extension ID, Extension Data)

Server Hello: This message is very similar to the Client Hello message, with the exception that it only includes one CipherSuite and one Compression method, this depends on the security configuration of the server. The server also sends its certificate which contains its public key signed by a known Certificate Authority (CA), think in terms of an envelope, where the public key is the letter inside and the sealed envelope is the CA’s signature. This public key contained in the certificate, if accepted by the client (browser) by passing the checks against the clients(browsers) CA list, will be used to encrypt the data on the client side.

  • Handshake (SYN/ACK, SSL/TLS Version)
  • Accepted Cipher Suite (Length, Cipher ID)
  • Accepted Compression Method (Length, CMP-ID)
  • Accepted Extension (Length, Extension ID, Extension Data)
  • Random String (Used to create the session keys)

Server Hello Done: The server sends a HelloDone(ACK) message.

Client Premaster Secret: The client responds to the server with a premaster key that it generates and sends to the server. The client encrypts the Premaster Secret with the public key it has just received from the servers certificate.

The server now has the ability to decrypt the Premaster Secret with the servers private key.

Server & Client Session Key Creation: The server & client now create a session key based on the random string the server generated and the premaster secret the client created. The session keys should match and therefore be accepted by the server as a valid authenticated session.

Client Finished: The client now sends a “Finished” encrypted message with a session key.

Server Finished: The server now sends a “Finished” encrypted message with a session key.

Handshake Finished: The TLS Handshake has now finished successfully and we can now send encrypted messages using the client/server public private key pair and the session keys. Upon disconnection the session keys are removed from the server and the connection process repeats again upon the next Client Hello.

Further Reading…

All Priests Swear They Never Desire Pu**y.

Ahhhh nemonic’s they’re a great way to remember a list of things, but would get you burned at the stake back in the day for using them. So the title of this post is just that, a nemonic. I learned the power of nemonic’s when I read Derren Brown‘s book ‘Tricks of the Mind’.  After reading the book I then had the ability and still do to remember all 39  works of William Shakespeare in chronological order starting with Two Gentlemen of Verona and Ending with Two Noble Kingsmen, and yes for you experts the debate goes on…

sexy-priest-and-nun-costumes-for-women-outfit-uniform-Adult-Women-Cosplay-fancy-Dress-halloween-costumes.jpg_q50

So back to the topic what the hell are we talking about in regards to our title, well it’s not as seductive a topic as it may seem and hence the need to use nemonic’s to remember the list. Have you ever heard of the OSI model? Open System Intercommunications Model? I don’t blame you and to be honest you probably wont ever have to know what it is or remember it. But for the few of us that do well here’s how I chuckle about the topic and make it easier for me to remember the model and layers as we call them. Oh yes and the nemonic is not my suggestion it was given to me from a close colleague and mentor when I kept failing to remember the model and the different layers and the low level meaning, cheers Mr B.

Here’s the nemonic.

  • All = Application (Layer 7)
  • Priests = Presentation (Layer 6)
  • Swear = Session (Layer 5)
  • They = Transport (Layer 4)
  • Never = Network (Layer 3)
  • Desire = Data (Layer 2)
  • Pussy = Physical (Layer 1)

If you want to know what all the technical jargon is behind this rather rude nemonic, here it is.

The Open Systems Interconnection model (OSI model) is a conceptual model that characterizes and standardizes the communication functions of a telecommunication or computing system without regard to its underlying internal structure and technology. Its goal is the interoperability of diverse communication systems with standard communication protocols. The model partitions a communication system into abstraction layers. The original version of the model had seven layers.

A layer serves the layer above it and is served by the layer below it. For example, a layer that provides error-free communications across a network provides the path needed by applications above it, while it calls the next lower layer to send and receive packets that constitute the contents of that path. Two instances at the same layer are visualized as connected by a horizontal connection in that layer.

The model is a product of the Open Systems Interconnection project at the International Organization for Standardization (ISO).

How to protect against credential stuffing on AWS

Credential Stuffing is an attack against a web application’s login mechanism. It is part of the Brute Force attacks outlined in the OWASP Top Ten. It is a major threat for the retail industry and gaming industry, but is not reserved to these industries alone. Credential Stuffing usually takes known username and passwords to carry out the attack, these are usually gained from data breaches, pastebin dumps, dark web e-commerce sites and more.

There are some very similar attack type’s that have the same impact as Credential Stuffing and this post will out line the application and infrastructure security mechanisms you should use to help prevent Credential Stuffing attacks. The focus of this post will be around AWS Cloud Hosting bu can apply across all over hosting platforms. It is also key to point out the separation of security approaches in order that the focus and implementation is carried out with the right people in the right layers.

Attack TypeDescription
Brute ForceTesting multiple passwords from dictionary or other source against a single account.
Credential StuffingTesting username/password pairs obtained from the breach of another site.
Password SprayingTesting a single weak password against a large number of different accounts.

Credential Stuffing attack can come from a manual user using 1 IP or can come from a group of attackers using many different IP’s and using bot’s. It is key that we are able to distinguish from an honest attempt from a user to login multiple and a malicious login attempt.

Single User IP Multiple Different Account Logins. This is usually the script kiddy or hacker n00b. These attacks are easy to detect and easy to defend and once implemented will usually deter the would be attacker off to a less secure site. Most attackers use the same automated open source free tools like Sentry MBA, Vortex and Account Hitman to carry out the attacks. All you need is a computer, internet link, malware tool and a data breach dump.

  • Elastic Load Balancer (Infrastructure Security Control)
  • AWS WAF (Infrastructure Security Control)
  • AWS CloudFront (Infrastructure Security Control)
  • AWS Shield (Infrastructure Security Control)
  • Multi Factor (Business Driven Option) (Application Security Control)
  • Capture (Application Security Control)
  • Block/BlackList IP (Application Security Control)
  • Rate Limit Header (Application Security Control)
  • Block Headless Browsers (Application Security Control)

Multiple IP’s Multiple Different Account Logins. This is not a script kiddie or n00b, take this attack seriously because the actors carrying out this attack are very serious. This multi layered attack usually comes from a group of attackers and sometimes from very sophisticated evasive techniques. To protect against this type of attack we must be prepared to go a lot deeper in our defences. The tools used to carry out these attacks are custom proxies, STORM, Black Bullet, Private Keeper, SNIPR, Sentry MBA, and WOXY, Account Hitman and more.

  • Elastic Load Balancer (Infrastructure Security Control)
  • Commercial WAF (F5) (Infrastructure Security Control)
  • AWS WAF (Infrastructure Security Control)
  • Honey Pot Redirection (Infrastructure Security Control)
  • AWS Cloud Front (Infrastructure Security Control)
  • AWS Sheild (Infrastructure Security Control)
  • AWS Route 53 (Infrastructure Security Control)
  • Capture (Application Security Control)
  • Two Step Login Process (Application Security Control)
  • Multi Factor (Business Driven Option) (Application Security Control)
  • Block/BlackList IP (Application Security Control)
  • Finger Print Client (Application Security Control)
  • Rate Limit Header (Application Security Control)
  • Rate Limit on Non residential ASN (Application Security Control)
  • Require JavaScript (Application Security Control)
  • Block Headless Browsers (Application Security Control)

In the above architecture we can see an AWS WAF service implemented. Upon detection of a known bad request the logs of this request would be filtered through various log services in order to update the WAF to block further attempts from this now known bad IP/IP Space automatically. We can see that the WAF service offers the following protection to help protect against Credential Stuffing and other related attacks:

  • Whitelist a rule to allow known good IP’s
  • Blacklist a rule to block known bad IP’s
  • SQL Injection a rule to block common patterns in the URI, query string, or body of a request containing SQL Injection.
  • XSS Injection a rule to block common patterns in the URI, query string, or body of a request containing XSS.
  • HTTP Flood detects for a large number of requests from a particular IP address, such as a web-layer DDoS attack or a brute-force login attempt
  • Scanner & Probes this component parses application access logs searching for suspicious behavior, such as an abnormal amount of errors generated by an origin. It then blocks those suspicious source IP addresses for a customer-defined period of time.
  • IP Reputation Lists this component is the IP Lists Parser AWS Lambda function which checks third-party IP reputation lists hourly for new ranges to block.
  • Bad Bot this component automatically sets up a honeypot, which is a security mechanism intended to lure and deflect an attempted attack.
When Combining AWS Shield with AWS CloudFront and AWS WAF we get a comprehensive DDoS and Brute force Protection architecture, coupled with our application security controls and we now have a much more robust, dynamic and automated way to stop the various Brute force attacks, Password Spraying, Credential Stuffing and DDoS attacks.

Route 53: You can use Amazon Route 53 to configure DNS health checks to route traffic to healthy endpoints or to independently monitor the health of your application and its endpoints. Amazon Route 53 Traffic Flow makes it easy for you to manage traffic globally through a variety of routing types, including Latency Based Routing, Geo DNS, Geoproximity, and Weighted Round Robin—all of which can be combined with DNS Failover in order to enable a variety of low-latency, fault-tolerant architectures.

AWS Shield: Shield is a managed Distributed Denial of Service (DDoS) protection service that safeguards applications running on AWS. AWS Shield provides always-on detection and automatic inline mitigations that minimize application downtime and latency. There are two tiers of AWS Shield – Standard and Advanced.

AWS Cloud Front: Amazon CloudFront is a fast content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally with low latency, high transfer speeds, all within a developer-friendly environment. CloudFront is integrated with AWS – both physical locations that are directly connected to the AWS global infrastructure, as well as other AWS services. CloudFront works seamlessly with services including AWS Shield for DDoS mitigation, Amazon S3, Elastic Load Balancing or Amazon EC2 as origins for your applications, and Lambda@Edge to run custom code closer to customers’ users and to customize the user experience. Lastly, if you use AWS origins such as Amazon S3, Amazon EC2 or Elastic Load Balancing, you don’t pay for any data transferred between these services and CloudFront.

AWS WAF: AWS WAF is a web application firewall that helps protect your web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources. AWS WAF gives you control over which traffic to allow or block to your web applications by defining customisable web security rules. 

OWASP Top Ten 2019

Someone once said never commit to memory what you can write down. So here is the OWASP Top Ten for all those attending interviews and need to brush up what the current order of the OWASP Top Ten Application vulnerabilities. This is the current 2019 OWASP Top Ten.

(1) Injection 
Injection attacks happen when untrusted data is sent to a code interpreter through a form input or some other data submission to a web application. For example, an attacker could enter SQL database code into a form that expects a plaintext username. If that form input is not properly secured, this would result in that SQL code being executed. This is known as an SQL injection attack.

Injection attacks can be prevented by validating and/or sanitizing user-submitted data. (Validation means rejecting suspicious-looking data, while sanitization refers to cleaning up the suspicious-looking parts of the data.) In addition, a database admin can set controls to minimize the amount of information an injection attack can expose.

– LDPA
– SQL
– OS
– XSS
– Log

(2) Broken Authentication

Vulnerabilities in authentication (login) systems can give attackers access to user accounts and even the ability to compromise an entire system using an admin account. For example, an attacker can take a list containing thousands of known username/password combinations obtained during a data breach and use a script to try all those combinations on a login system to see if there are any that work.

Some strategies to mitigate authentication vulnerabilities are requiring 2-factor authentication (2FA) as well as limiting or delaying repeated login attempts using rate limiting.

  • Weak Password Policy
  • Weak Cryptography
  • User Access Controls

(3) Sensitive Data Exposure

If web applications don’t protect sensitive data such as financial information and passwords, attackers can gain access to that data and sellor utilize it for nefarious purposes. One popular method for stealing sensitive information is using a man-in-the-middle attack.

Data exposure risk can be minimized by encrypting all sensitive data as well as disabling the caching* of any sensitive information. Additionally, web application developers should take care to ensure that they are not unnecessarily storing any sensitive data.

*Caching is the practice of temporarily storing data for re-use. For example, web browsers will often cache webpages so that if a user revisits thosepages within a fixed time span, the browser does not have to fetch the pages from the web.

– Logs
– Source Code
– Headers
– API’s

(4) XML External Entity

This is an attack against a web application that parses XML* input. This input can reference an external entity, attempting to exploit a vulnerability in the parser. An ‘external entity’ in this context refers to a storage unit, such as a hard drive. An XML parser can be duped into sending data to an unauthorized external entity, which can pass sensitive data directly to an attacker.

The best ways to prevent XEE attacks are to have web applications accept a less complex type of data, such as JSON**, or at the very least to patch XML parsers and disable the use of external entities in an XML application.

*XML or Extensible Markup Language is a markup language intended to be both human-readable and machine-readable. Due to its complexity and security vulnerabilities, it is now being phased out of use in many web applications.

**JavaScript Object Notation (JSON) is a type of simple, human-readable notation often used to transmit data over the internet. Although it was originally created for JavaScript, JSON is language-agnostic and can be interpreted by many different programming languages.

  • Extending Schema
  • WSDL

(5) Broken Access Controls

Access control refers a system that controls access to information or functionality. Broken access controls allow attackers to bypass authorization and perform tasks as though they were privileged users such as administrators. For example a web application could allow a user to change which account they are logged in as simply by changing part of a url, without any other verification.

Access controls can be secured by ensuring that a web application uses authorization tokens* and sets tight controls on them.

Many services issue authorization tokens when users log in. Every privileged request that a user makes will require that the authorization token be present. This is a secure way to ensure that the user is who they say they are, without having to constantly enter their login credentials.

  • – Allows access to restricted resources

(6) Security Misconfiguration

Security misconfiguration is the most common vulnerability on the list, and is often the result of using default configurations or displaying excessively verbose errors. For instance, an application could show a user overly-descriptive errors which may reveal vulnerabilities in the application. This can be mitigated by removing any unused features in the code and ensuring that error messages are more general.

(7) XSS (cross site scripting)

Cross-site scripting vulnerabilities occur when web applications allow users to add custom code into a url path or onto a website that will be seen by other users. This vulnerability can be exploited to run malicious JavaScript code on a victim’s browser. For example, an attacker could send an email to a victim that appears to be from a trusted bank, with a link to that bank’s website. This link could have some malicious JavaScript code tagged onto the end of the url. If the bank’s site is not properly protected against cross-site scripting, then that malicious code will be run in the victim’s web browser when they click on the link.

Mitigation strategies for cross-site scripting include escaping untrusted HTTP requests as well as validating and/or sanitizing user-generated content. Using modern web development frameworks like ReactJS and Ruby on Rails also provides some built-in cross-site scripting protection.

(8) Insecure Deserialisation

This threat targets the many web applications which frequently serialize and deserialize data. Serialization means taking objects from the application code and converting them into a format that can be used for another purpose, such as storing the data to disk or streaming it. Deserialization is just the opposite: converting serialized data back into objects the application can use. Serialization is sort of like packing furniture away into boxes before a move, and deserialization is like unpacking the boxes and assembling the furniture after the move. An insecure deserialization attack is like having the movers tamper with the contents of the boxes before they are unpacked.

An insecure deserialization exploit is the result of deserializing data from untrusted sources, and can result in serious consequences like DDoS attacks and remote code execution attacks. While steps can be taken to try and catch attackers, such as monitoring deserialization and implementing type checks, the only sure way to protect against insecure deserialization attacks is to prohibit the deserialization of data from untrusted sources.

  • Spring < 3 is vulnerable

(9) Using Components With Known Vulnerabilities

Many modern web developers use components such as libraries and frameworks in their web applications. These components are pieces of software that help developers avoid redundant work and provide needed functionality; common example include front-end frameworks like React and smaller libraries that used to add share icons or a/b testing. Some attackers look for vulnerabilities in these components which they can then use to orchestrate attacks. Some of the more popular components are used on hundreds of thousands of websites; an attacker finding a security hole in one of these components could leave hundreds of thousands of sites vulnerable to exploit.

Component developers often offer security patches and updates to plug up known vulnerabilities, but web application developers don’t always have the patched or most-recent versions of components running on their applications. To minimize the risk of running components with known vulnerabilities, developers should remove unused components from their projects, as well as ensuring that they are receiving components from a trusted source and ensuring they are up to date.
Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.

  • NIST NVD
  • Shodan

(10) Insufficient Logging And Monitoring

Many web applications are not taking enough steps to detect data breaches. The average discovery time for a breach is around 200 days after it has happened. This gives attackers a lot of time to cause damage before there is any response. OWASP recommends that web developers should implement logging and monitoring as well as incident response plans to ensure that they are made aware of attacks on their applications.

The official OWASP PDF for the OWASP Top Ten 2017 can be found here.