Transcript Click to add title

WEB SYSTEM
Company
LOGO
Components of a Generic
Web Application System
URL Mappings to the Web
Application System
Web Application
Architecture
Web Server vs Web
Application
 Web Server:

Serves client request and forward to proper application for
further processing (e.g. IIS, Apache, thttpd and etc.)
 Web Application:


Using programming language (e.g. ASP, PHP, Java, .Net, Perl or
C) to
implement business logic and serve the client
 Web Application does not run without Web Server
 Web Server does run without Web Application (Serving
static content)
 Web Application should contain:



Web Server and underlying OS
Web Application Code
Backend Server
Web Server Vulnerability
 Can be identified by:


Port scan for web related ports (TCP 80, 443 and etc)
Vulnerability scanner (Whisker.pl, N-Stealth, Nikto.pl
and others)
 Example:

IIS
 File system traversal vulnerability
 Unicode and superflous decode vulnerability
 Various buffer overflow in ISAPI filters (.ida, .printer, WebDAV
and etc)
 Impact:

Usually the attacker can take over the system running
the web server
Web Application
Vulnerability
 Vulnerability on web application itself
 Can be identified by:


Source code review
Application testing
 Automatic scanner
 Manual testing
 Example:



SQL or command Injection
E-Shop lifting
Passport reset password flaw
 Impact:


Data confidentiality and integrity breached
System compromised
Flowchart for a One-Way
Web Hack
 We need two things
to make an effective
 attack:


Interactive terminal
access
Ability to transfer files
Step 1: Finding the Entry
Point
 URL parsing vulnerability


n Unicode / Double decode attack
http://www1.example.com/scripts/..%c0%af../winnt/system32/cmd.Exe?/C+copy+c:\winnt\sys
tem32\cmd.Exe+c:\inetpub \scripts
 Parameter parsing vulnerability
 Example: script uses open() insecurely

http://www2.example.com/cgibin/news.cgi?story=101003.txt|cp+/bin/sh+/usr/local/apache/cgi-bin/sh.cgi
 SQL Injection
 Etc…
Invoking the Command
Interpreter
Invoking the Command
Interpreter, con’t
 Care must be taken to get cmd.exe to
receive commands properly


Content-length must be right
Remember to run “exit” command
 Make a script to automate POSTing
 commands
 This can be done for /bin/sh, too
Web Based Command
Prompt
 POSTing commands isn’t desirable

We want to run commands interactively
 And we don’t want to trip an IDS or get blocked by
a firewall
 Solution: web based command prompt
Web Based Command
Prompt (WCP)
Installing the Web Based
Command Prompt
 How do we get our script on the server?
 Use our script for POSTing commands
 Script files: write to a file one line at a time
using “echo”

Script files usually don’t need extra
permissions
 Binary files: on certain shells you can echo

arbitrary characters to a file
 echo -e
"\x0B\xAD\xC0\xDE\x0B\xAD\xC0\xDE\x0B\xAD\x
C0\xDE" > file
Uploading Files
 We’d also like to upload files to the server
 FTP, NFS, NetBIOs aren’t good to use for obvious
reasons
 Create a file uploader script in your favorite
language
 Get it on the server the same way as the web
based command prompt
Now what?




Now we can do all sorts of fun stuff!!!
Find source code of web apps
Find server configuration files
Try to perform privilege elevation attacks
that work locally
 Screw with the database
Hacking IIS5(windows 2000
server) via unicode bug
 Cari file html disimpan
Hacking IIS5(windows 2000
server) via unicode bug
 Jalankan cmd.exe
Hacking IIS5(windows 2000
server) via unicode bug
 Copy file cmd.exe
Hacking IIS5(windows 2000
server) via unicode bug
 IT’S SHOW TIME ..
Hacking IIS5(windows 2000
server) via unicode bug
 Deface time
SQL Injection
 Hackers typically test for SQL injection vulnerabilities by
sending the application input that would cause the server
to generate an invalid SQL query.
 If the server then returns an error message to the client,
the attacker will attempt to reverse-engineer portions of
the original SQL query using information gained from
these error messages.
 The typical administrative safeguard is simply to prohibit
the display of database server error messages.
Regrettably, that’s not sufficient.
 If your application does not return error messages, it
may still be susceptible to “blind” SQL injection attacks.
Solution
 To secure an application against SQL injection,
developers must never allow client supplied data to
modify the syntax of SQL statements.
 In fact, the best protection is to isolate the web
application from SQL altogether.
 All SQL statements required by the application should be
in stored procedures and kept on the database server.
 The application should execute the stored procedures
using a safe interface such as JDBC’s
CallableStatement or ADO’s Command Object.
 If arbitrary statements must be used, use
PreparedStatements.
 Both PreparedStatements and stored procedures
compile the SQL statement before the user input is
added, making it impossible for user input to modify the
actual SQL statement.
Web Application
Vulnerability




Application Design
Application Implementation
Application Deployment
Infrastructure Configuration
Application Design
 Vulnerability in the stage of application
design
 Examples:




Weak password (policy)
No protection (Encryption) on confidential
data
Bad choice on using cryptography
Weak authentication/authorization mechanism
Application Deployment
 Transition of application state (e.g. from
test to production)

Did not strip out information
 Test/Guest accounts
 Test information
 Debug configuration
 Account/Password information

No audit/test before deployment
 Deployed bugged version

Expose test environment
Find Web Application
Vulnerability
 How Do You Find Web Application
Vulnerability Today?
 Raise Your Hand If You Use Automatic
Tool!
 Raise Your Hand If You Use Manual
Test!
 Raise Your Hand If You Don’t Use Any
of Them!
Assesment Plan
 Do You know what will be tested?
 Do you have control to add or delete the
test?
 Who is making the plan?
 What is the methodology?
 What is the knowledge base?
Accuracy
 How accurate is the result?

Can any tool identify “ANY” of the case study
we are going to talk about?
 Is it confused by your customized error
page?
 Can it login into your HTML Form-based
authentication application?
 Can it assess authorization or access
control problem?
Accountability &
Traceability
 Can you verify or reproduce any single
vulnerability found?
 How easy/hard would that be?
 Can you identify what is the risk brought to
you by the vulnerability?
 Can you change/define how the risk is
calculated?