Intrusion Detection Evasive Techniques

Most attackers are aware of IDSs and use evasive techniques to dodge them. These evasive techniques include flooding, fragmentation, encryption, and obfuscation.

Flooding

IDSs depend on resources such as memory and processor power to effectively capture packets, analyze traffic, and report malicious attacks. By flooding a network with noise traffic, an attacker can cause the IDS to exhaust its resources examining harmless traffic. In the meantime, while the IDS is distracted and occupied by the volume of noise traffic, the attacker can target its system with little or no intervention from the IDS.

Fragmentation

Because different network media allow variable maximum transmission units (MTUs), you must allow for the fragmentation of these transmission units into differently sized packets or cells. Hackers can take advantage of this fragmentation by dividing attacking packets into smaller and smaller portions that evade the IDS but cause an attack when reassembled by a target host.

Encryption

Network-based intrusion detection (covered later in this chapter) relies on the analysis of the traffic that is captured as it traverses the network from a source to its destination. If a hacker can establish an encrypted session with its target host using Secure Shell (SSH), Secure Socket Layer (SSL), or a virtual private network (VPN) tunnel, the IDS cannot analyze the packets and the malicious traffic will be allowed to pass. Obviously, this technique requires that the attacker establish a secure encrypted session with its target host.

Obfuscation

Obfuscation, an increasingly popular evasive technique, involves concealing an attack with special characters. It can use control characters such as the space, tab, backspace, and Delete. Also, the technique might represent characters in hex format to elude the IDS. Using Unicode representation, where each character has a unique value regardless of the platform, program, or language, is also an effective way to evade IDSs. For example, an attacker might evade an IDS by using the Unicode character c1 to represent a slash for a Web page request.

Web Server Attack Tools

Web Server Attack Tools are now familiar with the methodology that an attacker uses to hack an internet server. This section will introduce web server hacking took that an attacker may use within the web server hacking methodology described in the previous section. These tools extract critical information during the hacking process.

Web Server Attack Tool: Metasploit

The Metasploit Framework may be a penetration-testing toolkit, exploit development platform, and research tool that has hundreds of working remote exploits for a spread of platforms. It supports fully automated exploitation of web servers by abusing known vulnerabilities and leveraging weak passwords via Telnet, H, HTTP, and SNM.

The features of Metasploit that an attacker may use to perform web server attack

1)  Closed-loop Vulnerability Validation

2) Phishing Simulations

3) Social Engineering

4) Manual Brute Forcing

5) Manual Exploitation

6) Evade-leading defensive solutions

Metasploit Architecture

The Metasploit framework is an open-source exploitation framework that gives security researchers and pen testers a consistent model for the rapid development of exploits, payloads, encoders, NOP generators, and reconnaissance tools. The framework reuses large chunks of code that a user would need to otherwise copy or re-implement on a per-exploit basis. The framework is modular in architecture and encourages the reuse of code across various projects. The framework itself is broken down into a couple of different pieces, the most low-level being the framework core. The framework core is liable for implementing all of the specified interfaces that allow interaction with exploit modules, sessions, and plugins. It supports vulnerability research, exploits development, and therefore the creation of custom security tools.

Metasploit modules

1. Metasploit Exploit Module

It is the basic module in Metasploit used to encapsulate an exploit using which users target many platforms with a single exploit. This module comes with simplified meta-information fields. Using a Mixins feature users can also dynamically modify exploit behavior, brute force attacks, and attempt passive exploits.

Steps to exploit a system follow the Metasploit Framework :

– Configuring active exploit

– Verifying the exploit options

– Selecting a target

– Selecting the payload

– Launching the exploit

2. Metasplolt Payload Module

An exploit carries the payload in its backpack when it breaks into the system and then leaves the backpack there.

There are three types of payload modules provided by the Metasploit:

• Singles: It is self-contained and completely standalone
• Stagers: It sets up a network connection between the attacker and the victim
• Stages: It is downloaded by stagers modules

Metasploit Payload Module can upload and download files from the system, take screenshots, and collect password hashes. It can even take over the screen, mouse, and keyboard to regulate a foreign computer. The payload module establishes a communication channel between the Metasploit framework and therefore the victim host. It combines the arbitrary code that’s executed because the results of an exploit succeed. to generate payloads first select a payload using the command as shown within the screenshot below.

