Showing posts with label EthicalHacker. Show all posts
Showing posts with label EthicalHacker. Show all posts

Tuesday, September 15, 2009

Malware Analysis Tools and Techniques

Malware Analysis Tools and Techniques


Apart from what guidelines have been published in various books and articles. My this post will summarize the overall manual and automated techniques to simulate and test the samples of malwares collected and their behavioral activities. To be noted that a "Malware" could be delivered in the form of trojan, virus or worm.

Manual Toolset
These tools require the collaboration of other toolset used in conjunction, to support depth analysis of a malware.

Foundstone BINTEXT
Malzilla (Analyzing Web-Based Malwares - JavaScript/iFrame)
HTTP Proxy Debuggers (Paros, WebScarab)
Nepenthes
iDefense SysAnalyzer, HookExplorer and MAP (Malcode Analyst Pack)
RegShot
SysInternals Tools
PEiD Tool (Very important to detect packers/compilers/cryptors)
UPX
FireBug
OllyDbg
WinDbg
GDB GNU (Linux)
OllyDump
OllyScript
SoftICE (Reversing)
IDA Pro (Reversing)
Salamander Decompiler (.NET Applications)
Reflector.Net Tool
DaFixer's DeDe (Delphi)
Backerstreet.com REC
HeavenTools PE Explorer
HijackThis

Automated Online Tools
These online submission services automatically analyze the malware in a very restricted environment(simulate) and record their activites and produce results on the basis of various Anti-Virus/Malware detection.

CWSandbox.org
ThreatExpert.com
VirusScan.jotti.org
Norman.com/microsites/nsic/
Malwareinfo.org
VirusTotal.com
VirScan.org

Source: EthicalHacker.

Friday, September 4, 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
-Misconfigurations
-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
-Automated Dynamic Tests (Fuzz Testing, Vulnerability Scanning)
-Automated Static Tests (Source or Binary Code Scanning)

Manual
-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.

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

Weaknesses
-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.

Strengths
-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

Weaknesses
-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.

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

Weaknesses
-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).

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

Weaknesses
-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).

Source: EthicalHacker.

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.

-NMap
-rsh,rlogin,rexec
-BurbSuite
-W3af
-Nessus
-JTR (John The Ripper)
-THC Hydra
-SQL Client Tools
-NFS Client Tools
-Sapyto
-Metasploit

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.

Countermeasures

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.

Source: EthicalHacker.

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 - http://www.cloudsecurityalliance.org
[2]ENISA Cloud Security Working Group - http://www.enisa.europa.eu

Source: EthicalHacker.

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)
{
$a++;
}
$z = 7;
// pass $z as a reference
increase(&$z);
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

Source: EthicalHacker.