Skip to content

Practical steps to help mitigate the risk of Zero-Day vulnerabilities

License

Notifications You must be signed in to change notification settings

jamesfed/0DayMitigations

Folders and files

NameName
Last commit message
Last commit date

Latest commit

ย 

History

17 Commits
ย 
ย 
ย 
ย 

Repository files navigation

0 Day Mitigations

Practical steps to help mitigate the risk of Zero-Day vulnerabilities. A presentation delivered to the College IT Conference 2024.

As a presentation on YouTube: https://youtu.be/0VlDxDBj6GE

By James Preston of ANSecurity.

Personal blog at myworldofit.net.

By the end of this presentation you will

  • Understand the common elements in some recent Zero-Day vulnerabilities.
  • Be familiar with 5 methods to help prevent attacks that start with a Zero-Day exploit.
  • Be able to take some immediate steps to help reduce the risk of impact from Zero-Day vulnerabilities.

image

What is a Zero-Day vulnerability

  • A vulnerability (perhaps under exploitation) in a system that is unknown to its owners, developers, or anyone capable of at least mitigating it if not full remediation.
  • Once made public the extra scrutiny of such a system normally leads to more vulnerability discoveries.
  • Multiple known and Zero-Day vulnerabilities are often chained together to perform an attack.
  • Rarely the biggest actual issue to worry about (looking at those who havenโ€™t setup MFA for everything yet!) but they do make great headlines.

Some Zero-Days that made it in the news

Log4Shell (Log4j)

https://logging.apache.org/log4j/2.x/security.html#CVE-2021-44228

  • 'JNDI lookup can be exploited to execute arbitrary code loaded from an LDAP server'
  • Existed unnoticed since 2013.
  • Privately disclosed.
  • Widely used, not always easy to determine if in use on 'appliances'.
  • Simple to exploit, lead to trivial remote code execution.

PaperCut

https://www.papercut.com/kb/Main/PO-1216-and-PO-1219

https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-131a

  • 'Our immediate advice is to upgrade your PaperCut Application Servers to one of the fixed versions listed below if you havenโ€™t already.'
  • Reported to Papercut by Trend Micro as already under exploitation.
  • Commonly Internet accessible.
  • Unauthenticated attacker could perform remote code execution on a PaperCut application server.

Ivanti Connect (and Policy) Secure

https://www.ivanti.com/blog/security-update-for-ivanti-connect-secure-and-ivanti-policy-secure-gateways

https://forums.ivanti.com/s/article/CVE-2023-46805-Authentication-Bypass-CVE-2024-21887-Command-Injection-for-Ivanti-Connect-Secure-and-Ivanti-Policy-Secure-Gateways

https://forums.ivanti.com/s/article/CVE-2024-21888-Privilege-Escalation-for-Ivanti-Connect-Secure-and-Ivanti-Policy-Secure

https://www.cisa.gov/news-events/cybersecurity-advisories/aa24-060b

  • 'If CVE-2024-21887 is used in conjunction with CVE-2023-46805, exploitation does not require authentication and enables a threat actor to craft malicious requests and execute arbitrary commands on the system.'
  • Under active exploitation at time of discovery.
    • Some researchers are now attributing to Chinese state actors.
    • Following discovery, the threat actors started using alternative exploits.
  • Threat actors bypassed authentication and delivered web shells to the appliance.
  • Evidence of credential capture.

Do I need to worry about this?

Why yes...

image

But perhaps not as much as you might think

2023 Data Breach Investigations Report

  • Using breached credentials is by far the most common method of access into an organisation.
  • But exploiting a vulnerability (zero-day or otherwise) still makes the top 3.

image

Buying time

Even if the Zero-Day is 'new' what comes after often isn't

Log4Shell (Log4j)

image

PaperCut

image

Ivanti Connect (and Policy) Secure

image

No single one of these practices will save you, think in layers!

  • Hide
    • Not the best option but it will buy you time.
    • Does your service appear on Shodan.io listed as that service?
  • Block access from and to known malicious
    • It's already known to be malicious - why wouldn't you block it?
  • Restrict opportunities for execution
    • Block file transfer, sandbox, block unrecognised file execution.
  • Strictly control network traffic
    • Why is that server reaching out to threatactor420.com?
  • Limit the overall impact/scope
    • Ok youโ€™ve been compromised, lets prevent lateral movement.

Not all threat actors are the same

  • Casual.
    • Do not take much to stop.
  • Determined - low skill.
    • Hiding probably won't work.
  • Determined - high skill.
    • Realistic probability will have access to an exploit before you've patched.
  • Nation State/Advanced persistent threat.
    • Highly likely will have access to an exploit before you've patched.

Hide

Hide - at a minimum

