Friday, February 11, 2011

Ineffectiveness of AntiVirus Solutions

Many recent high profile attacks into major software companies, public sector institutions and international organizations.
–Aurora attack on Google and 32 other companies last year
–In all cases: malicious email was sent to victim

Email-borne threats fall into two general categories:
–Mass email attacks
–Targeted attacks
Traditional AV increasingly ineffective and heuristic engine is necessary.

Typical Bredolab/Trojan.Sasfis
Most prolific family of mass-mailed threats using executable attachment.
Social engineering lures:
–Social Media website password reset
–Western Union or UPS invoice
–"You have received an E-Card!"
–Spammed out in very large numbers (Cutwail botnet)
–Many different payloads
–13.3% of all Malware stopped by Skeptic
–Between June 2009 and June 2010 (excluding Phish and links)
–Typically low AV detection (< 10 on VT)
–Good social engineering tactics
–Use of Word or Excel icons
–Spoof prolific companies (Facebook, UPS, Fedex)
–Heavy use of server-side polymorphism (SSP) to evade signature-based AV




Signature-based AV
–Create a "signature" for a piece of Malware
–String(s) of bytes
–Checksum(s)
–Very specific
–Evidence of increased use of SSP
–In 2008, Symantec created 1,691,323 new malicious code signatures
–In 2009, 2,895,802 new signatures were created (71% increase)
–139% increase from 2007 to 2008
–Not sustainable!
–Solution: heuristic-based approach

Signature Development Process


Heuristic-based Approach
–Generic detection
–Features known to exist in Malware
–Decision based on extracted features
–Weighted
–Cloud based
–no reactive signature deployment delays

Polymorphic Viruses
–Big problem for AV
–Many different variants
–Functionally equivalent
–Signatures required for each variant
–Solution: "emulation"
–Emulate past decryptor stub
–Sig the static virus body

Server-side polymorphism (SSP)
–Custom encryption routine
–Decrypt at runtime
–Generated by a polymorphic engine
–Hundreds or perhaps thousands of unique variants
–Random junk instructions
–API calls
–Arithmetic
–EP

Use in mass-email attacks
–Attackers generate a number of unique binaries
–Change the binary being spammed throughout the attack
–Problem for any vendor without proactive protection in place

Bredolab Case Study - 30 March 2010
–Standard Bredolab run:
–Subject: variation of 'UPS Delivery Problem NR 18800'
–Attachment: similarly named 'UPS_invoice_1845.exe'
–relatively small (only 56 observed copies)
–Started at 19:08:33 GMT (time 0)
–Last observed sample at 19:36:31
–Total of 27 min 59s

Case Study - AV Detection & Response Time
–At time 0, AV detection was 0
–Average response time?
–661 minutes (11 hours and 1 minute)
–Remember that the attack only lasted 28 mins
–This is the average response time
–INEFFECTIVE

Aurora and Targeted Attacks (Spear-Phishing)
–Aurora/Hydraq
–Up to 34 different companies compromised in same period using similar techniques
–Email links to malicious web pages
–Flaws in Adobe Acrobat Reader
–Google hackers are back?
–CVE-2010-2883

According to US Department of Defense Cyber Crime Center:
"102 breaches of the Pentagon’s agencies, partners and contractors in a two-year period ending August 2009"




Targeted Attack Case Study - 24 March 2010
–Targeted attack blocked attempting to exploit CVE-2010-0188 (libTiff)
–Single copy sent to an individual in a major international organization
–Co-ordinates governments from around the world
–Trojanized a clean PDF from a World Cup travel site

Case Study - AV Detection & Response Time
–AV detection was 0
–One week later, AV detection at 33%
–Sample sharing, blogged
–Average response time?
–3631 minutes (two and a half days)
–Only takes into account the 33% of vendors that were actually detecting the threat
–INEFFECTIVE

Monday, January 31, 2011

Targeting SAP Platform Using Trojans and Rootkits

Typical Enterprise Environment
-Has more than a thousand of employees
-Is a circus of IT Systems
–Mixture of operating systems, databases, applications and their different versions
-Decision makers care more about their bonus than the interest of the company
-Is a political battlefield

Enterprise Security
Even a medium level of IT security is too expensive to achieve
–Missing asset management (how many Oracle DBs, Windows servers, etc)
–Tons of security scanning, to few remediation chasing
–Many of the vulnerabilities cannot be mitigated
-Obsessed by Cross Site Scripting
-IT security departments cannot influence security decisions of business applications much, because of political reasons.
-Nobody cares about the hacked UNIX machine, SQL DB, or others.
-Defacement and similar security incidents are budget approvers

SAP Systems
-Business specific
-Industry solutions
-Hold the Crown Jewels
-Are usually extensively customized
-Less exposure to typical hackers (ABAP)