3. Metasploit Auxiliary Module

The Auxiliary Module of Metasploit is often wont to perform arbitrary, one-off actions like port scanning, DoS, and even fuzzing. It includes tools and modules that assess the security of the target, auxiliary modules like scanners, DOS Modules, fuzzes, and so on. To list all the available auxiliary modules in Metasploit, use shows the auxiliary command in Metasploit. All the other modules in Metasploit are auxiliary modules except modules used to exploit. The tool uses the auxiliary modules as an extension for a spread of purposes aside from exploitation. Auxiliary modules reside within the modules/auxiliary/ directory of the framework’s main directory. To run the auxiliary module, either use the run command or use the exploit command.

The basic definition of an auxiliary module is:

Metasploit NOPS Module

NOP modules generate no-operation instructions used for blocking out buffers. Use generate command to generate a NOP sled of arbitrary size and display it in a given format.

OPTIONS:

-b <opt>: The list of characters to avoid: 1\x00\xff’

-h: Help banner

-s <opt>: The comma-separated list of registers to save

-t <opt>: The output type: ruby, Perl, c, or raw

MSF nop(opty2)>

Understand various Android threats and attacks

App-based mobile threats

Applications are often the root of mobile device vulnerabilities. These types of attacks can occur when users download malicious apps or grant apps permission to access device data without checking whether or not it’s safe to do so

Web-based mobile threats

A web-based mobile attack is usually achieved through phishing or spoofing. Attackers will send an email, text, or another instant message that looks as if it was from a trusted source—but the message contains a malicious link or attachment. When users click through or provide personal information, the bad actor can then gain unauthorized access to their mobile device or steal credentials to spoof identities

Network threats

This type of mobile attack occurs when bad actors target unsecured or free-to-use public WiFi connections. In some cases, hackers may even set up a fake WiFi network (known as network spoofing) in an attempt to trick users. Spoofed networks will ask users to create an account with a username and password, giving hackers the opportunity to compromise devices and credentials

Physical threats

Lost, stolen, and unattended devices open users up to a range of cell phone security issues. If you don’t use a strong password, PIN, or biometric authentication, or use unencrypted apps and services, your phone can easily be hacked—especially considering how sophisticated the threat landscape is today

Mobile security threats and prevention 

It’s bad enough that malicious actors can use any of the above-mentioned threat types to launch an attack on unsuspecting users—but what’s even worse is that our everyday behavior and mobile activity can make it even easier for them to succeed. Below are some of the most common ways that we put our data and identities at risk of mobile device security threats, and tips on how to protect ourselves.

Downloading malicious apps and granting too many permissions

Applications that are downloaded from sources other than official app stores can lead to data leaks, as they’re often unlikely to have the appropriate protections in place. In addition, attackers may release malicious apps that are intended to exploit the users who download them—by stealing data from a device and selling it to third parties, for instance. Data leaks can also occur through malware-infected enterprise apps that distribute code on mobile operating systems, moving data across business networks without being discovered. 

How to minimize risk

Only download applications from Google Play, the Apple App store, and other trusted providers. In addition, deny permissions—such as access to location data, your camera, and microphone—unless the app you’re using absolutely requires it

Connecting to unsecured WiFi networks

WiFi networks that are free to access in public places like airports, coffee shops, and libraries are attractive because they give you the opportunity to avoid using mobile data. But many of these networks are unsecured, which means attackers can more easily gain access to users’ devices and compromise their data.

How to minimize risk

Think twice before connecting to free WiFi hotspots, and never use one that requires you to create an account or password. If you do need to use one of these networks, stick to low-risk activities—they should never be used to access your social media accounts, banking apps, or to make an online purchase.

Being the target of a social engineering attack

With remote work on the rise, attacks like phishing and “smishing” are increasingly prevalent on both mobile devices and computers. However, mobile users are often more vulnerable to these attacks because smaller screen sizes limit the amount of information that can be seen in a malicious email at any one time. This increases the chances that users will click on a link without considering the consequences. 

How to minimize risk

