Company LOGO WEB SYSTEM

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  tem32\cmd.Exe+c:\inetpub \scripts  Parameter parsing vulnerability  Example: script uses open() insecurely  bin/news.cgi?story= 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?