Developing SNORT IDS Rules For A Fictitious Security Vulnerability In A Range Of Laser Printers

This question presents a fictitious security vulnerability in a range of lasers printers.  The question requires that you develop SNORT IDS rules to detect exploits of this fictitious vulnerability. All information regarding this vulnerability is fabricated to give the illusion of a real security threat.  As a result, searches on the Internet will not yield any information regarding the signature of this vulnerability.  All the information required to detect exploits for this vulnerability are presented in this question, except where noted otherwise.

You are a security specialist working for XYZ Incorporated.  XYZ use SNORT as their NIDS which protects both their IP sub-networks being 192.168.1.0/24 and 192.168.2.0/24. 

A security vulnerability has been detected in the Humphrey Pollard Laserprint 12050 printer model.  This vulnerability is remotely exploitable and allows the execution of arbitrary code. 

There is a bug in the way the printer processes the postscript spool management header.  A sample of a spool header is given below: 

%!PS-Adobe-3.0 %%Creator: texttops/CUPS v1.2.2%%CreationDate: Thu 21 Sep 2006 11:49:57 AM EST%%Title: TODO %%For: username %%DocumentNeededResources: font Courier-Bold …

The printer’s code which parses these headers only allows 8 bytes for the “%%For” field value buffer in memory.  In the example above, the field value is “username”.  It is possible to overflow the buffer by providing a value to the “%%For” field that is greater than 8 bytes. The “%%For” field can be found anywhere in the packet.

An exploit has been released in the form of a worm which when infecting the Laser printer’s memory, tricks the laser printer into emailing all documents received for printing to an email account in Russia.  The worm propagates by scanning networks in proximity of its own for other vulnerable printers.  On finding vulnerable machines, it copies itself to them and the cycle continues.  

It also propagates via email as a PDF attachment.  The malicious code is embedded in the PDF file. The email message suggests that the attached document contains a joke and requires printing to a laser printer to view.  When the user prints the PDF, its payload is sent to the printer either directly, or via a printer spooling server.  Effectively, this means the worm can attack printers from any host on the network.

If a printer is found to be compromised, power-cycling (turning off and then on) the printer will erase the worm from the printer’s volatile memory.  However, this does not prevent the printer from being re-infected.   

You are required to write 2 SNORT IDS rules labelled (ONE) and (TWO) to manage this vulnerability until patches are applied and printers reset.

 Rule (ONE) must detect attempts to exploit this vulnerability on any printer in the company network.  The rule should scan for attempts from any host on the network to any host on the network.  It should also scan only for connections to the Jetdirect printing TCP/IP port number, used by this range of printers. You may need to research Jetdirect to identify which port number it uses for printing and what transport protocol. Google is a good place to start.

The Vulnerability

The signature of the exploit is given as follows:

%%For: username

The value “username” can be any sequence of characters, but must be exactly 8 characters long. For example, “username” could be “abcdefgh”.  Note also there is a space between the colon and “username”.  Immediately following the 8 characters for the username is the payload of the exploit, which is given below as decimal byte values:

124 185 30 135 99 214 51 29

Your rule should match the entire sequence as described above starting from “%%For:” through to the last decimal byte of the exploit payload “29”.  On detecting packets, your rule should generate an alert with a message stating: “Attempt to exploit laser printer vulnerability”. 

Rule (TWO) must detect attempts by the malicious payload running on any infected printers to email documents to the Internet.   

You have 6 printers on your network that are vulnerable to this attack.  Their IP addresses are:

192.168.1.45

192.168.1.40

192.168.2.15

192.168.2.30

192.168.2.31

192.168.2.40 

Your email rule must apply only to the vulnerable printers on the network.  In other words, your rule should detect attempts to email the hacker from only the above printers, and no other hosts. 

This model of laser printer also provides scanning and faxing capabilities.  When the scanning function is used, the unit will email the scanned document to an Internet email address given by the user when scanning. As a result, it is normal behaviour for these printers to send emails via SMTP.  Therefore, it is necessary to check the recipient email address of the document.  The rule should detect attempts to email users outside of the organisation, as no document should be emailed outside the company from a printer.  The organisation’s domain name is: xyzcorp.com.au.  So any emails sent to an address of form: [email protected] should not be detected as these addresses are for company employees.  Any other email addresses without the exact domain name above should be detected. Any mail server could be used to deliver the email.  On detecting an email from one of these printers to an address outside the organisation, your rule should generate an alert with the message: “Compromised printer attempting to email document outside organisation” 

For both rules, be sure to complete the following:

