Hi list,

NGS Software is pleased to make available a new whitepaper about
second-order code injection attacks.

Abstract:
"Many forms of code injection targeted at web-based applications (for
instance cross-site scripting and SQL injection) rely upon the instantaneous
execution of the embedded code to carry out the attack (e.g. stealing a
user's current session information or executing a modified SQL query). In
some cases it may be possible for an attacker to inject their malicious code
into a data storage area that may be executed at a later date or time.
Depending upon the nature of the application and the way the malicious data
is stored or rendered, the attacker may be able to conduct a second-order
code injection attack.

A second-order code injection attack can be classified as the process in
which malicious code is injected into a web-based application and not
immediately executed, but instead is stored by the application (e.g.
temporarily cached, logged, stored in a database) and then later retrieved,
rendered and executed by the victim."

The paper can be accessed from:
http://www.nextgenss.com/papers/Seco...eInjection.pdf


Cheers,

Gunter

------------------------------------------------------
G u n t e r O l l m a n n, MSc(Hons), BSc
Professional Services Director

Next Generation Security Software Ltd.
First Floor, 52 Throwley Way Tel: +44 (0)208 401 0089
Sutton, Surrey, SM1 4BF, UK Fax: +44 (0)208 401 0076
http://www.nextgenss.com
------------------------------------------------------

I found an instance of this class of vulnerability in 1998 where an
attacker could inject code into the "locate" database, which would later
be executed when root tried to do a locate on some path name
http://msgs.securepoint.com/cgi-bin/...raq/601/1.html

Mine was not the first such"secondary code injection" attack. It was a
consequence of exploring a PoC by MiG for a buffer overflow
vulnerability in bash, where in a tall directory tree would overflow
bash when you try to cd into that directory and you have the pwd set to
be part of your prompt. At the time, it did not occur to me that it was
a special kind of buffer overflow.

Crispin

Gunter Ollmann wrote:

>Hi list,
>
>NGS Software is pleased to make available a new whitepaper about
>second-order code injection attacks.
>
>Abstract:
>"Many forms of code injection targeted at web-based applications (for
>instance cross-site scripting and SQL injection) rely upon the instantaneous
>execution of the embedded code to carry out the attack (e.g. stealing a
>user's current session information or executing a modified SQL query). In
>some cases it may be possible for an attacker to inject their malicious code
>into a data storage area that may be executed at a later date or time.
>Depending upon the nature of the application and the way the malicious data
>is stored or rendered, the attacker may be able to conduct a second-order
>code injection attack.
>
>A second-order code injection attack can be classified as the process in
>which malicious code is injected into a web-based application and not
>immediately executed, but instead is stored by the application (e.g.
>temporarily cached, logged, stored in a database) and then later retrieved,
>rendered and executed by the victim."
>
>The paper can be accessed from:
>http://www.nextgenss.com/papers/Seco...eInjection.pdf
>
>
>Cheers,
>
>Gunter
>
>------------------------------------------------------
>G u n t e r O l l m a n n, MSc(Hons), BSc
>Professional Services Director
>
>Next Generation Security Software Ltd.
>First Floor, 52 Throwley Way Tel: +44 (0)208 401 0089
>Sutton, Surrey, SM1 4BF, UK Fax: +44 (0)208 401 0076
>http://www.nextgenss.com
>------------------------------------------------------
>
>
>
>
>

--
Crispin Cowan, Ph.D. http://immunix.com/~crispin/
CTO, Immunix http://immunix.com

Gunter,

Thanks for the comprehensive treatment of this class of vulnerabilities. The
OWASP Top Ten paper breaks down XSS flaws into "stored" and "reflected"
categories, but your paper is far closer to a complete theory about all the
ways that tainted data can undermine the security of applications.

--Jeff

----- Original Message -----
From: "Crispin Cowan" <crispin@immunix.com>
To: "Gunter Ollmann" <gunter@ngssoftware.com>
Cc: <bugtraq@securityfocus.com>
Sent: Monday, November 01, 2004 8:45 PM
Subject: Re: New Whitepaper - "Second-order Code Injection Attacks"


> I found an instance of this class of vulnerability in 1998 where an
> attacker could inject code into the "locate" database, which would later
> be executed when root tried to do a locate on some path name
> http://msgs.securepoint.com/cgi-bin/...raq/601/1.html
>
> Mine was not the first such"secondary code injection" attack. It was a
> consequence of exploring a PoC by MiG for a buffer overflow
> vulnerability in bash, where in a tall directory tree would overflow
> bash when you try to cd into that directory and you have the pwd set to
> be part of your prompt. At the time, it did not occur to me that it was
> a special kind of buffer overflow.
>
> Crispin
>
> Gunter Ollmann wrote:
>
> >Hi list,
> >
> >NGS Software is pleased to make available a new whitepaper about
> >second-order code injection attacks.
> >
> >Abstract:
> >"Many forms of code injection targeted at web-based applications (for
> >instance cross-site scripting and SQL injection) rely upon the
instantaneous
> >execution of the embedded code to carry out the attack (e.g. stealing a
> >user's current session information or executing a modified SQL query).
In
> >some cases it may be possible for an attacker to inject their malicious
code
> >into a data storage area that may be executed at a later date or time.
> >Depending upon the nature of the application and the way the malicious
data
> >is stored or rendered, the attacker may be able to conduct a second-order
> >code injection attack.
> >
> >A second-order code injection attack can be classified as the process in
> >which malicious code is injected into a web-based application and not
> >immediately executed, but instead is stored by the application (e.g.
> >temporarily cached, logged, stored in a database) and then later
retrieved,
> >rendered and executed by the victim."
> >
> >The paper can be accessed from:
> >http://www.nextgenss.com/papers/Seco...eInjection.pdf
> >
> >
> >Cheers,
> >
> >Gunter
> >
> >------------------------------------------------------
> >G u n t e r O l l m a n n, MSc(Hons), BSc
> >Professional Services Director
> >
> >Next Generation Security Software Ltd.
> >First Floor, 52 Throwley Way Tel: +44 (0)208 401 0089
> >Sutton, Surrey, SM1 4BF, UK Fax: +44 (0)208 401 0076
> >http://www.nextgenss.com
> >------------------------------------------------------
> >
> >
> >
> >
> >
>
> --
> Crispin Cowan, Ph.D. http://immunix.com/~crispin/
> CTO, Immunix http://immunix.com
>

Cool.

I make no claims that this a previously "undiscovered" security flaw. I
myself have been exploiting these kinds of flaws in web-based applications
for many years as well. However, the purpose of the paper is two fold.

[Classification] -- Firstly, the paper attempts to classify the second-order
code injection attacks, and differentiate between other immediate effects of
code injection into web applications. Hopefully making it a little easier
for professional pentesters to explain the significance of their findings.

[Awareness] -- Secondly, too many organisations that I come across don't
really understand what code injection is - everything is either cross-site
scripting or SQL injection. I believe it is important to clearly
differentiate between the code injection attacks - and to explain their
significance within a corporate environment.

What gets me is that to properly assess the security of any modern web-based
application now days, to properly check for second-order code injection
attacks, security teams must also have access to and assess the supporting
applications as well -- ranging from the customer-support applications
reviewing client account details, through to centralised log analysis and
management tools. In way too many client pentesting reports I've written
over the years, the exploitation of backend systems/processes through
second-order code injection attacks were far more damaging to their
corporate security than a bit of cross-site scripting and session hijacking
on their exposed web application.

Cheers,

Gunter

> -----Original Message-----
> From: Crispin Cowan [mailto:crispin@immunix.com]
> Sent: 02 November 2004 01:46
> To: Gunter Ollmann
> Cc: bugtraq@securityfocus.com
> Subject: Re: New Whitepaper - "Second-order Code Injection Attacks"
>
> I found an instance of this class of vulnerability in 1998 where an
> attacker could inject code into the "locate"
> database, which would later be executed when root tried to do a locate
> on some path name
> http://msgs.securepoint.com/cgi-bin/...raq/601/1.html
>
> Mine was not the first such"secondary code injection" attack.
> It was a consequence of exploring a PoC by MiG for a buffer overflow
> vulnerability in bash, where in a tall directory tree would overflow
> bash when you try to cd into that directory and you have the pwd set
> to be part of your prompt.
> At the time, it did not occur to me that it was a special kind of
> buffer overflow.
>
> Crispin
>
> Gunter Ollmann wrote:
>
> >Hi list,
> >
> >NGS Software is pleased to make available a new whitepaper about
> >second-order code injection attacks.
> >
> >Abstract:
> >"Many forms of code injection targeted at web-based
> applications (for
> >instance cross-site scripting and SQL injection) rely upon the
> >instantaneous execution of the embedded code to carry out the attack
> >(e.g. stealing a user's current session information or executing a
> >modified SQL query). In some cases it may be possible for
> an attacker
> >to inject their malicious code into a data storage area that
> may be executed at a later date or time.
> >Depending upon the nature of the application and the way the
> malicious
> >data is stored or rendered, the attacker may be able to conduct a
> >second-order code injection attack.
> >
> >A second-order code injection attack can be classified as
> the process
> >in which malicious code is injected into a web-based application and
> >not immediately executed, but instead is stored by the
> application (e.g.
> >temporarily cached, logged, stored in a database) and then later
> >retrieved, rendered and executed by the victim."
> >
> >The paper can be accessed from:
> >http://www.nextgenss.com/papers/Seco...eInjection.pdf
> >
> >
> >Cheers,
> >
> >Gunter
> >
> >------------------------------------------------------
> >G u n t e r O l l m a n n, MSc(Hons), BSc
> >Professional Services Director
> >
> >Next Generation Security Software Ltd.
> >First Floor, 52 Throwley Way Tel: +44 (0)208 401 0089
> >Sutton, Surrey, SM1 4BF, UK Fax: +44 (0)208 401 0076
> >http://www.nextgenss.com
> >------------------------------------------------------
> >
> >
> >
> >
> >
>
> --
> Crispin Cowan, Ph.D. http://immunix.com/~crispin/
> CTO, Immunix http://immunix.com
>
>
>

Le lun 01/11/2004 à 18:36, Gunter Ollmann a écrit :

> NGS Software is pleased to make available a new whitepaper about
> second-order code injection attacks.

Class 3 attacks are often met in large corporations where the Web is the
standard way (for both internal employées and "clients") to interact
with the corporate data.

I've seen some webapps audits where :
- malicous data can be inserted via the main corporate website by
anybody with a valid email
- the main processing is done deep in the internal network, through the
Intranet
- the Intranet *must* (corporate policy) be configured as Fully Trusted
in Internet Explorer, allowing the attacker to use, for example,
unsigned ActiveX to hack internal machines.

Not sanitizing input is bad, but storing it for later processing with
different privileges is much worse ...

--
Nicolas Gregoire ----- Consultant en Sécurité des Systèmes d'Information
ngregoire@exaprobe.com ------[ ExaProbe ]------ http://www.exaprobe.com/
PGP KeyID:CA61B44F FingerPrint:1CC647FF1A55664BA2D2AFDACA6A21DACA61B4 4F

Jeff,

I see XSS as merely a subgroup of code injection attacks - and it is
important to make that distinction. While they (as in XSS) still get a lot
of press coverage, they're not particularly remarkable. The most effective
attacks abusing XSS vulnerabilities to date would probably be within
Phishing attacks - thankfully something that the press havn't focused upon.

The OWASP categories of "stored" or "reflected", while good for a basic
understanding, are a little too limited in scope to cover all XSS
vulnerabilities. They are certainly inadequate for covering much of the
code injection possibilities.

Having said all that, it still suprises me how many people think that by
testing for <script>alert('XSS')</script> - getting a positive response -
means that an application is 100% vulnerable to XSS. People need to be a
lot clearer about the types of code injection flaws a web-based application
is vulnerable to -- instead of using a Cross-site Scripting catchall tag.

Cheers,

Gunter


> -----Original Message-----
> From: Jeff Williams [mailto:jeff.williams@aspectsecurity.com]
> Sent: 02 November 2004 20:44
> To: Crispin Cowan; Gunter Ollmann
> Cc: bugtraq@securityfocus.com; webappsec@securityfocus.com
> Subject: Re: New Whitepaper - "Second-order Code Injection Attacks"
>
> Gunter,
>
> Thanks for the comprehensive treatment of this class of
> vulnerabilities. The OWASP Top Ten paper breaks down XSS flaws into
> "stored" and "reflected"
> categories, but your paper is far closer to a complete theory about
> all the ways that tainted data can undermine the security of
> applications.
>
> --Jeff
>
> ----- Original Message -----
> From: "Crispin Cowan" <crispin@immunix.com>
> To: "Gunter Ollmann" <gunter@ngssoftware.com>
> Cc: <bugtraq@securityfocus.com>
> Sent: Monday, November 01, 2004 8:45 PM
> Subject: Re: New Whitepaper - "Second-order Code Injection Attacks"
>
>
> > I found an instance of this class of vulnerability in 1998 where an
> > attacker could inject code into the "locate" database,
> which would later
> > be executed when root tried to do a locate on some path name
> > http://msgs.securepoint.com/cgi-bin/...raq/601/1.html
> >
> > Mine was not the first such"secondary code injection"
> attack. It was a
> > consequence of exploring a PoC by MiG for a buffer overflow
> > vulnerability in bash, where in a tall directory tree would overflow
> > bash when you try to cd into that directory and you have
> the pwd set to
> > be part of your prompt. At the time, it did not occur to me
> that it was
> > a special kind of buffer overflow.
> >
> > Crispin
> >
> > Gunter Ollmann wrote:
> >
> > >Hi list,
> > >
> > >NGS Software is pleased to make available a new whitepaper about
> > >second-order code injection attacks.
> > >
> > >Abstract:
> > >"Many forms of code injection targeted at web-based
> applications (for
> > >instance cross-site scripting and SQL injection) rely upon the
> instantaneous
> > >execution of the embedded code to carry out the attack
> (e.g. stealing a
> > >user's current session information or executing a modified
> SQL query).
> In
> > >some cases it may be possible for an attacker to inject
> their malicious
> code
> > >into a data storage area that may be executed at a later
> date or time.
> > >Depending upon the nature of the application and the way
> the malicious
> data
> > >is stored or rendered, the attacker may be able to conduct
> a second-order
> > >code injection attack.
> > >
> > >A second-order code injection attack can be classified as
> the process in
> > >which malicious code is injected into a web-based
> application and not
> > >immediately executed, but instead is stored by the
> application (e.g.
> > >temporarily cached, logged, stored in a database) and then later
> retrieved,
> > >rendered and executed by the victim."
> > >
> > >The paper can be accessed from:
> > >http://www.nextgenss.com/papers/Seco...eInjection.pdf
> > >
> > >
> > >Cheers,
> > >
> > >Gunter
> > >
> > >------------------------------------------------------
> > >G u n t e r O l l m a n n, MSc(Hons), BSc
> > >Professional Services Director
> > >
> > >Next Generation Security Software Ltd.
> > >First Floor, 52 Throwley Way Tel: +44 (0)208 401 0089
> > >Sutton, Surrey, SM1 4BF, UK Fax: +44 (0)208 401 0076
> > >http://www.nextgenss.com
> > >------------------------------------------------------
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Crispin Cowan, Ph.D. http://immunix.com/~crispin/
> > CTO, Immunix http://immunix.com
> >
>
>
>