Never click on a link in an email or text message, even if it appears to be from a trusted sender. Instead, enter the URL in the address bar of your web browser so that you can verify that the link is legitimate

Practicing poor cyber hygiene

It’s more important than ever for people to practice good cyber hygiene, but many people continue to use weak passwords, recycle credentials across accounts, share data with friends and colleagues, and refuse to update applications and operating systems.

Out-of-date devices can also contribute to a slew of mobile cyber security issues. Whether it’s due to the manufacturer failing to offer updates or because a user chooses not to download new versions and software, this leaves gaps that an attacker can use to infiltrate a device. 

In addition, users can fall victim to mobile security threats due to improper session handling. Many apps use tokens to make the experience more convenient for users (i.e., allowing them to perform actions without reauthenticating). But these tokens can sometimes be unintentionally shared with bad actors if sessions remain open.

How to minimize risk

Use strong passwords, deploy multi-factor Authentication (MFA) Tools, set your devices to automatically update, and log out of apps and websites when you’re finished using them. And of course, keep your personal information and logins to yourself

Operating with broken cryptography or without end-to-end encryption

With people spending more time at home, there’s been a huge uptick in the use of video conferencing tools on mobile devices. While these are great for helping colleagues and families keep in touch, there are risks involved—especially if you use an app or service that doesn’t encrypt conversations, operates using weak algorithms, or otherwise leaves devices vulnerable to attacks

How to minimize risk

Whether you’re a business owner or a concerned individual, ensure that you—and everyone else you’re communicating with—is using applications and online tools that prioritize keeping identities and data secure.

Falling prey to botnets

A botnet is formed when a group of computers falls under the control of a hacker. Typically they’re used to overload an organization’s resources during malicious acts, such as Distributed Denial of Service (DDoS) attacks—which can be executed on mobile devices via Trojans, viruses, and worms. 

How to minimize risk

Like many other mobile threats, botnets can be avoided by only downloading legitimate apps, never clicking links or attachments in emails, using secure wireless networks, and being aware of unusual activity on devices. 

Organizations can protect themselves from mobile threats 

While IT and security teams are largely responsible for protecting a company, employee, and customer data, there’s also a lot that end users can do to secure their devices. Let’s take a look at how each group can improve security at work and at home

What IT and security can do

More than ever before, employees are working remotely from different locations and on various devices. However, only 13% of organizations deploy four basic protection: data encryption, need-to-know access, no default passwords, and regular security testing. Furthermore, nearly 50% of organizations don’t have an acceptable use policy in place, which is vital to fighting mobile data security threats and sets the standard for employee behavior on devices and networks.

IT teams can benefit by implementing mobile device management, deploying tools like MFA and single sign-on (while moving away from SMS Authentication), and adopting a Zero Trust approach to security in their organizations. They should also provide regular training for employees to ensure security is always top of mind and advise everyone of the latest, most prominent threats they could face on a daily basis.

What individuals can do

Employees can also prevent mobile security attacks by making sure they have a robust understanding of common threats. Not only should they know what they are—but they should also be able to recognize the telltale signs that an attempted attack has been made. 

In addition to following the policies set by their organization, employees can take security into their own hands by implementing secure password practices and enabling stronger authentication tools (like MFA and biometrics) across their devices. They can also ensure their home networks are secure and avoid using free WiFi networks when working remotely. 

What’s next in mobile device security?

To keep their employees and company data safe, it’s essential for organizations to stay on top of mobile device security risks—especially as the world becomes increasingly more remote. 

Dynamic work 

The model gives employees the freedom and flexibility to work from anywhere and requires a highly secure, integrated IT stack. Considering mobile security is a crucial part of this so that employees can collaborate effectively and safely—at any time, from any location, on any device.

Bring your own device

Policies have been around for a long time now, but they’re even more important in our current working environments. Organizations need to ensure that employees are able to work on any device, which makes tools like MFA and a Zero Trust approach to security absolutely crucial.

Internet of Things

Growing rapidly as more people rely on connected devices at work and at home (e.g., smart refrigerators and voice assistants). Being aware of what these devices are and how they may change the security landscape is key to preventing bad actors from gaining unauthorized access to information and networks

