What is Attack Surface Management?

Photo by Possessed Photography on Unsplash

Attack surface management (ASM) is the continuous discovery, inventory, classification, prioritization, and security monitoring of external digital assets that contain, transmit, or process sensitive data. In short, it is everything outside of the firewall that attackers can and will discover as they research the threat landscape for vulnerable organizations. In 2018, Gartner urged security leaders to start reducing, monitoring and managing their attack surface as part of a holistic cybersecurity risk management program.

Today, attack surface management is a top priority for CIOs, CTOs, CISOs, and security teams. What is an Attack Surface?

Your attack surface is all the hardware, software, SaaS, and cloud assets accessible from the Internet that process or store your data. Think of it as the total number of attack vectors cybercriminals could use to manipulate a network or system to extract data. Your attack surface includes:

Known assets: Inventoried and managed assets such as your corporate website, servers, and the dependencies running on them.

Unknown assets: Shadow IT or orphaned IT infrastructure that stood outside the purview of your security teams, such as forgotten development websites or marketing sites.

Rogue assets: Malicious infrastructure spun up by threat actors such as malware, typosquatting domains, or a website or mobile app that impersonates your domain.

Vendors: Your attack surface doesn’t stop with your organization; third-party and fourth-party vendors introduce significant and fourth-party risks. Even small vendors can lead to large data breaches; look at the HVAC vendor that eventually led to Target’s exposure of credit card and personal data on more than 110 million consumers.

Millions of these assets appear on the Internet daily and are outside the scope of firewall and endpoint protection services. Other names include external attack surface and digital attack surface.

January 29, 2024 by Cyber Security 0

Authentication vs. Authorization: When To Use Which One

Photo by Markus Spiske on Unsplash

What’s the difference between authentication and authorization? Does it matter which you use — or do you need both? Are they the secure app’s chicken and egg problem? Let’s dive in.

What is authentication vs. authorization?

Generally, programmers have subconscious reasoning for applying security and access controls to their applications. If questioned, they’ll describe a simple set of AUTH codes that protect the app. Are you using authentication, authorization, or both? What’s the difference? Do these get mixed up because they both begin with “AUTH” and are sometimes referred to in the same way as short-hand? Maybe some of this mix comes from each seeming to allow you to address the other’s concerns if you stretch it a bit.

But authentication and authorization are two separate things. Even if they go hand-in-hand for many applications, it’s essential to know the difference. Once you fully grasp this, it’s clearer how to implement each securely and effectively.

Authentication vs. authorization example

I will use the application and actor of the terms to discuss authentication and authorization. My background is in web applications, so I think of people using my web application as visitors. But actor refers to any human or computer accessing your application in any manner. The term application means any piece of software. So we could be referring to a website visitor, a desktop application user, or a consumer querying your API.

Authentication refers to identifying the actor using your application. That’s it. All authentication is responsible for is saying, “I can identify this actor” or “this actor is unidentified.” The meaning and description of authentication are simple — that doesn’t mean the implementation is. For example, you might have a username and password, tokens, cookies, JWTs, or other ways to authenticate a user. But, after the process is complete, we either can identify the actor or we can’t.

Authorization refers to the permission to accomplish a task in your application. Tasks can be simple, like listing resources or seeing the details of an object. Advanced ones may create, update, or move data through a complex business workflow. Now, this is important: authorization does not require an authenticated actor. It just so happens that most authorization decisions are based on the specific permissions of an identified actor, but that isn’t a requirement. We’ll touch on this more later. But authorization is the mechanism that answers the question: “does this actor have permission to do this action.” Both authentication and authorization are necessary.

Let me share a real-world example.

A client had requested that their web application list the resources for any visitor. Multiple pages had this listing shown and an API. They then asked that if visitors click through to the detail page or request details over the API, the visitor must be authenticated.

Now, check for authenticated users at the top of the code that retrieves details. The other code needs no checks because it doesn’t matter if they’re logged in. (That is to say, whether the user is authenticated or not, either situation allows access.) This application has only two states: the user is authenticated or not.

Only two states are rarely the case. Furthermore, there’s hardly ever a time that an application matures without expanding its access controls beyond these two states. So, with this knowledge in place, I decided to implement authorization on all endpoints.