1. Allocate an appropriate SID value and a revision number
2. Designate an appropriate class type for this attack.
3. Annotate your rules with comments describing what each component of the rule does, so other security specialists in your team can see how your rules are written. Comments can be introduced to your rules file snort.conf by preceding each line with a hash character “#”.  Anything after the hash character to the end of the line will be treated as a comment by SNORT and ignored by the rule parsing code.  This is how you should comment your rules.  

An example of how to present your rules in your assignment document is shown below: 

# Your explanation of the below in italics

var HOME_NET 138.77.23.0/16

var EXTERNAL_NET !138.77.23.0/16

# Your explanation of the below

drop udp $EXTERNAL_NET any -> $HOME_NET 993

#Your explanation of the below, and so on...

...

An example explanation for a SNORT rule option: 

# The content of the packet must contain the string “USER root” to be matched.  

# Furthermore, the offset option specifies that the string “USER root” should be 

# matched exactly 10 bytes from the beginning of the packet.  In other words, it will

# only match packets where 10 bytes from the start of the payload, the string 

# “USER root” is specified. 

The Worm Attack

content: “USER root”; offset:10;

     A.     Give your general description of the Kerberos authentication protocol

     B.     Explain the term: Authenticator used in the Kerberos authentication protocol

     C.     In the Kerberos authentication protocol, there are 3 basic roles: client, server and Key Distribution Centre (KDC). Give your description of each of them.

     D.     By explaining the term: Session Ticket, describe how a session key is created by KDC, distributed to the client and the server

     E.     Describe the mutual authentication procedure between the client and the server after the client obtains the session ticket. 

    A. Describe 802.1x authentication and the steps that when a wireless client connects to a network using RADIUS server for authentication.

    B. Explain the PEAP protocol – how does it differ from EAP and what EAP deficiency does it address?

    C. What makes a brute-force attack both particularly difficult and potentially easy on a wireless network using AES/CCMP encryption and 802.1x authentication Hint:  What do you need to know in order to attempt the attack?

    D. Assume an office wireless network was only configured with AES/CCMP encryption (i.e. no additional authentication standards). What problems would this cause?

    E.  Assume an office wireless network was only configured with 802.1x authentication (i.e. no additional encryption). What problems would this cause?

1. Define the Class type

include classification.config 

Indicate a variable which contains a list of IP addresses representing all vulnerable printers subject to an attack.

var variable_name

(Specify all ip addresses of printer)

alert tcp any any -> any (ephimaral port i.e. printer port) 

msg: “write the message you want to display” ; 

alert tcp any any -> any any (content:"%%For: "; content:"| 124 185 30 135 99 214 51 29 |"; distance:8;msg: "  ALERT printer exploit exposed")

Rule-2

It have to  discover endeavors by the vindictive payload running  on any tainted printer to email archives to clients outside the organization  this standard ought to recognize  bundles sent to any SMTP server on TCP port 25 from  just given  6 powerless printers in the system caution tcp $variable_name any -> any 25

msg:"???????????????????????????????????";

At that point include one more control: for

The association's space name is: xyzcorp.com.au. So any emails sent to a location of structure: [email protected] ought not be recognized as these addresses are for organization representatives. Whatever other email addresses without the careful space name above ought to be caught. Any mail server could be utilized to convey the email. On locating an email from one of these printers to a location outside the association, your tenet ought to produce an alarm with the message: "Traded off printer endeavoring to email report outside association"

alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:" Traded off printer endeavoring to email report outside association "; flow:to_server,established; content:“USER root”; offset:10; nocase; isdataat:300,relative; pcre:"/^RCPT TOx3as[^n]{300}/ism"; reference:bugtraq,2283; reference:bugtraq,9696; reference:cve,2001-0260; classtype:attempted-admin; sid:654; rev:14;)

(A). A full-benefit Kerberos environment, comprising of a Kerberos server, various customers and various application servers, obliges that the Kerberos server must have the client ID (UID) and hashed passwords of all taking an interest clients in its database. All clients are enrolled with the Kerberos server. Such an environment is alluded as a domain. Besides, the Kerberos server must impart a mystery key to every server and each server is enlisted with the Kerberos server.

The IDS Rules

A basic verification method must include three steps:

