Secure Coding mailing list archives
Re: [WEB SECURITY] Backdoors in custom software applications
From: "Steven M. Christey" <coley () linus mitre org>
Date: Wed, 22 Dec 2010 14:15:24 -0500 (EST)
On Mon, 20 Dec 2010, Arian J. Evans wrote:
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.
Note that these backdoors Arian listed can be classified in more general weakness/vulnerability terms (as he stated, e.g. authentication/authorization). This is both a good thing, since existing detection techniques for "regular" vulns may still find these, and a bad thing - you can't automatically determine if "intent" is malicious or not.
Just thought I'd mention this since a lot of people seem to think of backdoors and other maliciously-inserted code as being somehow "different" than regular vulns. The main difference is intent, which you can't always know. For example, many vendor-introduced hidden accounts are introduced to make installation or support easier, or as a result of a testing feature that wasn't disabled before shipment.
You could argue that some backdoors/malicious-functionality are "business logic" but I suspect that most business-logic issues are really just instances of more general weaknesses/vulns that require knowledge of a specific domain to determine whether they're expected behavior or bad behavior.
- Steve
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---------------------------------------------------------------------------- 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 _______________________________________________
Current thread:
- Backdoors in custom software applications Sebastian Schinzel (Dec 16)
- Re: Backdoors in custom software applications Jeremy Epstein (Dec 16)
- Re: [WEB SECURITY] Re: Backdoors in custom software applications Chris Wysopal (Dec 17)
- Re: [WEB SECURITY] Re: Backdoors in custom software applications Chris Schmidt (Dec 23)
- Re: [WEB SECURITY] Re: Backdoors in custom software applications Chris Wysopal (Dec 17)
- Message not available
- Re: [WEB SECURITY] Re: Backdoors in custom software applications Prasad N Shenoy (Dec 23)
- Re: [WEB SECURITY] Re: Backdoors in custom software applications Chris Wysopal (Dec 23)
- Re: [WEB SECURITY] Re: Backdoors in custom software applications Prasad N Shenoy (Dec 23)
- Re: Backdoors in custom software applications Jeremy Epstein (Dec 16)
- Re: [WEB SECURITY] Backdoors in custom software applications Arian J. Evans (Dec 23)
- Re: [WEB SECURITY] Backdoors in custom software applications Steven M. Christey (Dec 23)