Web Server Types of Attacks

       Web Server Types of Attacks

1) Scanning – Tools, such as Nmap and SuperScan, can be used.

2) Banner grabbing – Identifies the server and version. Netcat and Telnet are useful here.

3) Attacking the web server – The script kiddies’ dream would be to find unpatched servers or discover a recently discussed vulnerability that hasn’t been patched yet.

4) Surveying the application – Because it’s more advanced than a direct web server attack, attacking the application could go unnoticed.

5) Attacking authentication – Weak forms of authentication might allow the attacker to beat authentication or guess commonly used passwords.

6) Exploiting the database – A tempting target for hackers looking to make a profit in identity or credit card theft.

The web browser sends HTTP requests to the Web server. The firewall captures this traffic and, typically, concentrates on analyzing the communication parameters of the traffic. It checks the destination port, the source and destination IP addresses, and similar other attributes. However, a firewall’s weakness lies in its inability to verify the data portion (e.g., requests) of the communication consistently. This allows the request to appear legitimate to the firewall. When it arrives at the Web server, it is serviced normally. However, the request may be malicious and exploit a server vulnerability, producing undesired results.

Buffer Overflow Attacks

Buffer overflow vulnerabilities stem from problems in string handling. Whenever a computer program tries copying a string or buffers into a buffer that is smaller than itself, an overflow is sometimes caused. If the destination buffer is overflowed sufficiently it will overwrite various crucial system data. In most situations an attacker can leverage this to takeover a specific program’s process, thereby acquiring the privileges that process or program has.

Parser Evasion Attacks

Insecure string parsing can allow attackers to remotely execute commands on the machine running the Web server. If the CGI script or Web server feature does not check for various characters in a string, an attacker can append commands to a normal value and have the commands executed on the vulnerable server.

Directory Traversal Attacks

In certain situations, various characters and symbols can be used to break out of the Web server’s root directory and access files on the rest of the file system. By checking for these characters and only allowing certain directories to be accessed, directory traversal attacks are prevented.

Cache Poisoning

Cache poisoning, also called domain name system (DNS) poisoning or DNS cache poisoning, is the corruption of an Internet server’s domain name system table by replacing an Internet address with that of another, rogue address. When a Web user seeks the page with that address, the request is redirected by the rogue entry in the table to a different address. At that point, a worm, spyware, Web browser hijacking program, or other malware can be downloaded to the user’s computer from the rogue location.

The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue to receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although only the user of the local browser instance will be affected.

Hidden Fields

Hidden fields are a poor coding practice that has been known and publicized for some time, although it still continues. It’s the practice of using hidden HTML fields as a sole mechanism for assigning a price or obscuring a value. This practice of security by obscurity can be easily overcome by just reviewing the code. The theory is that if end users cannot see it, it is safe from tampering.

Many sites use these hidden value fields to store the price of the product that is passed to the web application.

Web-Based Password Cracking

An unlimited number of tools are available for the attacker to attempt to break into web-based applications. If the site does not employ a lockout policy, it is only a matter of time and bandwidth before the attacker can gain entry. Password cracking doesn’t have to involve sophisticated tools; many times password guessing works well. It can be a tedious process, although human intuition can beat automated tools.

URL Obfuscation

It is possible to hide addresses in URLs so that they can bypass filters or other application defenses that have been put in place to block specific IP addresses. Although web browsers recognize URLs that contain hexadecimal or binary character representations, some web filtering applications don’t. Here is an example of an encoded binary IP address: http://8812120797/. Does it look confusing? This decimal address can be converted into a human-readable IP address. Convert the address into hexadecimal, divide it into four sets of two digits, and finally convert each set back into decimal to recover the IP address manually.

XSS

Cross-site scripting (XSS) enables attackers to inject client-side script into Web pages viewed by other users. A cross-site scripting vulnerability may be used by attackers to bypass access controls such as the same-origin policy. Cross-site scripting carried out on websites accounted for roughly 84% of all security vulnerabilities documented by Symantec as of 2007. Their effect may range from a petty nuisance to a significant security risk, depending on the sensitivity of the data handled by the vulnerable site and the nature of any security mitigation implemented by the site’s owner.

