Month: May 2024

InfoSec

Understanding Offensive Security

A robot arm holding a robotic sword over a laptop representing Offensive SecurityAt first blush, Offensive Security can seem like an oxymoron or a misnomer. Are we saying that the best defense is a good offense? Not really. When people say that in the traditional sense, they usually mean that by attacking, you don’t give your opponent a chance to attack you, therefore there is less for you to defend against. That’s not what we’re doing here. We are not out attacking the “bad guys” in an attempt to tie up their resources to keep them from attacking us. What we’re really talking about is attacking ourselves internally or through a third party vendor.

Offensive security refers to proactive measures taken to identify, assess, and mitigate vulnerabilities within a system before malicious hackers can exploit them. Unlike defensive security, which focuses on protection and prevention, offensive security involves simulating attacks to uncover weaknesses and bolster defenses. This approach is also known as ethical hacking or penetration testing.

The hacking is “ethical”, because the people performing the exercise have permission to do it and share all of their results with the target and don’t keep, use, or share any vulnerabilities or data they might uncover with the outside world. Penetration testing (pen testing) is a process that involves simulating cyberattacks to identify vulnerabilities in a system, network, or application. Ethical hackers use the same techniques as malicious actors to find and fix security flaws.

Taking this up a notch is something called Red Teaming. Red teaming is an advanced form of penetration testing where a group of security professionals, known as the red team, emulate real-world cyberattacks over an extended period. Their goal is to test the organization’s detection and response capabilities. These groups perform vulnerability assessments, which involves systematically examining systems for vulnerabilities, typically using automated tools. While less thorough than penetration testing, vulnerability assessments provide a broad overview of potential security issues. In addition, offensive security professionals will often use social engineering attacks to exploit human psychology rather than technical vulnerabilities. Offensive security professionals also often conduct phishing simulations and other tactics to test an organization’s security awareness.

So that explains a little of what these teams do, but let’s consider a little more of the why.

  • Proactive Defense: Offensive security allows organizations to identify and address vulnerabilities before they can be exploited by attackers. By staying one step ahead, companies can significantly reduce the risk of data breaches and other security incidents.
  • Improving Security Posture: Regular penetration testing and vulnerability assessments provide actionable insights that help organizations strengthen their security posture. This ongoing process ensures that defenses evolve in response to emerging threats.
  • Compliance and Regulatory Requirements: Many industries have strict compliance and regulatory standards that mandate regular security testing. Offensive security practices help organizations meet these requirements and avoid potential fines and penalties. I can tell you that in several audits and compliance engagements that I’ve had recently that they’ve wanted evidence that we regularly conduct offensive security operations against our company.
  • Incident Response Preparedness: Red teaming exercises and other offensive security activities help organizations test and refine their incident response plans. This ensures that in the event of a real attack, the organization is prepared to respond quickly and effectively.

Ethical Hackers (or White Hat Hackers) are the backbone of offensive security. We’re talking about individuals who have the skillset to “be the bad guys” (Black Hat Hackers), but instead earn a living helping others be prepared. The important thing, though, is that you don’t have to be born a hacker, spend time in the seedy underbelly of the internet, nor wear all black to go into this field. There is a lot of reputable training available and some respected certifications that you can get that can help your employment chances in the field (CEH and OSCP to name two).

If you’re interested, give it a shot. There is almost no barrier to entry. Sites like TryHackMe and HackTheBox have free tiers and there are tons of YouTube channels offering training and walkthroughs and advice. I plan on spending a fair amount of time in future posts talking about various security topics – often from the Offensive Security angle – and working through some of the problems available to us on places like TryHackMe, HackTheBox, and VulnHub so that I can also give back a little and add one more resource to the pile in gratitude to what has been given to me, so stay tuned for that.

InfoSec

Locking Down Mercury

A composite image of Mercury behind cartoon jail bars, both images from PixabayIn my last post, I did a walkthrough for the VulnHub box The Planets: Mercury. This box was conceived and implemented to be low hanging fruit for people who enjoy Capture the Flag (CTF) exercises. The advice for much of what we used to gain our initial foothold are pretty basic. The advice should be pretty familiar to anyone who takes security hygiene seriously and certainly anyone who is running a production web server. Additionally, Injection (SQL and otherwise) is on the OWASP Top 10 consistently. It should be one of the things that should be checked and remediated early, but often isn’t. Nevertheless, we weren’t splitting atoms to find it or to suggest how to fix it. Here are the basic “Don’ts” from the Mercury CTF:

  • Don’t leave default error pages in place
  • Don’t leave public “to do” lists
  • Don’t construct SQL Queries using blind concatenation
  • Don’t leave text files with passwords in plain text (or any encoding) on the server

But none of those are how we gained root on the box. We took advantage of a misconfiguration on the server that was intended to let the user read from a log file. The Mercury box wanted to allow the user to read records from the /var/log/syslog file. Normally, that file requires elevated permissions to read it. The Admins on this example box chose to create a script that reads the last 10 lines from the file and then gave the user permissions to run sudo on this script. Unfortunately, we were able to use symlinks to cause that script to allow us to ultimately open a root shell instead.

But what could the Admins have done differently? The best solution here is probably using Access Control Lists (acls). Linux file systems for a few generations have supported these by default. To work with them, we can just install a package and then configure the permissions.

Take a look at these simple commands that could have prevented this avenue of privesc on Mercury.

# Install the acl package
# In Debian-based systems
sudo apt-get install acl
# In RedHat-based systems
sudo yum install acl

# See if your file systems supports ACLs
grep acl /etc/mke2fs.conf

# If they do, you will see acl in the default mount options
default_mntopts = acl,user_xattr

# If not, you should be able to run this command to set it up
# This has not been tested by me, as every Linux box I could find already had the permissions
sudo mount -o remount,acl /

# Looking at the ACL on the file to start, we see that I (user) have read and write
# the adm group has read, and everyone else has no permissions.
getfacl /var/log/syslog

# Output
getfacl: Removing leading '/' from absolute path names
# file: var/log/syslog
# owner: syslog
# group: adm
user::rw-
group::r--
other::---

# Now I'm going to configure a user to have read permissions using
# setfacl which was added when we installed the acl package
sudo setfacl -m u:exampleuser:r /var/log/syslog

# Let's check again
getfacl /var/log/syslog

# Output
getfacl: Removing leading '/' from absolute path names
# file: var/log/syslog
# owner: syslog
# group: adm
user::rw-
user:exampleuser:r--
group::r--
mask::r--
other::---

# You notice that now we have another user row in the output, saying
# that example user has read permissions on the file

That’s it! It took me a total of less than two minutes and this avenue of escalation could have been prevented. This is a good example of how thinking like an attacker can help you be a better Administrator if you think about how every change you make to a system could be exploited and then think about a better way. When in doubt, look for guidance, don’t get “creative”.