1. The customer C demands the client password and afterward make an impression on the AS of the Kerberos framework that incorporates the client's ID, the server's ID and the client's password.
2. The AS check its database to check whether the client has supplied the best possible password for this client ID and whether this client is allowed access to the server V. In the event that both tests are passed, the AS acknowledge the client as legitimate and must now persuade the server that this client is real. Along these lines the AS makes and sends once again to C a ticket that contains the client's ID and network address and the server's ID. At that point it is encoded with the mystery key imparted by the AS and the server V.
3. C can now apply to V for the administration. It makes an impression on V containing C's ID and the ticket. V unscrambles the ticket and checks that the client ID in the ticket is the same of the particular case that accompanied the ticket. In the event that these two match, the server allows the asked for administration to the customer.

(B). The Third segment (C as explained above) that matches the information communicated from the client and server and if it is proved to be correct or the information communicated is same from both the sides it lets the client to be authenticated and correct.

(C). Client: Client is the computer on the network that has to have resources from the server, in order to do so the computer needs to communicate with the Key Distributor to obtain the key request so that it could be authenticated from the user.

 Server: The server is any server on the network and it generally have no special security features installed it gives out permissions based on the Kerberos level authentication.

Key Distributor: The presentation of a plan for dodging plaintext passwords and another server, known as the Ticket-Granting Server (TGS). The new administration issues tickets to clients who have been verified to AS. Each one time the client oblige access to another administration, the customer applies to the TGS utilizing the ticket supplied by the AS to confirm itself. The TGS then concedes a ticket to the specific administration and the customer spares this ticket for future utilization.

(D). As opposed to sending the encrypted session keys to both of the principals, the KDC sends both the customer's and the server's duplicates of the session key to the customer. The customer's duplicate of the session key is encrypted with the customer's master key and in this manner can't be decoded by whatever other substance. The server's duplicate of the session key is implanted, alongside approval information about the customer, in an information structure called a ticket. The ticket is altogether encrypted with the server's master key and thusly can't be perused or changed by the customer or some other element that does not have entry to the server's master key. It is the obligation of the customer to store the ticket securely until contact with the server.

(E). At the point when the customer gets the KDC's reaction, it extricates the ticket and its own particular duplicate of the session key, putting both aside in a protected reserve. To make a safe session with the server, it sends the server a message comprising of the ticket, still encrypted with the server's master key, and an authenticator message encrypted with the session key. Together, the ticket and authenticator message are the customer's accreditations to the server.

At the point when the server gets certifications from a customer, it unscrambles the ticket with its master key, removes the session key, and uses the session key to unscramble the customer's authenticator message. On the off chance that everything looks at, the server realizes that the customer's accreditations were issued by the KDC, a trusted power. For shared verification, the server reacts by encoding the time stamp from the customer's authenticator message utilizing the session key. This encrypted message is sent to the customer. The customer then decodes the message. In the event that the returned message is the same as the time stamp in the first authenticator message, the server is verified.

Rule 1

(A). A typical network get to, three-part building design emphasizes a supplicant, access gadget (switch, access point) and verification server (RADIUS). This building design influences the decentralized access gadgets to give versatile, however computationally lavish, encryption to numerous supplicants while in the meantime centralizing the control of access to a couple of validation servers. This last peculiarity makes 802.1x validation sensible in extensive establishments.

At the point when EAP is run over a LAN, EAP bundles are encapsulated by EAP over LAN (EAPOL) messages. The arrangement of EAPOL parcels is characterized in the 802.1x determination. EAPOL correspondence happens between the end-client station (supplicant) and the remote access point (authenticator). The RADIUS convention is utilized for correspondence between the authenticator and the RADIUS server.

The verification procedure starts when the end client endeavors to unite with the WLAN. The authenticator gets the solicitation and makes a virtual port with the supplicant. The authenticator goes about as an intermediary for the end client passing validation data to and from the verification server for its sake. As far as possible movement to confirmation information to the server.

A transaction happens, which incorporates:

• the customer may send an EAP-begin message.
• the access point sends an EAP-demand character message.
• the customer's EAP-reaction parcel with the customer's personality is "proxied" to the verification server by the authenticator.
• the confirmation server challenges the customer to substantiate themselves and may send its certifications to substantiate itself to the customer (if utilizing shared verification).
• the customer checks the server's accreditations (if utilizing common confirmation) and after that sends its qualifications to the server to substantiate itself.
• the validation server acknowledges or rejects the customer's appeal for association.
• if the end client was acknowledged, the authenticator changes the virtual port with the end client to an approved state permitting full network access to that end client.
• at log-off, the customer virtual port is changed over to the u

(B). PEAP (Protected Extensible Authentication Protocol) is a variant of EAP, the validation convention utilized as a part of remote networks and Point-to-Point associations. PEAP is intended to give more secure confirmation to 802.11 Wlans (remote neighborhood) that help 802.1x port access control. 