Security on the web is based on a variety of mechanisms, including an underlying concept of trust known as the same-origin policy. This essentially states that if the content from one site (such as https://mybank.example1.com) is granted permission to access resources on the system, then any content from that site will share these permissions, while content from another site (https://othersite.example2.com) will have to be granted permissions separately.

Cross-site scripting uses known vulnerabilities in web-based applications, their servers, or plug-in systems on which they rely. Exploiting one of these, attackers fold malicious content into the content being delivered from the compromised site. When the resulting combined content arrives at the client-side web browser, it has all been delivered from the trusted source, and thus operates under the permissions granted to that system. By finding ways of injecting malicious scripts into web pages, an attacker can gain elevated access privileges to sensitive page content, session cookies, and a variety of other information maintained by the browser on behalf of the user. Cross-site scripting attacks are therefore a special case of code injection.

The term “Cross-Site Scripting” was introduced by Microsoft in the year 2000. The expression “Cross-Site Scripting” originally referred to the act of loading the attacked, third-party web application from an unrelated attack site, in a manner that executes a fragment of JavaScript prepared by the attacker in the security context of the targeted domain (a reflected or non-persistent XSS vulnerability). The definition gradually expanded to encompass other modes of code injection, including persistent and non-JavaScript vectors (including ActiveX, Java, VBScript, Flash, or even HTML scripts), causing some confusion to newcomers to the field of information security.

XSS vulnerabilities have been reported and exploited since the 1990s. Prominent sites affected in the past include the social-networking sites Twitter, Facebook, MySpace, YouTube, and Orkut. In recent years, cross-site scripting flaws surpassed buffer overflows to become the most common publicly reported security vulnerability, with some researchers in 2007 viewing as many as 68% of websites as likely open to XSS attacks.

CSRF

Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious Web site, email, blog, instant message, or program causes a user’s Web browser to perform an unwanted action on a trusted site for which the user is currently authenticated. The impact of a successful cross-site request forgery attack is limited to the capabilities exposed by the vulnerable application. For example, this attack could result in a transfer of funds, changing a password, or purchasing an item in the user’s context. In effect, CSRF attacks are used by an attacker to make a target system perform a function (funds Transfer, form submission, etc.) via the target’s browser without the knowledge of the target user, at least until the unauthorized function has been committed.

Remote File Inclusion

Remote File Inclusion (RFI) is a type of vulnerability most often found on websites. It allows an attacker to include a remote file, usually through a script on the webserver. The vulnerability occurs due to the use of user-supplied input without proper validation.

Local File Inclusion

Local File Inclusion (LFI) is similar to a Remote File Inclusion vulnerability except instead of including remote files, only local files i.e. files on the current server can be included. The vulnerability is also due to the use of user-supplied input without proper validation.

Session Hijacking

Session Hijacking, sometimes also known as cookie hijacking is the exploitation of a valid computer session—sometimes also called a session key—to gain unauthorized access to information or services in a computer system. In particular, it is used to refer to the theft of a magic cookie used to authenticate a user to a remote server. It has particular relevance to web developers, as the HTTP cookies used to maintain a session on many websites can be easily stolen by an attacker using an intermediary computer or with access to the saved cookies on the victim’s computer.

A popular method is using source-routed IP packets. This allows an attacker at point B on the network to participate in a conversation between A and C by encouraging the IP packets to pass through B’s machine.

If source routing is turned off, the attacker can use “blind” hijacking, whereby it guesses the responses of the two machines. Thus, the attacker can send a command, but can never see the response. However, a common command would be to set a password allowing access from somewhere else on the net.

An attacker can also be “inline” between A and C using a sniffing program to watch the conversation. This is known as a “man-in-the-middle attack”.

Methods

There are four main methods used to perpetrate a session hijack. These are:

• Session fixation, where the attacker sets a user’s session id to one known to him, for example by sending the user an email with a link that contains a particular session id. The attacker now only has to wait until the user logs in.
• Session sidejacking, where the attacker uses packet sniffing to read network traffic between two parties to steal the session cookie. Many websites use SSL encryption for login pages to prevent attackers from seeing the password but do not use encryption for the rest of the site once authenticated. This allows attackers that can read the network traffic to intercept all the data that is submitted to the server or web pages viewed by the client. Since this data includes the session cookie, it allows him to impersonate the victim, even if the password itself is not compromised. Unsecured Wi-Fi hotspots are particularly vulnerable, as anyone sharing the network will generally be able to read most of the web traffic between other nodes and the access point.
• Alternatively, an attacker with physical access can simply attempt to steal the session key by, for example, obtaining the file or memory contents of the appropriate part of either the user’s computer or the server.
• Cross-site scripting, where the attacker tricks the user’s computer into running code that is treated as trustworthy because it appears to belong to the server, allowing the attacker to obtain a copy of the cookie or perform other operations.

Exploits

• Firesheep – In October 2010, a Mozilla Firefox extension called Firesheep was released that made it easy for session hijackers to attack users of unencrypted public Wi-Fi. Websites like Facebook, Twitter, and any that the user adds to their preferences allow the Firesheep user to easily access private information from cookies and threaten the public Wi-Fi user’s personal property. Only months later, Facebook and Twitter responded by offering (and later requiring) HTTP Secure throughout.
• WhatsApp sniffer – An app named “WhatsApp Sniffer” was made available on Google Play in May 2012, able to display messages from other WhatsApp users connected to the same network as the app user. At that time WhatsApp used an XMPP infrastructure with unencrypted, plain-text communication.
• DroidSheep – DroidSheep is a simple Android tool for web session hijacking (sidejacking). It listens for HTTP packets sent via a wireless (802.11) network connection and extracts the session id from these packets in order to reuse them. DroidSheep can capture sessions using the libpcap library and supports: OPEN Networks, WEP encrypted networks, and WPA/WPA2 encrypted networks (PSK only) This software uses libpcap and arpspoof. The apk was made available on Google Play but it has been taken down by Google. The source is available here
• CookieCadger – CookieCadger is a Java app that automates sidejacking and replay of insecure HTTP GET requests. Cookie Cadger helps identify information leakage from applications that utilize insecure HTTP GET requests. Web providers have started stepping up to the plate since Firesheep was released in 2010. Today, most major websites can provide SSL/TLS during all transactions, preventing cookie data from leaking over wired Ethernet or insecure Wi-Fi. Cookie Cadger is the first open-source pen-testing tool ever made for intercepting and replaying specific insecure HTTP GET requests into a browser. Cookie Cadger is a graphical utility that harnesses the power of the Wireshark suite and Java to provide a fully cross-platform, entirely open-source utility that can monitor wired Ethernet, insecure Wi-Fi, or load a packet capture file for offline analysis. Cookie Cadger has been used to highlight the weaknesses of youth team sharing sites such as Shutterfly (used by AYSO soccer league) and TeamSnap. The binary and source can be downloaded here

Prevention

Methods to prevent session hijacking include:

• Encryption of the data traffic passed between the parties by using SSL/TLS; in particular the session key (though ideally all traffic for the entire session). This technique is widely relied-upon by web-based banks and other e-commerce services because it completely prevents sniffing-style attacks. However, it could still be possible to perform some other kind of session hijack. In response, scientists from the Radboud University Nijmegen proposed 2013 a way to prevent session hijacking by correlating the application session with the SSL/TLS credentials
• Use of a long random number or string as the session key. This reduces the risk that an attacker could simply guess a valid session key through trial and error or brute force attacks.
• Regenerating the session id after a successful login. This prevents session fixation because the attacker does not know the session id of the user after s/he has logged in.
• Some services make secondary checks against the identity of the user. For example, a web server could check with each request made that the IP address of the user matched the one last used during that session. This does not prevent attacks by somebody who shares the same IP address, however, and could be frustrating for users whose IP address is liable to change during a browsing session.
• Alternatively, some services will change the value of the cookie with each and every request. This dramatically reduces the window in which an attacker can operate and makes it easy to identify whether an attack has taken place, but can cause other technical problems (for example, two legitimate, closely timed requests from the same client can lead to a token check error on the server).
• Users may also wish to log out of websites whenever they are finished using them. However, this will not protect against attacks such as Firesheep.