Northern Kentucky University



CIT 481: Cybersecurity CapstoneAssignment #7: SignaturesDue October 23rd in className: _____________________The objective of this assignment is to learn how to use IDS alerts to understand what is happening on the networks. Signature-based IDS like snort and suricata examine network packets for both metadata (IP address, port, etc.) and content (a sequence of bytes found in a packet). Signatures are provided to the IDS in the form of rulesHere is the rule that triggers on web requests for ip any any -> any any (msg:"GPL ATTACK_RESPONSE id check returned root"; content:"uid=0|28|root|29|"; fast_pattern:only; classtype:bad-unknown; sid:2100498; rev:8;)The string “any any” on the left of the arrow indicates that the rule should trigger for any source IP address or port, while the same string on the right of the arrow indicates that the rule should trigger for any destination IP address or port. The string provided after content: provides the pattern of bytes to be matched, which includes the string “uid=0”, the hex byte 28, the string “root”, and the hex byte “29”.To translate bytes in the range 00-7f to ASCII (80-ff are non-ASCII binary bytes), we can use the xxd command as follows, prepending the hex byte with the string “0x” in the echo command, then piping the result to xxd and using a final echo command to print a newline. In this case, we see that 0x28 is the hexadecimal representation of the left parenthesis character in ASCII.$ echo “0x28” | xxd –r && echo( The string after msg: is the text string to be printed when this rule is triggered. The string fast_pattern:only indicates an optimization to make the rule run faster. The string after classtype: provides a classification for the type of attack identified by the signature. The strings after sid: and rev: are the signature identifier and revision number respectively. The snort manual provides details on how to read and write snort rules. Chapter 9 of Applied Network Security Monitoring discusses snort rules in extensive detail.On SecurityOnion, IDS rules can be found under /etc/nsm/rules. In this directory, you should find a large file downloaded.rules whose last modification timestamp is today. Like antivirus software, IDS signatures need to be updated regularly. SecurityOnion uses a tool called pulledpork to update its rules daily.This lab comes with captured packets in PCAP or PCAPNG format. To obtain IDS alerts, these packets must be replayed on the network as follows. On the Security Onion VM, start Squert to look for alerts. On the Kali VM, open a terminal window, then replay the packets with the following command as root:tcpreplay -i eth0 -t file.pcapngwhere file.pcapng contains the packets to be replayed. Alerts related to the traffic should appear in the Squert display within a minute. Click on the replay icon in the top row of the Squert user interface to update the alerts if needed.If you encounter problems, it can be worth repeating the replay command without the –t flag, which tells tcpreplay to replay the packets as quickly as possible.Note that replaying packets is safe to do and will not recreate the exploit on your network. Even if IP addresses and active services are identical, the TCP connections specified in the replayed packets will not recur due to differing initial TCP sequence numbers. There is a command tcpliveplay that can recreate exploits in some circumstances, but tcpreplay cannot.1: Testing the IDSOn SecurityOnion, open Squert and a terminal window. To verify that Squert is working correctly, run the following command in the terminal window:$ wget you see a red icon by the reload icon in the top of the Squert window, click on the reload icon to update the list of alerts. The following alert should be displayedGPL ATTACK_RESPONSE id check returned rootIf this alert is not displayed, there is a problem with the configuration of Security Onion. Repeat the setup as described in the setup assignment to fix the problem.Click on the alert to bring up a popup window, then double click on the word SIGNATURE in the popup. This will limit the Squert display to show only alerts matching this signature. When Squert is in this mode, the second line from the top of the display will show the string FILTERED BY OBJECT: YES. Click on the red button on the far left of the line displaying the alert. It appears under the word QUEUE. This will cause Squert to display the full text of the snort alert, along with a list of events of this type that Squert has recorded.2: Backdoor ExploitEnsure that Squert is open on the Security Onion VM, then login to your Kali VM and replay the captured packets for this part of the assignment with the following command as root:tcpreplay -i eth0 -t backdoor.pcapngIf you see a red icon by the reload icon in the top of the Squert window, click on the reload icon to update the list of alerts. One or more alerts should be displayed. As an alternative to using tcpreplay and a GUI like Squert, you can run snort on the command line with a pcap file as input. First, create a directory to store snort’s output files, then run the following commands, moving the pcap file into the newly created directory before running the snort command.mkdir snortcd snortsnort --daq pcap -l . -q -A full -c /etc/nsm/nku-onion-eth1/snort.conf -r backdoor.pcapngThis command will create a file named alert with the full text of the alerts. The backdoor alert will look like:[**] [1:2013188:4] ET EXPLOIT VSFTPD Backdoor User Login Smiley [**][Classification: Attempted Administrator Privilege Gain] [Priority: 1] 10/03-20:33:03.831502 192.168.1.100:54342 -> 192.168.1.102:21TCP TTL:64 TOS:0x10 ID:22310 IpLen:20 DgmLen:70 DF***AP*** Seq: 0x4367A384 Ack: 0x60245FB2 Win: 0xE5 TcpLen: 32TCP Options (3) => NOP NOP TS: 3344674672 104564551The most important information is listed on the first line of alert text—the alert message itself: ET EXPLOIT VSFTPD Backdoor User Login Smiley. The string ET at the beginning of the alert description indicates that the rule that produced this alert was from the Emerging Threats feed, which is a free set of rules for snort and suricata developed by the community. The three numbers … have the following meanings:1: the gid (generator ID), indicating which part of snort produced the alert. Generator 1 is the rules engine. Other generators include various preprocessors and the decoder subsystem.2013188: signature ID that provides a unique identifier for the rule. This identifier can be used to find the rule that produced this alert from the list of rules in /etc/nsm/rules on Security Onion.4: revision number indicates which version of the rule is the one that triggered the alert. This indicates that this alert was produced by the 4th version of rule 2013188. Earlier versions of Emerging Threats rules can be found in their github repository if you need to see what changed over the course of the three updates since the initial rule.The second line indicates the category of alert. As this is Attempted Administrator Privilege Gain, it indicates that an attacker attempted to gain administrator or root level access. Further investigation will be required to see if the attempt succeeded or not. The priority number of 1 indicates that this a high priority alert. The numbers 2, 3, and 4 indicate medium, low, and no priority alerts respectively.On the third line, we can see from the text that an attacker on 192.168.1.100 connected to a server on port 21 at 192.168.1.102 and attempted to gain access via a “smiley” backdoor. There is a also large amount of summary information about the packet after the IP addresses. Of particular interest is the string ID:22310 which is the IP identifier number of the packet that triggered the alert. Using the display filter ip.id == 22310 in Wireshark, you can view only the packet that triggered this alert, giving the analyst a good starting point in analyzing the packets associated with an alert.Answer the following questions based on the alerts and the contents of the pcap file.Which alert(s) were triggered? Include the full text under the SIGNATURE column of Squert.What were the signature IDs of the triggered alert(s)?What is the full text of the rule that generated this alert?What content in the pcap was matched by the triggered alert(s)?In which packet in the pcap file was the data that triggered the alert? Identify packets by packet number, not by IP identifier.What username string did the attacker use to gain access to the backdoor?Which service (identify by name and TCP port) contained the backdoor that was exploited?On which TCP port was the backdoor opened?What commands did the attacker issue via the backdoor?What did the attacker learn about the system with the backdoor?How could you exploit the backdoor? Write a step by step numbered list of events that you would need to use to complete the exploit.3: MS08-067 ExploitMicrosoft Security Bulletin MS08-067 describes the 67th security update published by Microsoft in year 2008. At the top of Microsoft’s bulletin page (), we see the words “Vulnerability in Server Service Could Allow Remote Code Execution.” This means that an unauthenticated user can run arbitrary code on vulnerable machines across the network. MS08-067 has had a variety of exploits written for it. While this vulnerability is old enough that most machines are patched, it is still used because exploits for this vulnerability are highly reliable.While running Squert on SecurityOnion, replay the packets on the SecurityOnion VM with# tcpreplay –t –i eth1 s08-067-exploit.pcapngAnswer the following questions based on the alerts and the contents of the pcap file.Which alert(s) were triggered? Include the full text under the SIGNATURE column.What were the signature IDs of the triggered alert(s)?What was the full text of the rule that produced this alert?What content in the pcap was matched by the triggered alert(s)?In which packet in the pcap file was the content of the alert found? Identify packets by packet number.Which service (identify by name and TCP port) contained the backdoor that was exploited?Instead of opening a backdoor, this exploit makes a shell connection to the attacker. What is the attacker’s IP address and which port number is used for this shell connection?Can you determine which commands are issued by the attacker? If so, list the commands.5: InvestigationMacDaddy Payment Processor has deployed Snort NIDS sensors to detect an array of anomalous events, both inbound and outbound. An alert was logged at 08:01:45 on 5/18/2011 concerning inbound shellcode sent to port 80/tcp for internal host 192.168.1.169 from external host 172.16.16.218. Here is the alert:[**] [1:10000648:2] SHELLCODE x86 NOOP [**][Classification: Executable code was detected] [Priority: 1]05/18 -08:01:45.591840 172.16.16.218:80 -> 192.168.1.169:2493TCP TTL :63 TOS:0x0 ID :53309 IpLen :20 DgmLen :1127 DF***AP*** Seq: 0x1B2C3517 Ack: 0x9F9E0666 Win: 0x1920 TcpLen: 20The MacDaddy Payment Processor network consists of three segments:Internal network: 192.168.1.0/24DMZ: 10.1.1.0/24Internet: 172.16.0.0/12The following evidence is available from the security team at MacDaddy.alert – A text file containing their snort sensor’s full text alert output.log.pcap – Full-content packet captures of the packets involved in the events summarized in the alert file.snort.conf – Configuration file for the snort sensor.rules – Directory containing the rules used by the snort sensor.This evidence gives the investigator the ability to run snort on log.pcap or on a subset of packets selected in Wireshark and exported from log.pcap. These files may be found on the class LMS.The investigation must determine if the alert above indicates an actual attack or false positive. Identify the packet by packet number within log.pcap as shown by Wireshark., then explain why the rule was triggered by that packet. If the packet was part of a file, extract the file from log.pcap and use that file as part of the evidence.Support your answer based not only on the alert above, but also on what happened after the alert. An attack would likely be followed up by additional attacker activity, which may result in more snort alerts, while a false positive would be unlikely to be connected to malicious activity involving the same IP addresses.5: Investigation ReportFollow our standard report format, include a timeline of alerted activities involving the potential attacker on the Internet as well as those involving the target, and be sure to support all statements with evidence from the alerts or captured packets. Identify events using packet numbers and/or timestamps.Offline ReferencesChris Sanders and Jason Smith. Applied Network Security Monitoring. Chapter 9. Syngress. 2014.Online ReferencesCisco. Snort Users Manual 2.9.9. . 2016.Emerging Threats FAQ. . 2017.Microsoft. Microsoft Security Bulletin MS08-067. . 2008.Rapid 7. Exploitable Vulnerabilities #1 (MS08-067). . 2014.DeliverablesThis assignment does not require a formal report. Instead, answers should be inserted into this lab document in the format(s) requested in each section. Bring a copy of this assignment to class on the day on which it is due for discussion. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download