Scott Sutherland discusses penetration testing thick applications. He explains why these applications create unique risks compared to web applications due to users having full control over the application environment. This allows attacks on trusted components, exposure of data and admin functions, and privilege escalation. Sutherland outlines the goals and process for testing thick applications, including common architectures, accessing the application, and testing the application's GUI, files, registry, network traffic, memory, and configurations to identify vulnerabilities.
2. Who am I?
Scott Sutherland
Principal Security Consultant
• Penetration Testing
‒ Networks
‒ Web apps / services
‒ Thick apps
• Community Stuff
‒ Researcher
‒ Blogger
‒ Tool smith (or smithy if you like)
‒ Twitter stalker: @_nullbind
3. What are we going to talk about?
• Why should you care
• Testing Goal and Objectives
• Project Scoping
• Common Architectures
• Accessing the Application
• Testing Requirements
• Application Walkthrough
• Managed vs. Unmanaged
• Testing the Application
• Vulnerability Categories
• Reporting
4. Why am I talking about this?
Thick applications create unique
risks that web applications don't.
5. Why am I talking about this?
Users often have full control over the
application environment which:
‒ Allows attacks on trusted
components
‒ Exposes data, admin/hidden
functions
‒ Leads to application and OS privilege
escalation
6. Why am I talking about this?
Thick applications are the new web
applications.
7. Why am I talking about this?
Publishing thick applications via Terminal
Services and Citrix: Good Stuff
‒ Helps meet client demand for “cloud
services”
‒Converts Client/Server model to SaaS
model
‒Cheaper/Faster than developing
actual web based solution from
scratch
8. Why am I talking about this?
Publishing thick applications via Terminal
Services and Citrix: Bad Stuff
‒Very hard to secure published
desktops/applications
‒Commonly results in direct database
access
‒Often exposes internal networks of
service provider
9. Testing Goal & Objectives
Goal:
Determine what risks the application implementation
presents to the business so they can be mitigated.
Objectives:
Identify vulnerabilities that may exist in:
‒ The client application and server components
‒ The workstation or published application configuration
‒ The server or network configuration
10. Scoping Projects
Estimate effort:
‒ Number of forms
‒ Number of files
‒ Number of registry keys
‒ Number of user levels
‒ Application architecture
‒ Application technology
‒ Constraints
‒ Environment
Generally…
‒ More stuff = more time
‒ More complexity = more time
11. Common Architectures
Desktop Client Remote Database
‒ Usually entire implementation is on internal network
Desktop Client local DB Remote Database
‒ Local db typically syncs with remote db
‒ Usually client and local db are on internal network
remote db is hosted by service provider
Desktop Client Application Server Database
‒ Usually client in on internal network and app/db server
is located is hosted by service provider
‒ Common technologies: Web Services, Web
Applications, JBOSS, and IBM WebSphere
12. Common Architectures
Terminal Services Application
‒ RDP Terminal Server Published app
‒ Website RDP Terminal Server Published app
Citrix Application
‒ Citrix client Terminal Server Published app
‒ Website Citrix client Published app
Thin Application
‒ VMware application
‒ Hyper-V application
13. Accessing the Application
• Install locally, and test over VPN
• Install locally, and test over the internet
• Test over VPN, RDP to a client system,
and install the tool sets for testing
• VPN + Terminal Services (TS)
• Web based TS
• VPN + Citrix Client
• Web based Citrix
• Run from network share
14. Testing Requirements
Minimum Requirements:
• 2 application credentials
for each role
• Application Access
Potential Requirements:
• VPN access
• Local administrator
on client test system
• Internet endpoints
• Installation package
15. Application Walkthrough
• Verify connectivity to application
• Verify all credentials
• Walk through common use cases
• Identify potential areas of client concern
• Better understand application
architecture
17. UNMANAGED CODE APPLICATIONS
• General Information
‒ C and C++ (“unmanaged” or “native” languages)
‒ Compiled to machine code
‒ Include exportable functions
• Pros
‒ Typically run faster due to pre compiled code
‒ Can’t be easily decompiled to the original source code
• Cons
‒ Architecture specific
‒ Disassembly and reassembly is still possible
‒ API hooking is still possible
18. MANAGED CODE APPLICATIONS
• General Information
‒ Frameworks: .net (C# VB), Java Runtime, Dalvik
‒ Compiled to bytecode
‒ Usually does not include exportable functions
‒ Uses reflection to share public functions
• Pros
‒ Architecture independent
‒ Can be coded in different languages
‒ Can access unmanaged/native code
• Cons
‒ Slower due to Just in Time (JIT) compiling
‒ Disassembly and reassembly of CIL code is still possible
‒ Decompiling via reflection is still possible
‒ Global Assembly Cache (GAC) poisoning is possible
‒ API hooking is still possible
19. Attack Vectors
The usual suspects:
• Application GUI • Network traffic
• Files and folders • Application memory
• Windows registry • Configurations
20. Application Test Plan
Create a test plan and follow it…
• Address high priority test cases identified by
clients and business owners first
• Testing can be broken out by vector:
‒ GUI Review
‒ File Review
‒ Registry Review
‒ Network Review
‒ Memory Review
‒ Configuration Review
21. How far do we take this?
Stay in scope!
• That means only networks, servers, and
applications defined by the client
• On in scope systems:
‒ Application admin = yes
‒ Database user = yes
‒ Database admin = yes
‒ Local OS admin = yes
‒ Remote OS admin = yes
‒ Domain Admin = yes
(IF logged into system)
…then no more escalation
22. Testing the Servers
• Automated authenticated scanning
‒ Multiple tools
‒ Multiple rounds
• Manual testing using standardized
penetration test approach
‒ Information Gathering
‒ Vulnerability Enumeration
‒ Penetration
‒ Escalation
‒ Evidence Gathering
‒ Clean up
23. Testing the Application: GUI
• GUI object privileges
Show hidden form objects
Enable disabled functionality
Reveal masked passwords (GUI B GONE)
• GUI content
Review for sensitive data and passwords
• GUI logic
Bypass controls using intended GUI Functionality
Common Examples:
‒ SQL query windows
‒ Access control fields
‒ Export functions allow more access to data
‒ Break out of Citrix and Terminal Server applications
‒ External program execution
24. Testing the Application: GUI
Tool Description
UISpy Enable disabled functions, and call actions related to disabled functions.
Show hidden objects, enabled disabled objects, execution functions, and generally
WinCheat manipulate remote form objects.
View form object properties including the value of masked password fields, and mask
Window Detective card numbers.
25. Testing the Application: Files
• File permissions
Files and folders
• File Integrity
Strong naming, Authenticode signing
• File content
Debugging Symbols/files, sensitive data, passwords, and settings
• File and content manipulation
Backdoor the framework
DLL pre loading
Race conditions
Replacing files and content
Common Examples:
‒ Application settings
‒ Trusted paths and executables
‒ Trusted hosts
‒ Update servers
‒ Passwords and Private keys
26. Testing the Application: Files
• Exported Functions (usually native code)
Identify and run exported functions without authenticating
• Public Methods (managed code reflection)
Create a wrapper to access public methods without authenticating
• Decompile and Recompile
Recover source code, passwords, keys, and create patched assembly
• Decrypt and Deobfuscate
Recover source code, passwords, keys, etc
• Disassemble and Reassemble
Create patched assembly
27. Testing the Application: Files
Tool Description
AccessEnum, Privesc, autoruns, Dump file, registry, and service permissions. Also, review scheduled tasks excessive privilege and write script
schtasks locations.
.Net Reflector, Reflexil, ildasm, IL_Spy,
Decompile or disassemble binaries to recover source code, IL code, or assembly code. Use code review tools to
Graywolf,JD Java decompiler, java byte identify vulnerabilities, and review for sensitive data such as passwords, private keys, proprietary algorithms.
code editor, Metasm, CFFExplorer
Reflexil .net reflector plugin, Graywolf De obfuscate decompiled assemblies
Review exports, view/edit imports, edit and extract resources, view disk/memory usage to identify compression,
CFF Explorer, dllexp disassemble binary, and finger print language
MSFpayload. MSFencode, and MSFVenom can be used to generate shell code, DLL and EXE payloads for
Metasploit injection and side loading. This also ships with METASM ruby library that can be used to disassemble and
compile binaries
Process Explorer View image file settings, process, connections, threads, permissions, strings from process, environmental
variables
View DEP/ASLR settings, image file settings, process, connections, threads, permissions, strings from process,
Process Hacker 2 environmental variables
Process Monitor, API Monitor Monitors calls to file, registry keys, and sockets. API monitor does what it sounds like.
Spider2008 Search file system for interesting strings with regular expressions
Strings Dump strings from files
Symantec EPP Scan all files for know malware
PE Explorer Detect compiler or packer type and version
UPX, MPRESS, Iexpress, 7zip Decompress/unpack binaries and other files
Visual Studio, Ilasm, Metasm, winhex Edit exported .net reflector projects, IL, or assembly and create patched executables.
28. Testing the Application: Registry
• Registry permissions
Read and write access to registry keys
• Registry content
Sensitive data, passwords, and settings
• Registry manipulation
Bypass authentication and authorization
Replace content
Common Examples:
‒ Application settings
‒ Trusted paths and executables
‒ Trusted hosts
‒ Update servers
‒ Passwords
‒ Private keys
29. Testing the Application: Registry
Tool Description
Tools:
AccessEnum Dump file and registry permissions
Regedit Backup, review, and edit the registry
Regshot Registry diffing tool.
Process Monitor Monitors calls to file, registry keys, and sockets
30. Testing the Application: Network
• Network Rules
Local and network firewall rules
• Network content
Sensitive data, files, passwords, and settings
• Network manipulation
Bypass authentication and authorization (SQL)
Replacing content (Parameters)
Common Examples:
‒ Application settings
‒ Trusted paths and executables
‒ Trusted hosts
‒ Update servers
‒ Passwords
‒ Private keys
• Reverse and Fuzz Proprietary Protocols
31. Testing the Application: Network
Tool Description
Cain Can be used for ARP based man in the middle attacks. Can be used to parse password in live traffic or a pcap file.
Burp Can be used to manipulate HTTP traffic.
Metasploit Create custom fuzzer for RPC protocols.
Sully Create custom fuzzing templates.
Echo Mirage Generic TCP proxy.
Ettercap Can be used for man in the middle attacks. Can be used to modify traffic in transit with filters.
Evilgrade, interceptor-ng Tool for delivering Metasploit payloads instead of legitimate updates.
Network Miner Parse network traffic for files, systems, and shares.
oSpy, API Monitor 2 Dump data like encrypted SSL traffic and connection strings when DLL calls are made.
SOAPUI Can be used to interact directly with web services, and is often used with BURP
Web Inspect Service Attack Tool Generic web service review.
Wireshark, windump, Dump all network traffic. Rawcap is the bomb.
tcpdump,Rawcap
32. Testing the Application: Memory
• Process controls
DEP, ASLR, permissions, and privileges
• Memory content
Sensitive data, passwords, and settings
• Memory manipulation
Bypass authentication and authorization
Replacing content
Common Examples:
‒ Application settings
‒ Trusted paths and executables
‒ Trusted hosts
‒ Update servers
‒ Passwords
‒ Private keys
33. Testing the Application: Memory
Run-time Modifications
• Direct editing
• DLL injection
• Shell code Injection
• Process replacement
• Modify assembly in memory
• Identification of dangerous functions
• Check if debugger can be run
• Debugging via stepping and breakpoints
to analyze and modify
34. Testing the Application: Memory
Tool Description
Metasploit Can be used to generate shell code, exe, and DLL payloads. Can also be used to
migrate into a running process.
Process Explorer View image file settings, process, connections, threads, permissions, strings from
process, environmental variables
Process Hacker 2 View image file settings, DEP/ASLR settings, connections, threads, permissions,
environmental variables, inject DLL
RemoteDLL Can be used to inject a DLL into a process.
Tsearch Can be used to quickly find and replace strings in memory.
Immunity, OllyDBG, Can be used to step through the application and modify assembly instructions on the
fly.
Windbg, and IDA
Debuggers
Winhex Can be used to quickly find and replace strings in memory.
Userdump Dump memory from process.
35. Testing the Application: Configurations
• Application user privileges
• Service account privileges
• Service configuration privileges
• Service registration
• Database account privileges
• Remote share permissions
• TS breakouts to OS
• Citrix breakouts to OS
36. Testing the Application: Configurations
Tool Description
windows-privesc- Check privileges on servers and associated program directories, and manually
check check for insecurely registered services.
Citrix Client Used to connect to Citrix applications.
Data Source (ODBC) Look for existing ODBC connection and use tools like excel to leverage them.
Administrative Tool
Services.msc, Review application services for insecure registration, binary paths, and
windows-privesc- determine users who is running the service.
check
SQL Clients Used to connect directly to the database. Examples include OSQL, ISQL,
SQLCMD, RAZOR SQL,TOAD, Microsoft SQL Management Studio Express.
Windows Explorer and Access Windows dialog boxes to obtain access to a cmd console or
common dialog boxes Powershell. Target links, shortcuts, open file functions, export functions,
import functions, and reporting functions. Help menus and verbose error
pages can also be handy.
37. Vulnerability Categories
1. Application Logic
2. Code Injection
3. Excessive Privileges
4. Unencrypted Storage of Sensitive Data
5. Unencrypted Transmission of Sensitive Data
6. Weak Encryption Implementations
7. Weak Assembly Controls
8. Weak GUI Controls
9. Weak or Default Passwords
38. Reporting Stuff
• Create severity ranking system based on
static criteria
• Internally, criteria should take compensating
controls into consideration
• Prioritize findings based on
ranking system
• Include instructions or
screen shots to help
reproduce and fix issues
• Don’t forget recommendations
39. Wrap Up
• General Summary
‒ Attack thick applications and related infrastructure
from many vectors using many tools
‒ Managed code suffers from inherent weaknesses
that can’t be fixed and is easier to attack
• General Advice
‒ Never store sensitive anything in an assembly
‒ If something sensitive “must” be stored in an
assembly use unmanaged coding languages like C
and C++
‒ Be very careful to implement sufficient controls
when deploying thick applications via terminal
services or Citrix