They implemented an authorization layer that simply returned valid on the endpoints that displayed lists of resources (including the API). A simple class reused on each endpoint always authorized access to the list of resources. Then, on the endpoint with the details, I created another class that returned true only when I had the visitor’s identity.

Then it happened: business requirements changed! About a week after the web page was launched, the business decided they wanted the lists of resources to be locked behind authentication. Guess what? Because I had used authentication correctly, to begin with, it was super simple. Next, I modified the authorization class to list resources to check for an identified visitor. Done! I imagine a scenario where lists require an authenticated user, but details need a user who has a subscription. If that happens, I’m ready! I’m prepared for future changes in the business, too.

What is the point?

Authentication determines an identity of an actor. Authorization decides if an actor has permission to take action. Your application, no matter how simple, should use both hand-in-hand. Authenticate actors when you must. Authorize actors, regardless of their identity, for every action.

January 19, 2024 by Application Security 0

What are Sock Puppets in OSINT

Sock puppets, or research accounts, are fictitious online identities that conceal an OSINT investigator’s true identity. They are created to gain access to information that requires an account to access. However, it is essential to note that creating fake accounts goes against the Terms of Service of some websites. Therefore, the users are responsible for reading and understanding the Terms of Service of their websites. Although creating sock puppets is not usually illegal, it is equally important to check with your organization’s policies to ensure you have permission to create and use them.

Purpose of Sock Puppets

Sock puppets are created to keep OSINT research separate from personal life. This ensures that OSINT investigators maintain anonymity and practice good Operational Security (OPSEC). It is crucial to emphasize the importance of separating an OSINT investigator’s real identity from their research accounts.

Some social media platforms, such as Facebook, may expose your identity to a target being investigated through friend recommendations. Additionally, if you use your account to conduct online research, you may accidentally like a post or send a friend request to your target. To avoid these risks, it would help if you created sock puppets before starting your research. To put it in perspective, imagine yourself as a police officer conducting surveillance using your vehicle, which would reveal your identity. You would not do that, right? Similarly, using your personal social media accounts to research a subject could be better because it can expose your real identity.

What are the Sock Puppet Functions?

When you are passive, it means that you do not interact with a particular target. However, your profile might still show up in the “suggested friends” or “people to follow” results, so it is advisable to try blending in a little. One way to do this is by choosing a name that fits well with your target group.

Engaging with your target in some way, such as by adding them as friends on Facebook, is essential to conducting active research. Blending in with the target group during active research is even more crucial. If you plan on engaging with your target, creating a few accounts on different platforms is recommended to make it appear like you are a natural person.

January 4, 2024 by Cyber Security 0

What is OpenID Connect?

OpenID Connect extends the OAuth protocol to provide a dedicated identity and authentication layer that sits on top of the basic OAuth implementation. It adds some simple functionality that enables better support for the authentication use case of OAuth.

OAuth was not initially designed with authentication in mind; it was intended to be a means of delegating authorizations for specific resources between applications. However, many websites began customizing OAuth for use as an authentication mechanism. To achieve this, they typically requested read access to some basic user data and, if they were granted this access, assumed that the user authenticated themselves on the side of the OAuth provider.

These plain OAuth authentication mechanisms were far from ideal. For a start, the client application had no way of knowing when, where, or how the user was authenticated. As each of these implementations was a custom workaround of sorts, there was also no standard way of requesting user data for this purpose. To support OAuth properly, client applications would have to configure separate OAuth mechanisms for each provider, each with different endpoints, unique sets of scopes, and so on.

OpenID Connect solves a lot of these problems by adding standardized, identity-related features to make authentication via OAuth work in a more reliable and uniform way.

December 15, 2023 by Application Security 0

HTTP Verb Tampering

Photo by Christopher Gower on Unsplash

HTTP is the protocol that lets applications respond to requests and retrieve data. An HTTP verb is one of several actions the application can use when querying the server. Standard HTTP verbs include:

  • GET: retrieves data from specified source
  • HEAD: requests preview of specified resource
  • POST: submits entity to specified resource, such as editing data
  • PUT: transmits new data to the specified resource replacing the old information
  • DELETE: deletes the specified resource entirely

Most web applications use HTTP verbs to authenticate users and manage access privileges. However, malicious actors can bypass authentication and access controls to protect privileged information.