PEAP verifies the server with an open key testament and conveys the validation in a safe Transport Layer Security (TLS) session, over which the WLAN client, WLAN stations and the confirmation server can verify themselves. Each one station gets an individual encryption key. At the point when utilized as a part of conjunction with Temporal Key Integrity Protocol (TKIP), each one key has a limited lifetime. 

Cisco Systems, Microsoft and RSA Security are advancing PEAP as an Internet standard. Presently in draft status, the convention is picking up help and is relied upon to remove Cisco's exclusive Lightweight Extensible Authentication Protocol (LEAP). 

PEAP addresses the weaknesses of 802.11 security, imparted key validation being boss among these. Shortcomings in 802.11 Wired Equivalent Privacy (WEP) permit an aggressor to catch encrypted casings and dissect them to focus the encryption key. (In this framework, the same imparted key is utilized for both confirmation and encryption.) With the imparted key, the aggressor can decode edges or stance as a honest to goodness client. 

PEAP is comparative in outline to EAP-TTLS, obliging just a server-side PKI testament to make a protected TLS shaft to secure client verification, and uses server-side open key authentications to validate the server. It then makes an encrypted TLS burrow between the customer and the confirmation server. In many arrangements, the keys for this encryption are transported utilizing the server's open key. The resulting trade of verification data inside the passage to confirm the customer is then encrypted and client accreditations are protected from listening stealthily. 

(C). AES remains for "Cutting edge Encryption Standard." This was a more secure encryption convention presented with Wpa2, which supplanted the interval WPA standard. AES isn't some creaky standard created particularly for Wi-Fi networks; its a genuine overall encryption standard that is even been received by the US government. Case in point, when you scramble a hard drive with Truecrypt, it can utilize AES encryption for that. AES is for the most part considered very secure, and the fundamental shortcomings would be savage energy assaults (forestalled by utilizing a solid passphrase) and security shortcomings in different parts of Wpa2.

Rule 2

The undertaking mode is still defenseless to assaults. One way a Wi-Fi programmer could conceivably join with your undertaking secured remote network is by breaking the client passwords by means of animal energy lexicon assaults. Despite the fact that not as straightforward as breaking WPA/Wpa2 Psks, its still conceivable with the privilege devices. They'd need to set up a fake network, a right to gain entrance point matching the SSID and security settings of the genuine network with expectations of getting clueless clients of the genuine network to interface keeping in mind the end goal to catch their login accreditations. The assailant could sit tight for customers to join or attempt to constrain it by sending de-confirmation parcels and/or utilizing speakers and reception apparatuses to help the fake sign.

The aggressor would likewise need to set up a fake RADIUS server to catch these client login accreditations. They could utilize the prevalent open source Freeradius server with the Freeradius-WPE patch. This patch changes a portion of the settings so the server will acknowledge and dependably react with a fruitful validation (regardless of the password) for all the diverse EAP sorts and after that logs the verification demands. Inside the logs, an aggressor can typically see the username the customer is utilizing to unite with the genuine network. They wouldn't see the client's password however would have the test and reaction that they could gone through a word reference based saltine to uncover the password.

(D). Wpa2 Personal (AES) is right now the strongest manifestation of security offered by Wi-Fi items, and is suggested for all employments. At the point when empowering Wpa2, make sure to choose a solid password, one that can't be speculated by outsiders.

On the off chance that you have more established Wi-Fi gadgets on your network that don't help Wpa2 Personal (AES), a great second decision is WPA/Wpa2 Mode (regularly alluded to as WPA Mixed Mode). This mode will permit more current gadgets to utilize the stronger Wpa2 AES encryption, while as yet permitting more established gadgets to unite with more established WPA TKIP-level encryption. In the event that your Wi-Fi switch doesn't help WPA/Wpa2 Mode, WPA Personal (TKIP) mode is the following best decision.

(E). "Malignant affiliations" are when remote gadgets can be effectively made by assailants to unite with an organization network through their portable computer rather than an organization access point (AP). These sorts of laptops are known as "delicate Aps" and are made when a digital criminal runs some product that makes his/her remote network card resemble an authentic access point. Once the hoodlum has gotten access, he/she can take passwords, dispatch assaults on the wired network, or plant trojans. Since remote networks work at the Layer 2 level, Layer 3 insurances, for example, network verification and virtual private networks (Vpns) offer no boundary. Remote 802.1x validations do help with some assurance however are still helpless against hacking. The thought behind this sort of assault may not be to break into a VPN or other efforts to establish safety. Undoubtedly the criminal is simply attempting to assume control over the customer at the Layer 2 level.