In this demo,
we're going to leverage the content rule option to protect against an exploit.
You may have wondered why Globomantics asked us to block Telnet and
give it such a high priority in the last module.
Well,
it turns out that Globomantics recently discovered that the FTP
software they were using has a backdoor vulnerability that's triggered
when an attacker connects to it through Telnet and adds a specific
string to the username at the login.
Once an attacker connects to the FTP service over
Telnet and enters this username, it opens port 6200,
which can then be accessed with root privileges.
Globomantics had incorrectly assumed that blocking
Telnet would stop this attack, and now they need a real fix.
They're working on fixing the issue and upgrading their FTP software.
But while they're testing and evaluating the impact,
they want you to configure a Snort rule that stops this backdoor attack.
You'll need to address the following security goals.
First, you need to reject the traffic attempting to exploit the VSFTPD backdoor.
You will also need to limit the impact on legitimate use of the FTP service.
Blocking the port outright is not an option.
Finally,
you need to verify that your rule prevents a backdoor from being
executed but still allows normal use of the FTP service.
Let's head over to our Snort server and get started.
Since our current Telnet rule only blocks traffic
destined for the default port 23,
our Snort server is still allowing connections over other ports.
This still enables attackers to exploit the vulnerable FTP service,
which authenticates over port 21.
Let's go ahead and restart Snort and then head over to our Kali
Linux machine to walk through the export in our lab and verify that
our current rules are not actively preventing it and see what we
have to do to block the traffic.
The backdoor present in this vulnerable service is fairly easy to exploit.
We start with a Telnet session to port 21.
And as you noticed, even though we're blocking Telnet,
if we just use port 21, we can still get through.
So far, our environment is not blocking this traffic.
This is actually a login prompt,
but because we're using Telnet instead of FTP to connect to it,
it's not giving us an actual prompt to enter username,
but the packet that we need to send it starts with user,
and then we specify a username.
The backdoor is triggered by adding a smiley face at the end of the username.
Let's just try typing user followed by smiley face.
Now it prompts for a password.
Anything in this field works since the user is not legitimate anyway.
The backdoor will already be triggered by our last command.
Let's just use pass for the password.
Now we escape using ^ and closed bracket, and then typing quit.
To connect to the backdoor, we simply Telnet to port 6200,
which is now open, and we're granted immediate access.
When we type the id command,
we can see that we're given root access to this device.
Let's check back in on our Snort server.
As we feared, no alerts were generated by this traffic.
Let's head to the rules file and write something to block this exploit.
Let's go ahead and stop Snort and then open up the rules file,
and we'll need to modify our rules to block this exploit.
Based on our security goals, we need to write a rule with a reject action.
Our protocol is TCP again, and our source network is the EXTERNAL_NET.
The destination is HOME_NET, but this time we need to inspect on port 21.
For a message,
I'm going to enter "Attempted VSFTPD backdoor." Now we need to
configure content to detect the payload.
The backdoor is triggered by adding a smiley face to the username.
So for this rule, I'm going to simply enter the smiley face here.
This time, the classtype is going to be attempted‑admin.
Our sid is 1,000,004.
And the revision value is 1.
Once we add the rule,
we can save this file and then restart Snort to see if it performs as we expect.
Let's head back to the Kali Linux machine and retry the exploit.
So we need to Telnet to port 21, and that's still connected.
So port 21 is still open.
We need to enter a user with a smiley face.
Now notice that it didn't ask us for a password,
but we know that should be our next step.
So let's go ahead and enter a password and then we'll just quit out of Telnet.
And then we'll try to access port 6200, and we are blocked.
Let's check Snort to see what was generated.
There are our notifications that a reset was sent to Kali when
it attempted to log in along with our classifications:
Attempted Administrator Privilege Gain.
The priority level is 1 by default.
We have almost satisfied our security goals,
but before we can call this a success,
we need to verify that legitimate FTP traffic is not impacted.
To do that,
we'll need to log into the FTP service using user
credentials and send a file to Metasploitable.
We'll start by creating a file we can upload called test.txt.
I'll just put test successful as the text of this file and save it.
Now we're ready to initiate an FTP connection with Metasploitable.
There's a user account on this machine with username,
user, and a password that's also user.
When I said this machine was vulnerable, I wasn't kidding.
But we can go ahead and use that for this test.
Once we're logged in, we can use the put command to send our test.txt file.
And we receive a notification that the transfer was complete.
To test our outbound connection,
let's see if we can download a file back to Kali Linux.
We can do that using the get command.
And our transfer back succeeded as well.
Let's check our Snort server for any additional alerts.
And we have no additional alerts.
So now we've satisfied all of our goals for this demo.
Before we move on with this module,
let's do a quick recap of what we covered in this demo.
We started by testing the exploit against our existing rules to
verify that our environment was indeed vulnerable.
While testing, we identified the particular string we wanted to detect.
Once we had that information,
we created a rule that used content to detect the user
command that would create a backdoor.
We used the reject command to have Snort send a reset back
to the attacking workstation and successfully prevented the
backdoor from being executed.
Our last step was to verify that all of our FTP services still
function correctly with our rule in place.