December 2, 2023 by Application Security 0

Attack Surface: How can I reduce the attack surface?

Photo by Azamat E on Unsplash

There are various ways to decrease the attack surface. Let’s take a look at some of the more widely used techniques.

The digital side

The easiest target to attack is the digital attack surface. Let’s explore effective strategies to reduce the attack surface.

Less code, less software attack surface

When you reduce the code you’re running in your desktop, server, or cloud instance, you’re reducing the possibilities for entry points to be discovered and later exploited. Turn off, disable, or remove unnecessary software features, and simplify your code. Fewer codes also mean fewer software bugs and vulnerabilities; at the end of the day, that equals fewer security risks overall.

Remove unnecessary OS software and services.

Cleaning the OS includes removing unnecessary functions, applications, and system tools. Do you need a printing service running if you don’t use a printer? What about that MYSQL server running on the 3306 port? Do you need it if you don’t host any databases? And is Adobe Suite required if you don’t work with any PDF files? Install only the strictly necessary applications for your employees’ daily work, and turn off all unused protocols or services. The same advice goes for servers.

Scan your network ports.

Scanning the open ports in your public IP addresses is often the first thing attackers do when performing infosec reconnaissance on any target.

Luckily, there are many ways for you to stay one step ahead of your attackers. And your best bet is to begin auditing your network ports before they do. In our previous article about most scanned ports, we showed a quick way to get famous using the almighty Nmap command.

While using the Nmap top-ports option helps audit your port exposure, this activity can be done using different port scanners such as Unicornscan, Angry IP Scanner, or Netcat.

Analyze your SSL certificates.

People often see SSL certificates as a way to prove a website is secure, but that can be a big mistake.

How hardened are your SSL certificates? Are you keeping your SSL chains complete and well-secured? Are you using strong cipher suites? These are fundamental questions that all developers, system administrators, and technical managers should ask themselves more often. Additional information can be found in our article: Is SSL a real sign of security?

But SSL security doesn’t end up in your hardening, chain, and overall security score. You also need to consider the data you’re exposing to the public.

Have you ever thought about your SSL certificate expiration and validity? Your attack surface includes all your SSL certificates—valid, active, and expired ones.

Of course, the bad guys can explore such public information. So, remember that while SSL certificates are suitable for encrypting your information…not having a thorough audit or control over them can lead to some of your worst nightmares.

Segmentation your network

Keeping all your assets within a single network is often one of the biggest mistakes you can make. Splitting and segmenting your network is one of the easiest ways to reduce your attack surface.

This will help increase your network barriers and, at the same time, help you gain better and more effective server or desktop controls over all machines connected to the network.

Audit your software, network, and traffic.

Auditing your software is one of the oldest known tactics for reducing your attack surface. This will help detect misconfigurations and outdated software, test the security system, and keep users’ activity under control.

Analyzing the network, protocols, OS services, and current and past traffic over the network is a great way to detect factors that could expose your attack surface even more.

Log analysis plays a critical role in reducing your attack surface. Also, running scheduled audits on overlooked services (such as the DNS service) can help keep your exposure under control, as we covered in our previous article: Why should I perform a DNS audit?

The human side

The physical attack surface involves our world, making its most significant component none other than the human being.

As we’ve said before, company staff is often one of the weakest links in the cybersecurity chain of your online business.

Let’s see what can be done to avoid exposing your physical attack surface as much as possible:

Train all your employees to avoid getting tricked by social engineering calls or phishing emails. These are two of the most common ways to sabotage networks, routers, and other physical hardware, most of the time allowed by your human capital. 

While nothing can prevent rogue employees from stealing sensitive information about your company (including email or user logins), human resource and hiring departments do have psychological tests in hand for screening applicants. These tests may reveal the true nature (including many unconscious aspects) of the people in line to work with your team.

Teaching your employees correct policies concerning using unknown and unauthorized devices in the office can also help reduce baiting attacks. 

There are more social engineering techniques we’ll explore in future posts. Fortunately, they all rely on following company-based security practices and constant employee education.

November 15, 2023 by Cyber Security 0

Attack Surface: What is an attack surface?

Photo by Bernd 📷 Dittrich on Unsplash