SAP Security
-Security mostly focuses on authorizations and segregation of duties
-Intrusion prevention is still a baby
-Risks are underestimated/general IT Security efforts are typically unbalanced at companies
-Unlike e.g Active Directory, SAP systems belong to the business, not the IT
-Security departments usually fail when they are challenged



RFC (Remote Function Call) protocol lets you run functions remotely
–To run; use Java, C, etc. with RFC-SDK or simply execute the test program "startrfc". Following
creates a new user with god rights:

startrfc -3 -h 10.1.5.4 -s 05 -c 010 -u ERTUNGA -p CCC42 -F SUSR_RFC_USER_INTERFACE
-E USER=SATRIANI -E ACTIVITY=01 -E PASSWORD=RUBINA -E USER_TYPE=A -T USER_PROFILES,
12,r=-SAP_ALL


There is no exploit involved. Everything is intended functionality.
–Beats "RFC users are not a threat because they cannot login via SAPGUI"
–Time to recheck company’s shared folders and eliminate hardcoded passwords.

RFC (a.k.a communication) users are thus very very important!
–Secure their passwords and make them part of the password change process
–Don’t forget: GUI (dialog) users which have S_RFC rights can also execute remotely
–SAP_ALL FOR COMMUNICATION USERS IS A NO GO!

RFC_READ_TABLE
Reads the contents of any table (Including ones with sensitive data e.g salary information)
Has bugs in converting e.g binary fields

SUSR_RFC_USER_INTERFACE
Can be used for creating/modifying users

RFC_ABAP_INSTALL_AND_RUN
-Takes ABAP source lines and executes them
-Widely known! tighten user authorizations to prevent abuse
-More restricted in latest NetWeaver Systems

RFC can be encapsulated in SOAP messages (SOAP RFC)
-Company’s internal proxy suddenly opens the doors to all SAP systems
-Disable it if not used!

Single Sign-on (SSO2)
-Is a convenient feature, not a security feature
-RTFM: Secure Store and Forward [SSF] documentation
-Personal Security Environment files hold the private key data
-If an attacker obtains it, it can create authentication tickets for the victim system. Accepting these tickets is enabled per default. Attacker can logon as any user.
-The private key container (PSE) can be pin-protected
-Advice: Disable accepting tickets using relevant profile parameters!

SQL Injection-ABAP typically uses parametrized queries (Developers can still specify parts of sql statements dynamically by parentheses)
-Not dynamic: SELECT ColumnA FROM TableA INTO[...]
-Dynamic: SELECT(var_ColumName)FROM(var_TableName) INTO[...]WHERE(var_WhereClause)
-Avoid dynamic statements where possible!

Cross Site Scripting
-Proper sanitization/encoding of the input data is the key for self developed web code such as BSPs.
-If not done, an attacker can do everything related to XSS, plus steal e.g the SSO2 (Authentication) cookies from the clients SSO2 cookies are stateless so client impersonation is a breeze. Avoid using this mechanism without proper controls.
-If you have F5's or similar devices, encrypt cookies based on origin IP.

ABAP Executable Manipulation
-Statement: INSERT REPORT
-Writes custom code to any ABAP program
-It's even possible to call an editor to make it more user friendly
-Very suspicious if found in self-developed code

RS_REPAIR_SOURCE Executable
-Unpatched version does not have authorization checking.
-People with e.g SE38 rights can execute this and manipulate the system and data of it.
-Same as ABAP injection, only more convenient.
-SAP patched it via: SAP Note 1167258: Program RS_REPAIR_SOURCE

ABAP Rootkits
-It is possible to modify system executables (ABAPs)
-An attacker can easily infect important ones executables and install an ABAP rootkit
-SAP has RFC functions that do not require user authentication by default (SRFC Function Group). This could be one candidate.
-Installed rootkit can give anonymous access to the attacker with functionality such as: Installing
SAP_ALL users, Manipulating ABAP reports, Running OS commands, Stealing hashes or PSE files, Deleting Logs.

Triple-Penetration Attacks
Penetration 1: Attacker exploits the weakest system
-Typical enterprise setup: Testing/Development ­> Quality Assurance ­> Production
-Among them, most unprotected are test/development systems

Penetration 2: Attacker infects clients which connect to the weakest system
–Starts with modification/infection of the critical areas such as logon screen ABAP code
-When admins/developers successfully login, malicious payload is downloaded and executed on these users computers

Penetration 3: Victim infects all the systems it later connects to
-Modification of critical components of the newly accessed SAP systems (Internal production systems, Partner systems, critical systems)



How to stay secure
-Have proper "check-in" and "leavers process" that take the ABAP developer risks into consideration
-Audit the code against security vulnerabilities before transporting to production systems
-Syncing passwords to development systems means, possibility of developers to capture valid passwords for production systems. Avoid it!
-Get rid of insecure and/or default passwords
-Disable backwards compatiability of passwords
-Install the latest security patches