Do you really need to allow inbound connections to your student meals booking system from Afghanistan?

Block access from and to known malicious

  • Use the blocklists from your firewall vendor.
  • https://iplists.firehol.org/?ipset=firehol_level1 - really powerful and highly trustworthy.
    • Watch out for the RFC1918 addresses that are included!
  • Start and maintain information sharing partnerships.
  • Outbound URL filtering with deny access to known malicious categories.
    • Command and Control, Hacking, Malware, Newly Registered Domains, Parked, Phishing, Unclassified/Unknown.
  • Alert on attempts to access something malicious (even if just once a day).

image

Restrict opportunities for execution

  • Install anti-malware everywhere!
    • Yes on Linux as well ๐Ÿ˜‰.
  • Establish a baseline of what is permitted.
    • File hashes, file publishers, signed scripts, avoid filenames.
  • Prevent the execution of everything else.
  • Alert on attempts to execute something new (even if just once a day).

Resources:

For when you can't:

Strictly control network traffic

  • Based on
    • IP Address
    • Domain
    • URL
    • Application
    • Protocol/Port
  • Where possible also
    • User
    • Device health

All together now - decryption!

  • Without performing decryption (where possible) you simply don't have visibility into what's coming into and leaving your services.
    • Decryption works with TLS 1.3.
    • Inbound decryption works with practically everything you are likely to deploy.
    • Outbound decryption works on Linux and even some 'appliances'.
    • Grants anti-malware protections to machines that don't/can't have an agent installed on.

image

https://ubuntu.com/server/docs/security-trust-store

image

So let's download some web shells!

image

"Deny by default" egress traffic restrictions are a best practice to follow for any servers, not just those running impacted versions of Log4j instances.

https://www.mandiant.com/resources/blog/log4shell-recommendations

Limit the overall impact/scope

  • DMZs! Why did they ever go away?
  • Make use of client firewalls.
    • Deny access to management interfaces on the local subnet.
    • Permit management access from jump stations in a dedicated bastion network.
    • Bonus points - wrap network level access into that bastion network up in MFA!
  • User based policy.
  • Internal IDS/IPS โ€“ same level of strictness as inbound.
    • Normally internal is more lax.

Cloud Service drawio (1)

Ruckus Wireless Controller (SmartZone)

image

  • Can't install AV/EDR/UEBA agents.
  • No access to underlying Operating System detailed logging.
  • Although you can import CAs (for decryption) they are not supported for outbound connections.
  • A threat actors dream with lots of CPU and RAM to play with.

Strict outbound URL filtering

Download the URL logs, use a PivotTable within Excel (or even better some PowerShell ๐Ÿ˜‰) to process and produce a list of previously seen URLs.

image

Build out an allowed URL list, create policy to permit access to those addresses and block all others.

image

Perfect for blocking an outbound connection to a threat actors C2 service.

image

mmmmm network level anti-malware

Inbound decryption to the appliance from all networks (external and internal) allows the firewall full visibility into what's being uploaded.

So lets upload a web shell!

image

image

As the firewall sees the file go through it identifies it as spyware and is placed to block the connection while also alerting the administrator.

image

Linux web server

image

  • Can install agents, certificate authorities, pretty much anything on!
  • Full access to the underlying operating system.
  • May give the threat actor more room to move.

A series of firewall policies to

  • Block known malicious IP addresses.
  • Permit broad (not country restricted) inbound access to the main institution website.
  • A series of geo-blocks.
  • Permit all other inbound access to additional websites.
  • Geo-allow rule for VPN service.
    • Consider having a form or similar which staff can submit travel plans to for allowing broader inbound access when needed.
  • A rule to drop all other inbound traffic.

image

If traffic is moving from DMZ to 'internal' zones over encrypted channels then decrypt!

  • Don't let that small foothold spread.
  • Detect brute force attacks.
  • Detect further exploit attempts.
  • All of these would be very noisy indicators that something is going wrong.

image

'Universal' MFA

Our firewall policy permits access on all applications and ports to our web server.

image

So why is my SSH connection not going through?

image

Ah! A network level authentication profile.

image

Lets try something that can pop an authentication prompt. That's better!

image

MFA prompt time!

image

Prompt finished, and now into the services as expected.

image

When you get back to your institutions

  1. Consider how widely accessible your services need to be, consider geo-blocking and geo-allowing.
  2. Leverage trustworthy block lists, see how many hits you are getting.
  3. Install your anti-malware agents on all your servers - including Linux.
  4. Restrict outbound and internal traffic from services that permit inbound connections from the Internet to the minimum required for their function.
  5. Consider inbound/internal decryption to get the best value out of existing investments.

About

Practical steps to help mitigate the risk of Zero-Day vulnerabilities

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published