What does “attack surface” mean? I see the attack surface as the entire network and software environment exposed to remote or local attacks. For others, it’s the sum of compromised points—although that’s not the attack surface, but the attack vectors.

An attack surface refers to all the ways attackers can exploit your apps. This includes software, operating systems, network services and protocols, domain names, and SSL certificates.

A classic example to help illustrate the concept of attack surface is your business’s physical office. What’s the attack surface of your local office?

The answer is simple: doors, windows, safe boxes, etc. What about your home? Even simpler: front and back doors, windows, garage doors, climbable trees or tables, etc.

The difference between detecting a breach in your home and a violation in your company’s online attack surface can be characterized by the size of the area and its inclusion of multiple complex regions to explore.

You’d clearly notice if someone had broken a window or forced open the door in your home. It’s even easier to have a home alarm system that notifies you immediately.

However, due to the extensive network, software, protocols, and services running within an online company, detecting what part of the attack surface was the origin of the breach or intrusion can be tricky, even with a solid IDS in place, application firewalls, and notification alerts. Most of the time, it may pass unnoticed.

November 7, 2023 by Cyber Security 0

Hardening Your HTTP Security Headers Part 2

Photo by Maik Jonietz on Unsplash

4. X-Frame-Options

The x-frame-options header provides click jacking protection by not allowing iframes to load on your website. It is supported by IE 8+, Chrome 4.1+, Firefox 3.6.9+, Opera 10.5+, Safari 4+. Here is an example of what the header looks like:

x-frame-options: SAMEORIGIN

Enable in Nginx

add_header x-frame-options "SAMEORIGIN" always;

Enable in Apache

header always set x-frame-options "SAMEORIGIN"

5. Expect-CT

The expect-ct header prevents miss used certificates from being used by allowing websites to report and optionally enforce Certificate Transparency requirements. When this header is enabled the website is requesting the browser to verify whether or not the certificate appears in the public CT logs. Here is an example of what the header looks like:

expect-ct: max-age=604800, enforce, report-uri=”https://www.example.com/report”

Enable in Nginx

add_header expect-ct "max-age=604800, enforce, report-uri='https://www.example.com/report' always;

Enable in Apache

header always set expect-ct "max-age=604800, enforce, report-uri="https://www.example.com/report"

6. X-Content-Type-Options

The x-content-type-options header prevents Internet Explorer and Google Chrome from sniffing a response away from the declared content-type. This helps reduce the danger of drive-by downloads and helps treat the content the right way. Here is an example of what the header looks like:

x-content-type-options: nosniff

Enable in Nginx

add_header x-content-type-options "nosniff" always;

Enable in Apache

header always set x-content-type-options "nosniff"

7. Feature-Policy

The feature-policy header grants the ability to allow or deny browser features, whether in its own frame or content within an inline frame element (<iframe>). Here is an example of what the header looks like:

feature-policy: autoplay 'none'; camera 'none'

Enable in Nginx

add_header feature-policy "autoplay 'none'; camera 'none'" always;

Enable in Apache

header always set feature-policy "autoplay 'none'; camera 'none'"

October 29, 2023 by Application Security 0

Hardening Your HTTP Security Headers Part 1

Photo by Markus Spiske on Unsplash

There are a lot of things to consider when securing your website or web application, but a good place to start is to explore your HTTP security headers and ensure you are keeping up with best practices. In many cases, they are very easy to implement and only require a slight web server configuration change. HTTP security headers provide yet another layer of security by helping to mitigate attacks and security vulnerabilities. In this post, we will explore some of them to help you better understand their purpose and how to implement them.

What Are HTTP Security Headers?

Whenever a browser requests a page from a web server, the server responds with the content along with HTTP response headers. Some of these headers contain content metadata such as the content-encoding, cache-control, status error codes, etc.

Along with these are also HTTP security headers that tell your browser how to behave when handling your website’s content. For example, by using the strict-transport-security you can force the browser to communicate solely over HTTPS. There are six different HTTP security headers that we will explore below (in no particular order) that you should be aware of and we recommend implementing if possible.

1. Content Security Policy

The content-security-policy the header provides an additional layer of security. This policy helps prevent attacks such as Cross-Site Scripting (XSS) and other code injection attacks by defining content sources that are approved and thus allowing the browser to load them.

