Home    Victim´s Story   Fraud Prevention    Project GSO   Hall of Shame   LINKS  

Global Scambaiting Forum  

 
 

 

 

 

 

 

 

 






SPEAR PHISHING SCAM III



Traffic Analysis




 

Traffic analysis is a special type of inference attack technique that looks at communication patterns between entities in a system. "Traffic analysis is the process of intercepting and examining messages in order to deduce information from patterns in communication. It can be performed even when the messages are encrypted and cannot be decrypted. In general, the greater the number of messages observed, or even intercepted and stored, the more can be inferred from the traffic. Traffic analysis can be performed in the context of military intelligence or counter-intelligence, and is a concern in computer security."[1] Knowing who's talking to whom, when, and for how long, can sometimes clue an attacker in to information of which you'd rather she not be aware.


The size of packets being exchanged between two hosts can also be valuable information for an attacker, even if they aren't able to view the contents of the traffic (being encrypted or otherwise unavailable). Seeing a short flurry of single-byte payload packets with consistent pauses between each packet might indicate an interactive session between two hosts, where each packet indicates a single keystroke. Large packets sustained over time tend to indicate file transfers between hosts, also indicating which host is sending and which host is receiving the file. By itself, this information might not be terribly damaging to the security of the network, but a creative attacker will be able to combine this information with other information to bypass intended security mechanisms.


SecurityFocus ran an article on a "method based on traffic behavior that helps identify P2P users, and even helps to distinguish what type of P2P applications are being used."[2] In this case the focus was on the default port numbers these tools use, though there are more sophisticated methods using flows.[3]


TCP/IP lends itself to traffic analysis to the point that it is possible to "fingerprint" (determine the host operating system by looking at packets on the network) systems. Fyodor's NMAP site has a tutorial[4] that explains this in detail, but NMAP works by sending packets to stimulate the host. It is also possible to passively fingerprint; commercial tools to passively fingerprint include SourceFire's RNA[5] and Tenable's Passive Vulnerability Scanner.[6] A powerful free tool call P0f[7] is also available. According to the Honeynet project, the following fields are crucial in OS fingerprinting.[8]


-  TTL - What the operating system sets the Time To Live on the outbound packet
-  Window Size - What the operating system sets the Window Size at.
-  DF - Does the operating system set the Don't Fragment bit.
-  TOS - Does the operating system set the Type of Service, and if so, at what.
-  Attackers would commonly use traffic analysis in addition to some other method of attack, it is most useful for reconnaissance, to find vulnerable hosts for instance, or potentially in competitive intelligence to determine characteristics of someone else's system. However, in the case of insiders or authorized users you have the "inference problem, wherein authorized users are able to make valid deductions, based only on data they are authorized to access, about data they are not authorized to access."[9]


Fortunately, traffic analysis can also be used as a defensive technique by identifying anomalies in traffic patterns. Using traffic analysis, administrators can baseline the traffic to and from hosts on the network over time, in a graphical format (line charts or other graphs). As a daily routine, the administrator can review these charts and see patterns in network activity to and from hosts and networks, including packet quantity, packet sizes, bandwidth utilization, connections per hour, etc. After becoming familiar with the baseline utilization of the network, an administrator will be able to quickly spot anomalies in connections between hosts and networks such as port-scans, DoS attacks, significant increases in bandwidth utilization, and other factors that might indicate hosts that are under attack or have become compromised.


These days there are a number of freeware and commercial tools that can perform passive operating system fingerprinting. Not only can they identify the OS, but they are often able to track the versions of operating systems.


1. http://en.wikipedia.org/wiki/Traffic_analysis
2. http://www.securityfocus.com/infocus/1843
3. http://www.cert.org/flocon/2005/presentations/Wagner-HeavyHitters-FloCon2005.pdf
4. http://insecure.org/nmap/osdetect/
5. https://www.sourcefire.com/products/3D/rna
6. http://www.tenablesecurity.com/products/pvs.shtml
7. http://lcamtuf.coredump.cx/p0f.shtml
8. http://www.honeynet.org/papers/finger/
9. http://www.cip.umd.edu/reports/ISOO_report_final.pdf



Alteration Attacks



Alteration attacks are just what they sound like; they occur when someone makes unauthorized modifications to code or data, attacking its integrity. These attacks can take many different forms and have a variety of consequences. An organization might have a Software Development Life Cycle, but the binary code can be altered. A person with access can recompile an existing program to add another library or DLL, or use a binary editor like HT Editor.[1]


"Self-modifying code is quite straightforward to write when using assembly language (taking into account the CPU cache). It is also supported by some high level language interpreters such as SNOBOL4, the Lisp programming language, or the legendary ALTER verb in COBOL. It is more difficult to implement on compilers but compilers such as Clipper and Spitbol make a fair attempt at it, and COBOL almost encouraged it. Batch programming scripts often involve self-modifying code as well."[2] While there are some valid reasons to write self modifying code, from a security perspective, this isn't something we consider good practice since the application could be an unknown, or in an unevaluated state. Here is what Dennis Ritchie, one of the greatest software developers, had to say about a variant of self modifying code, Just in Time compilation:


-  We've flirted with, embraced, and pulled away from the idea
-  of this cyclically over the years. (Ken Thompson's compilation
-  of code for recognizing regular expressions was one of
-  the early software patents (#3568156, 1971)) and Reiser's
-  bitblt was the first of several local implementations of the idea
-  for doing low-level graphics operations.[3]


The place where code is altered and not managed is one of the biggest non-attacker driven problems. Maintenance code is often not subjected to scrutiny. Failures to check inputs and removal of security design measures can happen during this period. Often, the programmers assigned to update or maintain code have less ability and training than an initial implementation team. If your organization is starting to train your developers in software security, make sure all the developers get trained. Otherwise, the security effort you put into the design may be undone during a maintenance phase.


Alteration attacks apply to data as well as code, in fact even more so. For example, what if an attacker defaced your organization's web site in a very subtle manner? Instead of posting a trite message about how your site was 0WN3D and that you suck, they may stealthily modify the numbers in your last quarterly report to make it look like business was very poor in order to drive your stock price down.


Or maybe you caught the latest web server worm. Worms are definitely alteration attacks because they have to modify something on your system in order to work. However, coupled with rootkit technology they may be able to avoid detection. Malware has been a primary vector for integrity attacks for a very long time. Consider the following from F-Secure on the Brain virus from 1986, "The Brain virus tries to hide from detection by hooking into INT 13. When an attempt is made to read an infected boot sector, Brain will just show you the original boot sector instead. This means that if you look at the boot sector using DEBUG or any similar program, everything will look normal, if the virus is active in memory. This means the virus is the first 'stealth' virus as well."[4]


The primary defense against an alteration attack is a cryptographic hash. If you can record the state of a program or data before it is altered and securely store the hash, you can periodically recheck the program or data and compare it with the stored hash. SHA 2 is recommended for the hash algorithm. As NIST says, "The SHA-2 family of hash functions (i.e., SHA-224, SHA-256, SHA-384 and SHA-512) may be used by Federal agencies for all applications using secure hash algorithms. Federal agencies should stop using SHA-1 for digital signatures, digital time stamping and other applications that require collision resistance as soon as practical."[5]


1. http://www.acm.uiuc.edu/sigmil/RevEng/ch09.html
2. http://en.wikipedia.org/wiki/Self-modifying_code
3. http://yarchive.net/comp/self_modify.html
4. http://www.f-secure.com/v-descs/brain.shtml
5. http://csrc.nist.gov/CryptoToolkit/tkhash.html


 More


 
 
 

 Top

 
       
© 2006-2010 by GSO •  Contact