Re: [WEB SECURITY] Backdoors in custom software applications

["Arian J. Evans" <arian.evans () anachronic com>]

Sebastian -

Looks like you got great replies! Lots of different theories and ideas here.

On a day to day basis - here are the most common "backdoors" in
webapps I've encountered over the last 15 years or so:

1) Developer Tools "Backdoor" hidden under obscure path
2) COTS module improperly deployed results in "backdoor"
3) Custom admin module, Auth gets changed/removed, results in same as #2
4) MVC framework autobinding exposes functions not intended to be
exposed resulting in backdoor

Most of these "backdoors" are accidental ignorance or mistakes. They
can turn malicious, but in the majority of cases I have seen, they
were not intended to be malicious. I have only seen deep-evil,
malicious backdooring a couple of times.

In devilish detail:

1) Back Door hidden under obscure path

/app/bin/steve/stevessecretphrase/tools/ (stuff under here is
dangerous and/or bad)

I see this happen over and over again for a variety of reasons. As
mentioned - most were not intentionally malicious - at least before
the developer who made the "backdoor" was fired. Usually the original
motivation was to instrument some part of the code for runtime
analysis, or provide a test/debugging interface for the developer.

Automated static analysis is by and large useless out of the box at
detecting these. These are valid "web applications" from an
implementation level perspective. Blind automated blackbox is fairly
limited at finding these too....these type of backdoors aren't linked
from the main app. They are rarely in the large, fairly useless
dictionary of directory names the scanners run brute force checks for.

How do you find these?

I wrote a tripwire-like tool for my webapps that tracked and diffed
files and paths for (a) changes and (b) cross mapped to request paths
in the WWW logs. In the early days I knew all the paths of all the web
apps we wrote, so this would allow me to identify new and unusual
paths as they showed up on the file system, or in request logs. As we
grew that quickly failed to scale. When your web apps grow into the
dozens, and hundreds....I think a WAF is your only hope here.

Modern web apps don't lend themselves to file-level
path/file/directory audits (using automation). Source code scanning
lacks the context needed here, plus these things are very often
config-file dependent and config files in prod are always different
than the CBE/SIT code being scanned, and in prod they are rarely
audited properly.

The good news is that the bad guys have just as much trouble finding
these as you do. The exception being an ex-employee who has insider
knowledge (usually wrote the thing). But while dangerous, this appears
to be one of the least-common sources of compromise.



2) COTS module improperly deployed or configured for AuthC/Z resulting
in "Back Door"

Example: some Peoplesoft or SAP module with employee PII or amazing
administrative powers accidentally gets:

(a) deployed with insufficient (or missing) AuthC/Z, usually as part
of some grand web SSO scheme that turned messy.

(b) deployed to an unintended production server region that does not
have the same controls as the intended region. e.g.- IT is counting on
using Windows Integrated Authentication over HTTP on the Intranet for
Auth on this webapp. However, someone deployed parts of it to the
Internet-facing/DMZ webservers. Now you can access it with no
authentication at all. Or using Basic Auth and a default vendor or
admin/admin type account easily accessible over the internet.

At the rate I see #2 increasing, it may replace #1 soon.



3) Homegrown admin tools deployed with insufficient AuthC/Z

Same as #2, but harder to find with automation. It's easy to cook up
some tests for things everyone knows about, e.g.
/peoplesoft/admintools/ in static and dynamic analysis.

It is less easy to look for things you do not know exist.
/sebastians/homebrew/admintools

I see two "backdoor" situations here, one where /admintools/
accidentally has Auth removed for everything in it, and I see where
only a specific function/form fails to Auth, allowing you to create a
new Administrator, or such, if you know the right request to make.



4) MVC framework Autobinding exposes parameters in namespace not
intended to be exposed in the UI at all, or at the privilege level
they get exposed at.

This is a newer, but rapidly growing "backdoor" problem. I do not see
this being discussed much yet in Web AppSec circles, so either I'm
missing something or other folks don't realize the potential impact of
this problem.

There are not many vendors providing effective solutions for
discovering MVC "backdoors". I suspect because there is no demand for
this year. Operational security people driving software security
analysis efforts are otten not aware of the slightly messy features in
MVC frameworks (like autobinding). And quite frankly, I'm not sure how
many of the software security automation vendors get it. But I
digress.

To test for these issues I like to extract a parameter "heatmap" from
static analysis of sourcecode and use this for dynamic blackbox
injection testing.


These are all just classic examples of Authentication and
Authorization weaknesses, at both implementation level, and
occasionally design flaws. But they serve as "backdoors" and seem to
me far more common than the theoretical backdoors created by the
"trojan Chinese compilers" or whatever is way cooler to talk about at
OWASP and Defcon during the Beer Track sessions.

I am going to talk to Steven@MITRE about making new CWE entries for
the examples above, though. I'm trying to get CWE over 1,000 node
entries!

Happy Holidays, hope this helps,

---
Arian Evans
Simple Software Security Sagacity



On Thu, Dec 16, 2010 at 12:18 PM, Sebastian Schinzel <ssc () seecurity org> wrote:
> Hi all,
>
> I am looking for ideas how intentional backdoors in real software applications may look like.
>
> Wikipedia already provides a good list of backdoors that were found in software applications: 
> http://en.wikipedia.org/wiki/Backdoor_(computing)
>
> Has anyone encountered backdoors during code audits, penetration tests, data breaches?
> Could you share some details of how the backdoor looked like? I am really interested in
> a technical and abstract description of the backdoor (e.g. informal descriptions or pseudo-code).
> Anonymized and off-list replies are also very welcome.
>
> Thanks,
> Sebastian
> ----------------------------------------------------------------------------
> Join us on IRC: irc.freenode.net #webappsec
>
> Have a question? Search The Web Security Mailing List Archives:
> http://www.webappsec.org/lists/websecurity/archive/
>
> Subscribe via RSS:
> http://www.webappsec.org/rss/websecurity.rss [RSS Feed]
>
> To unsubscribe email websecurity-unsubscribe () webappsec org and reply to
> the confirmation email
>
> Join WASC on LinkedIn
> http://www.linkedin.com/e/gis/83336/4B20E4374DBA
>
> WASC on Twitter
> http://twitter.com/wascupdates
_______________________________________________
Secure Coding mailing list (SC-L) SC-L () securecoding org
List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l
List charter available at - http://www.securecoding.org/list/charter.php
SC-L is hosted and moderated by KRvW Associates, LLC (http://www.KRvW.com)
as a free, non-commercial service to the software security community.
Follow KRvW Associates on Twitter at: http://twitter.com/KRvW_Associates
_______________________________________________