All major browsers currently offer full or partial support for content security policy. And it won’t break the delivery of the content if it does happen to be delivered to an older browser, it will simply not be executed.

There are many directives which you can use with content security policy. This example below allows scripts from both the current domain (defined by ‘self’) as well as google-analytics.com.

content-security-policy: script-src ‘self’ https://www.google-analytics.com

To explore all of the directives, and to see implementation on Nginx and Apache, make sure to check out our in-depth post on Content Security Policy.

2. X-XSS-Protection

The x-xss-protection the header is designed to enable the cross-site scripting (XSS) filter built into modern web browsers. This is usually enabled by default, but using it will enforce it. It is supported by Internet Explorer 8+, Chrome, and Safari. Here is an example of what the header looks like:

x-xss-protection: 1; mode=block

Enable in Nginx

add_header x-xss-protection “1; mode=block” always;

Enable in Apache

header always set x-xss-protection “1; mode=block”

3. HTTP Strict Transport Security (HSTS)

The strict-transport-security header is a security enhancement that restricts web browsers to access web servers solely over HTTPS. This ensures the connection cannot be established through an insecure HTTP connection which could be susceptible to attacks.

All major modern browsers currently support HTTP strict transport security except for Opera Mini and versions previous of Internet Explorer.

Here is an example of what the header looks like: You can include the max-age, subdomains, and preload.

strict-transport-security: max-age=31536000; includeSubDomains; preload

To read more about this header and see implementation on Nginx and Apache, make sure to check out our in-depth post on HTTP Strict Transport Security.

October 15, 2023 by Application Security 0

What is DNS Spoofing?

Photo by Lars Kienle on Unsplash

DNS spoofing, or DNS cache poisoning, is a phishing and cyber attack where false Domain Name System (DNS) information is introduced into a DNS resolver’s cache. This causes DNS queries to return an incorrect response, which commonly redirects users from a legitimate website to a malicious website designed to steal sensitive information or install malware.

There are several reasons why DNS spoofing is possible, but the principal problem is DNS was built in the 1980s when the Internet was much smaller, and security was not a primary concern. There is no in-built way for DNS resolvers to verify the validity of the data they store, and incorrect DNS information can remain until the time to live (TTL) expires or is manually updated.

How Do Attackers Poison DNS Caches?

DNS poisoning or DNS spoofing attacks work by impersonating DNS nameservers, making a request to a DNS resolver, and then forging the reply when the DNS resolver queries a nameserver. This is possible because DNS uses UDP, an unencrypted protocol, which makes it easy to intercept traffic with spoofing. DNS servers do not validate the IP addresses they are directing traffic to.

There are two common methods for poisoning DNS caches:

Man in the middle attack: The interception of communication between users and a DNS server to route users to a different or malicious IP address. In this situation, the attacker sits between the computer’s stub resolver and the recursive resolver, sending back a fake DNS result.

DNS server compromise: This type of attack occurs when an attacker gains direct access to the DNS server of a domain, generally through spear phishing or whaling, and updates the DNS entries to point to a malicious website. This type of attack is also known as DNS hijacking.

This works because, unlike TCP, which relies on both communicating parties performing a ‘handshake’ to initiate communication and verify the identity of devices, DNS requests and responses rely on UDP or User Datagram Protocol. With UDP, there is no guarantee that a connection is open, that the recipient is ready to receive, or that the sender is who they say they are. This leaves UDP communications vulnerable to MITM attacks; an attacker can send a message via UDP, pretending that it is a legitimate nameserver by forging header data. If the receiving DNS resolver accepts the fake response and caches, which can happen as there is no way to verify if the information is accurate and comes from a legitimate source. With that said, DNS spoofing attacks are not easy to pull off as the DNS resolver queries the authoritative nameserver giving attackers only a few milliseconds to fake the response before the real response arrives.

When are DNS Spoofing Attacks Successful?

For a DNS spoofing attack to be successful, attackers either need to know or guess:

Which DNS queries are not cached by the targeted DNS resolver so that the resolver will query the authoritative name server what port the DNS resolver uses, which was easy in the past but has since become much more difficult as DNS resolvers rotate their open ports to mitigate DNS spoofing The request ID number which authoritative nameserver the DNS resolver will query.

