Transcript 2004-05-07-MAEDS

Web Application Security, I.T.
Logging and Log Analysis
May 7th, 2004
Mark Lachniet, Analysts International
Introductions
• Mark Lachniet, Technical Director of Analyst
International’s Security Services Group
• Technical lead developing for services,
methodology, quality control, technical presales
• Certified Information Systems Auditor (CISA)
from ISACA
• Certified Information Systems Security
Professional (CISSP)
• Linux LPIC-1, Novell Master CNE, Microsoft
MCSE, Checkpoint CCSE, TruSecure ICSA, etc.
• Former I.T. director of Holt Public Schools
• Frequent speaker for local organizations
Agenda
•
•
•
•
•
•
•
Web Application Security
The forensic approach to logging
The Syslog protocol
UNIX logging
Windows logging
Resources
Q&A / Discussion
Conceptual Overview of Web Apps
• Web applications are
generally developed
in Tiers
–
–
–
–
User / Client
Web Server
Business Logic
Database
• In many cases, the
database is the same
one that holds other
critical organizational
data!
Logical / Physical Overview
• Let us pretend that we are looking at a State of
Michigan web site (note: this is only pretending!!)
• The purpose of the web site is to allow “self service”
access to Human Resources information:
–
–
–
–
–
Pay stubs, deductions, direct deposit bank name
Demographic information
Emergency Contact information
Education
Dependants (names, ages)
• The application was written by a combination of
internal and external programmers
• The application was written in Microsoft .NET, and
communicates with the actual State of Michigan
Human Resources HRMN system
Logical / Physical Overview
Demonstrative Web
Application Diagram
Self Service
Web Server
Bad Person
DMZ Network
(Internet Accessible Machines)
The Internet
Internet Router
Company Firewall
Human Resources
Database
Internal Network
(Protected Machines)
Good Person
Implications
• In order for this all to work, the HRMN system
needs to trust the self service web application to
access data
• Thus, the program logic of the self service
application may be critically important, responsible
for ensuring that:
–
–
–
–
Users are properly authenticated
Users are authorized to use the system
Adequate logging of activity takes place
The Internet-facing components do not have known
security flaws
• In short, a part of the security of the human
resources database now lies in an Internet-facing
web application, possibly bypassing the more
established and mature database security
• What could possibly go wrong?
What Can Go Wrong???
• Frankly, a lot…..
• Secure programming practices have not really been
taught in higher education
• Productivity pressures have made security a
secondary priority
• A lot of insecure web sites have been implemented
• In fact, a recent study found that no less than 92% of
web pages surveyed over a 4-year period had serious
security flaws
http://www.vnunet.com/News/1152521
• Are you confident that your web site is within the
fortunate 8%?
• If you don’t have an explicit set of controls for
application development, security and ongoing
testing, you shouldn’t be!
Types of Flaws in Web Applications
•
Lets look at the statistics from the
previously quoted article:
1.
2.
3.
4.
5.
6.
7.
•
•
•
Cross-site scripting (80 per cent)
SQL injection (62 per cent)
Parameter tampering (60 per cent)
Cookie poisoning (37 per cent)
Database server (33 per cent)
Web server (23 per cent)
Buffer overflow (19 per cent)
My personal experience indicates that these
numbers are about right
Any one of these flaws could lead to a
disclosure of critical or protected data
Lets look at a few examples
Cross-Site Scripting
• Occurs when input from a user is not “sanitized”
before being re-displayed on a web site
• For example, an Internet guest book may allow you
to enter a message, along with the time and date that
you visited a web site
• It may be possible to craft this message in such a
way that users’ Internet browsers interpret the
message as HTML code, instead of plain text
• If this happens, person A can make it appear to
person B’s computer that a web site (presumably a
trusted one) is the source of a tricky attack
• This commonly used to do things like steal
authentication information, or redirect to a
“phishing” web site to harvest passwords, credit card
numbers or bank account numbers
Real Life Example of CSS
• While working for a customer, analyzing a well known
SSL VPN appliance, I discovered a CSS bug
• I then created a proof of concept to demonstrate this bug
• I created a (virtually) identical copy of the VPN server’s
login page, and put this on a server that I had control of
• I then created a special CSS web address (URL) that,
when entered, would redirect the user transparently to
this external web site
• The fake web site said “session has timed out, please log
in again” message, and had a place to log in again
• When the user entered their username and password on
the fake login, this information was written to disk on my
“hacker” computer, and the user was redirected back to
the *real* VPN server’s “incorrect password” page
• The end user would simply think that their session had
timed out, and that they had mis-typed their password
SQL Injection
• The next most common flaw, SQL injection, is worse
• In this case, a hacker would find a part of the application
code that did not perform proper input sanitization
• By passing special characters in form fields (e.g. a place
to type in a query or address) it is then possible to embed
additional commands for the HR database
• Since the application server is “trusted” by the back end
database, it assumes that the request is legitimate and
performs the query
• The “normal” results, as well as the database commands
entered by the hacker are displayed in the browser
• This attack can be used to completely bypass application
and database security
• In our working example, an identity thief hacker could
then print out the names, SSN#’s and addresses of all
employees and use this to steal their ID
Real Life Example of SQL Injection
• While analyzing a production Internet web site during a
WASA (Web Application Security Analysis) I discovered
a SQL injection flaw in the application code
• With this knowledge, I configured a program called “data
thief” to assist me in demonstrating the vulnerability
• Using data thief, I was able to copy the entire back-end
database, with all of the data, including usernames and
passwords, across the Internet to my computer
• Using this database of logins and passwords, I was able
to log in, and access the application as an administrator
• At that point, I also had the ability to run software on the
database server, which was on the internal, protected
network
• If I were a bad guy, I could have used this access to
compromise additional systems on the Internal network
Real Life SQL Injection Example
Other Web Application Risks
• There are a number of other risks that need to
be looked at:
–
–
–
–
Ability to bypass authentication systems
Ability to steal user “sessions”
Flaws in the underlying operating system / web server
Flaws in the “chain of trust” (relying on an additional
system for some security component such as a SSO
(Single Sign On) system)
– Flaws that allow a hacker to deny service to the
system (e.g. by using all of the licensed connections,
flooding the server, or causing a software crash)
– Reliance on client-side security (especially client-side
scripting)
• And so on….
Security Best Practices
• A lot of information is available for programmers,
auditors and I.T. staff on web application security issues
• The most referenced one is the Open Web Application
Security Project at http://www.owasp.org
• OWASP has specific guidelines for what programmers
should and shouldn’t do, as well as detailed information
on what the issues are and how they can be detected
• For more information on how to go about assessing an
application using accepted methods, check out “Open
Source Security Testing Methodology Manual” at
http://www.isecom.org/projects/osstmm.shtml
• A number of product-specific web sites for major vendors
also exist. A good one for both theory and practice is the
Microsoft “Building Secure ASP .NET Applications”
600pg PDF at:
http://www.microsoft.com/downloads/details.aspx?displaylang
=en&FamilyID=055FF772-97FE-41B8-A58C-BF9C6593F25E
Why Logging?
• http://www.cerias.purdue.edu/homes/rgk/at.html
– Individual Accountability
– Reconstructing Events
– Problem Monitoring
– Intrusion Detection
• The presence of a good logging system can also
be a deterrent
• Forensic evidence
• Logging should be required through
organizational policy!
The Forensic Approach to Logging
• As a security analyst, I analyze a lot of
intrusions after the fact
• Almost always, there is very limited information
to use in recreating the nature of a compromise
• In an environment with good internal controls, it
may be possible to find a great deal of
information, on many disparate systems
• The goal here is to be able to recreate the
sequence of events that lead to an incident
• Due to the fact that many incidents occur in
ways that don’t leave a trail (e.g. a security flaw
in an application) we must cover as many bases
as possible
Common Sources of Logging Data
Log Data and Formats - Syslog
• There are a lot of places where log data can be
gathered, and they don’t all use the same
protocol
• Historically, the most commonly used format for
logging is Syslog (from the UNIX world)
• Syslog works as a network-aware component,
with both a server and client programs
• The server may be UNIX syslogd, Kiwi, or a
similar “listener” that logs data or takes action
• Syslog servers typically listen on UDP port 514,
and transmit data in an unencrypted format
• Connections may be made over a physical
network, or via a local loopback address
• Log entries are analyzed and processed
Log Data and Formats – Syslog Cont.
• Based on its configuration, actions may be taken:
– Write to file (one or more)
– Send to another syslog server
– Perform an action (send an e-mail or page, play a
sound file, log to a database, etc.)
• Syslog uses two criteria for its alerts – facility and
level – usually denoted in a format such as:
– mail.info (routine mail entry - log to mail log)
– kern.crit (kernel emergency! Email admin)
• These criteria aren’t really implemented in a
standard way across operating systems, but you can
use them for your own purposes
• Note: Old syslog has poor security – you need
another layer of security such as hostname / IP
filtering, or use a better product such as Syslog NG.
Example /etc/syslog.conf
# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.*
/dev/console
# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none; authpriv.none;cron.none /var/log/messages
# The authpriv file has restricted access.
authpriv.*
/var/log/secure
# Log all the mail messages in one place.
mail.*
/var/log/maillog
Example Syslog File
Security
Info
System
Problem
Feb 16 09:26:32 lachniet dhclient: DHCPREQUEST on eth0 to 12.242.20.34 port 67
Feb 16 09:26:32 lachniet dhclient: DHCPACK from 12.242.20.34
Feb 16 09:26:32 lachniet dhclient: bound to 67.162.209.240 -- renewal in 2969 se
conds.
Feb 16 09:57:07 lachniet sshd(pam_unix)[19088]: authentication failure; logname=
uid=0 euid=0 tty=NODEVssh ruser= rhost=host34.lan.sequoianet.com user=root
Feb 16 09:57:12 lachniet sshd(pam_unix)[19088]: session opened for user root by
(uid=0)
Feb 16 09:57:50 lachniet sendmail: sendmail shutdown succeeded
Feb 16 09:57:50 lachniet sendmail: sm-client shutdown succeeded
Feb 16 09:57:51 lachniet sendmail: Warning: Option: AuthOptions requires SASL su
pport (-DSASL)
Feb 16 09:57:51 lachniet sendmail: sendmail startup succeeded
Feb 16 09:57:51 lachniet sendmail: sm-client startup succeeded
More on Syslog
• Syslogging only happens if there is a client program
to send the message
• This is usually built into the application itself, such
as the kernel, or a sendmail program
• Many programs generate log data, but do not have
the coding to send it to the syslog facility, or don’t
do it because its impractical (e.g. a web server)
• To promote enterprise security and efficiency, these
programs can be reprogrammed, or can call a
supplemental program such as ‘logger’ (included in
most UNIX operating systems)
# logger -p kern.crit Your computer is on fire!
Creates a log entry such as:
Feb 16 14:33:29 lachniet root: Your computer is on fire!
Microsoft Windows Logging
• Microsoft products to *not* use the Syslog protocol
for logging by default
• Instead, there are a number of ways to log data, and
disparate places to log it:
– Windows Event Log (MMC plugin)
– Internet Information Systems Logs (www, FTP,
SMTP)
– DHCP server logs
– Microsoft Exchange
– DNS logs, etc. etc.
• Because of this, it is difficult to set up centralized
logging for Windows machines “out of the box”
(note: UNIX has the same problem)
• Fortunately, a number of products have been created
to help us with this task
Windows Event Log Example
The Event ID is a
critical component
that you can search
for
Supplemental
information can
also be useful
Windows Event Log Example Cont.
• The previous was a perfect example of
something you might want to know about
• Not even this level of information is available by
default – it must be manually configured on
most systems (Windows 2003 may be an
exception)
• !! The default level of logging is useless!!
• No system should be “green lighted” unless
there is some kind of formal system hardening
methodology that includes adequate logging of
the operating system
• Also, note that the event log only tracks some
events, and does not include web servers, etc.
Configuring Logging on Windows
• In order to get useful logging out of a Windows
product, you have to manually turn this on
• If you are configuring for an individual workstation,
you are going to configure a ‘local security policy’ –
this can be done by a machine administrator (usually
an end user)
• If you are doing this for a large group of people,
presumably in Windows 2000 Active Directory, you
will use Group Policy
• In any case, you need to manually configure what
your policy settings will be – usually through the
“Administrative Tools” or mmc program
• Lets look at an example of a local workstation –
doing this for a domain is similar but more
complicated (there may be more complex
inheritance rules)
Default Windows Event Logging
By
default,
nothing is
audited
Enabling Auditing
• Double-click on the category, and select the
check boxes for important items
Configuring Logging on Windows Cont
Now you
are auditing
logons and
logoffs
• Repeat as desired! (use a guide to determine what
settings to use)
Configure Event Viewer Settings
• But wait, you are not done – the default “event
viewer” settings may not be adequate
• Within the event viewer, you need to set:
– The size of the event log
– What happens when the event log reaches maximum
size (overwrite, rollover, nothing)
– How many days to store the logs for before rolling
over
• There is also the option to “hard stop” the server if it
cannot log – this may be needed for high-security
systems. See:
http://www.microsoft.com/technet/treeview/default.asp
?url=/technet/columns/security/askus/aus1101.asp
Setting Event Log Properties
Setting Event Log Properties
Windows Event Logging
• For a list of Windows event ID’s check out:
http://support.microsoft.com/?kbid=299475
http://support.microsoft.com/?kbid=301677
• There are a variety of things that you can audit for:
–
–
–
–
–
Login / logout
Account management (create, delete, modify)
Directory service access
Object access (files, printers)
Use of privileges (backup)
• Yet, there are many things you can’t monitor with
event log:
– Internet Information Server
– Microsoft Exchange, etc.
The Honey Pot
• If there is a particularly interesting file on your
network, for example “salary.xls” or
“resignation.doc”, you may want to audit all
access to this file
• You may even choose to create this file just to see
who looks at it 
• In another example, you may wish to audit access
to log files, and filter out normal users – most
folks have no business reading log files
• This can take place on file servers (network
shares) but can also be configured on your local
workstation
Good Windows Log Features
• The ability to forward Windows events to a
centralized syslog server for aggregation and
analysis
• The ability to log events to a SQL database for
complicated analysis and trending
• The ability to maintain time synchronization with
other systems (NTP)
• The ability to recognize malicious use (IDS)
• Regular batch hashes, zips and transfers of log
data to repository or read-only medium (CD-R?)
• The ability to ‘hash’ a file (i.e., create a
cryptographically sound representation of the file)
may be required for high-security
Network Logs
• Network device logs can provide a detail of what
type of information traveled between network
systems:
– Determine how the system was profiled
(reconnaissance)
– Determine how the system was attacked
(vulnerability)
– Determine what happened after the attack – did
the hacker use your system to store files? Attack
other systems? Copy data to another machine?
– Determine if multiple parties were involved (may
indicate collusion on the part of multiple
employees)
Log Aggregation and Analysis
• Logging is important, but making sense of the data is
even more important
• If individuals manually analyze large datasets, they
may get desensitized and miss something important
• Additionally, manually viewing single events (a
packet, a single URL) does not really establish a
useful baseline
• Is this event part of an attack? Is it some indication
of a performance problem?
• For this reason, a variety of log analysis tools have
been created to help the end user to deal with the
deluge of data
Snare
• Snare - Audit and EventLog analysis and forwarding
• http://www.intersectalliance.com/
Kiwi Syslog Daemon
• Receives the syslog events from local programs and
remote systems (as needed)
Kiwi Syslog Daemon Cont.
• Kiwi can do lots of neat things, like send you a page or
play a WAV file every time there is a failed administrator
login
eIQ System Analytics
• A “Web-based analysis and reporting
solution that can analyze event logs
generated by Windows and UNIX networks”
NetIQ (Web Trends) Firewall Suite
• Converts large amounts of firewall data into handy charts
and graphs
• Tracks both “packet” and “web browsing” data
On Selecting Products
• Note – I do not have a strong preference for any one
tool and do not recommend any of the above
• Much of what needs to happen can be done entirely
on open source and freeware tools
• The biggest cost is labor. Do you spend the money
on a product or a person? What is the accuracy?
• As with anything, the capability to log and audit
usage should be a component of the System
Development Life Cycle and not in isolation
• Consult with subject matter experts where
appropriate – technical people know the capabilities,
but not the needs or the reasoning for this level of
detail (and work) in the organization
Links
http://www.doit.wisc.edu/security/resources/bestpract/logging.asp
(windows settings)
http://www.sans.org/rr/papers/index.php?id=1100 (using Kiwi in a Cisco
and Microsoft environment)
http://www.sans.org/rr/papers/index.php?id=1101 (Syslog in a Microsoft
environment)
http://www.owasp.org (best practices in web application development)
http://www.databasejournal.com/features/mssql/article.php/2243271
(Enhanced SQL Security auditing)
http://www.winsyslog.com/en/FAQ/index.php (syslog products for
Windows)
http://www.campin.net/syslog-ng/faq.html (Syslog NG products)
http://www.loganalysis.org/ (web site / listserve dedicated to log analysis)
http://www.loganalysis.org/sections/audit/tbird-syslog-overview.pdf
(overview of Syslog in general)
More Links
http://windows.about.com/library/tips/bltip316.htm (turning on logging
of DHCP)
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/colu
mns/security/askus/aus1101.asp (enabling auditing on Windows)
http://www.jsiinc.com/SUBI/tip4100/rh4108.htm (list of security events
to audit for)
http://www.eiqnetworks.com/products/systemanalytics.shtml
(commercial product to analyze Windows and UNIX logs)
http://www.mwagent.com/en/ (MonitorWare)
http://www.sans.org/rr/papers/index.php?id=201 (Effective logging and
the use of the Kiwi syslog utility)
Discussion
• This presentation to be available at:
http://lachniet.com/powerpoint
Mark Lachniet
CISSP, CISA, MCSE, MCNE, CCSE, LPIC-1, TICSA
Technical Director, Security Group
Analysts International
(517) 336-1004 (voice)
(517) 336-1100 (fax)
mailto: [email protected]