For those waiting after the part one, apologies to keep you stranded as I was tied up for few days for mitigation of Zeus (yes, we've got some in network, no very proud of but was a true story caused by wireless guests) and it was a good time to give some exercise to IRT monkeys.
Let's pick up where we left.
Before
Stonesoft introduced Evader back in July at Black Hat 2012, there were some tough time to test evasion techniques within the network. With the
tool, many IT security folks can leverage some of the advanced evasions which are already in the wild without raising any alerts in normal IPS or NGFW, and conduct effective POC to validate where they stand in this scenario.
The following list will show some of possible evasion techniques we can expect.
- Encoding
- Obfuscation
- Tunneling
- Injection
Any of them can be combined to establish phone-home connection from botnets to C&C servers that we have already seen.
1. Encoding
While I found this diagram very useful to explain what levels of application and interaction in Web 2.0 era, this is also true for some of the malwares that are already based on this architecture.
Let's start from the beginning to set the scene. I'll make it as much readable as I could to keep you entertain.
URI - Uniform Resource
Identifier
RDF - Resource Description Framework
RDFS - RDF
Schema
SPARQL - Simple Protocol and RDF Query Language
OWL - Web Ontology Language
RIF/SWRL - Rule Interchange Format/Semantic Web Rule Language
Whilst the original architecture was to enhance information shared on WWW, I will utilize it as the basic of encoding evasion techniques. For this topic sake, I'll just emphasize on UNICODE, URI and Cryptography.
First, UNICODE. It is a known method in XSS (
OWASP 2010 - A2). It can be used to mask the malicious web requests and other HTTP URI-based attacks. URI has been in used for directory traversal attacks and when such requests use encoding, a
poorly configured web server is vulnerable to unauthorized information disclosure.
As the main purpose of today's malware is to stay under the radar, additional efforts have been done to secure the communication channel between the infected host and the bot controller using
encryption. In early days, cybercriminals used RC4 to hide payload, communication or code. Some have gone further miles by using
AES or
customized encryption.
2. Obfuscation
This has long been used for legitimate purposes for developers to protect their codes from being reverse-engineered by others, especially in OOP languages. The use of obfuscation has been grown widely as it can be seen in phishing, Javascript-embedded documents and again XSS just to list a few.
3. Tunneling
Here comes my favorite part. As we slowly adopt the transition to IPv6, there has never been a better time to find more and more tunneling methods in the network to support new and existing application and infrastructure. When we think about about tunneling, let's consider some remote administration tools that are already in play. An array of LogMeIn, TeamViewer, GoToMyPC and infamous Ammyy (associated with scamming,
1 and
2) use tunneling via standard http or https ports based on the fact that these are generally unrestricted traffic.
Another issue is encapsulation. For example, 6to4 tunneling is a kind of encapsulated traffic on native IPv4 environment (
RFC6343,
RFC3964). As mentioned in the latter, there are four identified attacks to 6to4 tunnels.
a) Attacks with Neighbor Discovery (ND) Messages
b) Spoofing traffic to 6to4 nodes
c) Reflecting traffic from 6to4 nodes
d) Local IPv4 broadcast attack
A fine details of security concerns on IP Tunneling is explained in
RFC6169.
4. Injection
Last but not least, I save the best for the last. This issue has topped OWASP 2010 as
A1 and personally I believe it will maintain its position should the OWASP refresh their Top 10.
When you hear about injection, the first thing would come to your mind might be SQLi and for a fact, this has been in the news most often than others. A recent revelation about
Sony attack was a good highlight of how prevalent the exploitation can be. We can break down injections into following categories, sorted by severity.
a) SQL injection
b) Shell command injection
c) Script injection
d) File injection
a) SQL injection
Such injections can occur when the developers allow the user-side to create dynamic queries based on supplied inputs. The reason of having highest severity is simple. It can be applied to
ANY database with
ANY programming language. Do I have your attention now? So what can we do to restrict and prevent this vulnerability. Here's how.
i) Use parameterized queries
ii) Use stored procedures
iii) Use escaping schemes
I ain't no DBA, but had a good time reading this
Cheat Sheet to recall my days with SQL Server 2000 and MySQL.
b) Shell command injection
Yet another malicious traffic can be seen within HTTP and HTTPS is the shell injection. The can vary from real shell commands to other utility programs depending on how the web server is set up. The culprit of this is that all injected codes will execute at same privilege as the web application. Again, how do we
defend this? You can locate the following items and filter if deemed suspicious.
i) HTTP header
ii) HTTP post
iii) form items
iv) hidden fields
and so on.
We should
validate any inputs passed from the interface before they are processed and executed.
c) Script injection
I don't think this one requires much introduction. To name a few well-known scripts, we can start with these.
i) HTML - a very nice description of this was done by
ii) ASP
iii) Javascript
iv) PHP
v) CGI
vi) LDAP
Again, we can better fence them off by input validation and sanitization.
d) File injection
Known as
remote file inclusion and usually associated with CMS components. This attack could cause one or combination of damage from the list.
i) server-side code execution
ii) client-side code execution, followed by XSS
iii) DoS
iv) data disclosure
If you start to feel this post sways from its purpose, please don't. By now, you get to familiarize what can you see and look out for specific things in your existing IPS traffic. I guess we already have more than enough confidence to suspect all inbound and outbound data and we need to ensure adequate and sufficient filters are enabled. By adequate means we are not disrupting any legitimate flow and by sufficient means you have got to make sure to follow up the logs and/or packet captures gathered by these filters.