Furthermore, these malicious websites are often used to install computer worms, ransomware, and spyware on the user’s computer, giving the perpetrator long-term access.

How to Mitigate DNS Spoofing

The Domain Name System Security Extensions (DNSSEC or DNS Security Extensions) is a set of Internet Engineering Task Force (IETF) specifications designed to secure certain kinds of information the DNS provides. DNSSEC provides DNS resolvers origin authentication of DNS data, authenticated denial of existence, and data integrity but not availability or confidentiality.

Like TLS/SSL, DNSSEC uses public-key cryptography to verify and authenticate DNS data.

When DNSSEC is used, each answer to a DNS request contains an RRSIG DNS record and the requested record type. The RRSIG record is a digital signature of the requested DNS data. The digital signature is verified by locating the correct public key in the DNSKEY. The NSEC and NSEC3 records are used to provide cryptographic evidence of the non-existence of any request. This is also known as authenticated denial of existence.

The delegation signer (DS) is used to authenticate DNSKEYs by using a chain of trust. NSEC and NSEC3 also serve the purpose of providing robust resistance against spoofing.

The chain of trust starts with a set of verified public keys for the DNS root zone, the trusted third party. Domain owners generate their own public key/private key pair and upload them using their domain-name registrar’s DNS control panel, which pushes the keys via secDNS to the zone operator (for example, Verisign for the com zone), who signs and publishes them in the DNS.

This prevents resolvers from caching forged or manipulated DNS data and prevents cache poisoning.

In short, DNSSEC provides two security features to DNS:

Data origin authentication: This allows a resolver to cryptographically verify data from the zone requested.Data integrity protection: This allows a resolver to know that the data hasn’t been modified in transit and was originally signed by the zone owner’s private key.

These two security features all any recursive resolver to look up data in the zone and retrieve the zone’s public key, which is then used to validate the authenticity of provided DNS data. Resolvers then confirm the digital signature received matches what they expect and return it to the end-user. If the signature is not valid, the resolver assumes a cyber attack, discards the data, and returns an error.

While the primary concern of DNSSEC is to prevent the cyber threat of DNS spoofing, resulting in users being directed to the wrong place, DNSSEC provides the additional benefit of protecting text records (TXT) and mail records (MX). DNSSEC has also been used to bootstrap other cyber security systems that publish cryptographic certificates stored in DNS, such as Certificate records, SSH fingerprints, IPSec public keys, and TLS Trust Anchors.

That said, DNSSEC, unlike SSL certificates, does not provide confidentiality of data. DNSSEC responses are authenticated but not encrypted. Nor does DNSSEC protect against cyber attacks like distributed denial of service attacks (DDoS attacks).

DNSSEC also has several potential downsides, including:

Lack of data confidentiality: While DNSSEC authenticates, it does. not encode DNS responses. This means that perpetrators can still listen in on traffic and use this data for more sophisticated attacks; this is why SSL certificates are such an important part of Internet security. Deployment complexity: DNSSEC is easily misconfigured, which can cause servers to lose their security benefits or even deny access to the website altogether. No widespread adoption: While DNSSEC was published in 2005, it has not yet become mainstream, leaving any DNS records vulnerable to attacks.

Beyond DNSSEC, there are other ways you can prevent DNS spoofing:

Active monitoring: DNS data should be continuously monitored for changes, such as the appearance of a new external host, that could indicate compromise.

Patching: Like anything, DNS servers and software can be vulnerable to exploits and zero-day vulnerabilities. Ensure whoever is hosting your DNS records is meticulous about vulnerability management and attack surface management.

DNS updates Newer versions of DNS use port randomization and cryptographically secure transaction IDs to prevent DNS attackers and ensure your servers are up-to-date.

Password policies: Ensure you use strong passwords and, ideally, two-factor authentication for the account that manages your DNS records. And don’t forget about changing default passwords on network equipment, such as routers, which can put every device and user in danger if compromised. Read our guides on password security and network security for more information.

Invest in cybersecurity awareness training: Remember that many DNS spoofing attacks are either the result of or aim to initiate some phishing attack. Educate your staff about what to look for in phishing campaigns.

September 29, 2023 by Network Security 0

Recent Comments

No comments to show.