Re: [SC-L] Insider threats and software
Paco Hope wrote: On 8/16/07 7:44 PM, silky [EMAIL PROTECTED] wrote: how is this different then sending malformed packets to an rpc interface? ... Now I'll gently disagree with Gary, who is my boss, so you know I'll hear about it in the hallways... I think this feels more like privilege escalation than insider threat. The distinction being that these attacks allow an authorized user who has liimited privileges to escalate their privileges and do things that they shouldn't be able to do. An insider (to me) is a person who already had that privilege and status when they started their attack. (Read Kevin Wall's follow-up on darkreading.com he has good things to say on who are insiders and outsiders). Where we are prone to confusion, I think, is that outsiders or limited authorized users can have the same IMPACT as an insider, when the privilege escalation is sufficiently bad. Gary has an interesting but fairly obvious idea, that AJAX clients are exceptionally vulnerable to the environment they run in. Said clients are also part of a distributed computing system between the AJAX client, the web front end, and whatever back-end systems are involved. Is this an insider threat? Only if the people who coded the server were dumb enough to treat the AJAX client as if it were an insider component. Never do that. This is web security 101: always always always check your input parameters, and especially if they are coming from a web client. There is a risk here that AJAX developers will get confused, lazy, sloppy, about whether the AJAX client component is trusted or not. It is not clear to me yet whether the AJAX dev tools that are emerging make that mistake pervasive, or if it requires a special kind of stupid to make that mistake. Is this really an insider threat? I think that is stretching things, but not a huge amount. Gary also brings up references to his book on hacking games. Small-scale distributed games are the same as web apps; never trust the client. Large scale MMORP games (everything from World of Warcraft to Second Life) are economically mandated to shift as much computational burden onto the client as possible, and that entails inevitably trusting the clients more than security really can tolerate. Such games are inherently insecure; look for more hacking to occur. Read more about it in this Oakland 2007 paper, with an interesting solution to this problem: /Enforcing Semantic Integrity on Untrusted Clients in Networked Virtual Environments (Extended abstract)/ Somesh Jha, Stefan Katzenbeisser, Christian Schallhart, Helmut Veith and Stephen Chenney http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/toc=comp/proceedings/sp/2007/2848/00/2848toc.xmlDOI=10.1109/SP.2007.3 Crispin -- Crispin Cowan, Ph.D. http://crispincowan.com/~crispin/ Director of Software Engineering http://novell.com AppArmor Chat: irc.oftc.net/#apparmor ___ 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. ___
Re: [SC-L] Insider threats and software {darkreading thread}
Hi all, As is often the case with these darkreading things, we have two discussion threads going. Those of you interested in a very well thought out counter argument to my position should read kevin's excellent posting on darkreading. http://www.darkreading.com/boards/messages.asp?thread_id=165118msg_id=147279t=true#msg_147279 gem company www.cigital.com podcast www.cigital.com/silverbullet book www.swsec.com -Original Message- From: Wall, Kevin [mailto:[EMAIL PROTECTED] Sent: Friday, August 17, 2007 1:38 AM To: Gary McGraw Subject: Posted thread on your Dark Reading column (was RE: [SC-L] Insider threats and software) Hi Gary, Our Exchange server was down for awhile so rather than posting a reply to your post on SC-L, I simply created a reply thread on your Dark Reading column. Given that, I'm not sure that it's worth posting to SC-L too. Give it a read and see what you think. Or maybe they could just be referred to the URL if you think it actually contributes anything of value. Cheers (or is that beers?), -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED]Phone: 614.215.4788 The reason you have people breaking into your software all over the place is because your software sucks... -- Former White House cyber-security adviser, Richard Clarke, at eWeek Security Summit This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. ___ 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. ___
Re: [SC-L] Insider threats and software
Hello all, I do not agree with Mike's point of view. Of course the unique way to cheat a system is to understand how it is working, and to abuse it. But the main difference is that you can hardly talk about protocol in the case of applications: if you have a given protocol, you 'just' need to build a firewall that checks that the protocol is properly working. In the case of software level insider attack, you would therefore need a dedicated firewall for every application you provide, which seem difficult both in term of development and performance cost. The differences I see between the two cases are the following: - attacks are now performed at the applicative level. And no simple interface between the user and the application can be identified, since a heavy client is involved (the interface is no longer a single protocol, but a whole application). - the matter becomes even worse if the systems are dynamic (such as with MIDP, or OSGi, or any plug-in mechanism), which does not yet occurs with online games, but soon could. last case make a shift in the potential attacks quite likely: it is sufficient to make malicious components freely available to perform attacks, even without illegally modifying existing code. The problem of client-based attack is bound with the one of integration of off-the-shelf components: how is it possible to control the execution process for every self-developed of third party, local or remote, piece of code ? Both involve application level 'protocols' to perform insider attacks, which are not so easy to tackle, I.e what Gary is describing is (to my view) not the ultimate insider, but a step toward a worsening of the security state of systems. regards, Pierre P. Quoting silky [EMAIL PROTECTED]: i really don't see how this is at all an 'insider' attack; given that it is the common attack vector for almost every single remote exploit strategy; look into the inner protocol of the specific app and form your own messages to exploit it. On 8/15/07, Gary McGraw [EMAIL PROTECTED] wrote: Hi sc-l, My darkreading column this month is devoted to insiders, but with a twist. In this article, I argue that software components which run on untrusted clients (AJAX anyone? WoW clients?) are an interesting new flavor of insider attack. Check it out: http://www.darkreading.com/document.asp?doc_id=131477WT.svl=column1_1 What do you think? Is this a logical stretch or something obvious? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com ___ -- -- Pierre Parrend Ph.D. Student, Teaching Assistant INRIA-INSA Lyon, France [EMAIL PROTECTED] web : http://www.rzo.free.fr ___ 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. ___
Re: [SC-L] Insider threats and software
Doesn't an execution sandbox serve similar funtions to a firewall, but at the host level? Can't even more control be added to a sandbox than can be set on a firewall? Second, doesn't a host based firewall (even on desktops) provide the security you are talking about (providing they work propery - which is another topic). Am I missing the point? Or are you thinking of something that checks message queues for proper semantics and syntax (since some OS's are message based and work from message queues)? M. - Michael S Hines [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pierre Parrend Sent: Thursday, August 16, 2007 4:20 AM To: silky Cc: SC-L@securecoding.org Subject: Re: [SC-L] Insider threats and software Hello all, I do not agree with Mike's point of view. Of course the unique way to cheat a system is to understand how it is working, and to abuse it. But the main difference is that you can hardly talk about protocol in the case of applications: if you have a given protocol, you 'just' need to build a firewall that checks that the protocol is properly working. In the case of software level insider attack, you would therefore need a dedicated firewall for every application you provide, which seem difficult both in term of development and performance cost. The differences I see between the two cases are the following: - attacks are now performed at the applicative level. And no simple interface between the user and the application can be identified, since a heavy client is involved (the interface is no longer a single protocol, but a whole application). - the matter becomes even worse if the systems are dynamic (such as with MIDP, or OSGi, or any plug-in mechanism), which does not yet occurs with online games, but soon could. last case make a shift in the potential attacks quite likely: it is sufficient to make malicious components freely available to perform attacks, even without illegally modifying existing code. The problem of client-based attack is bound with the one of integration of off-the-shelf components: how is it possible to control the execution process for every self-developed of third party, local or remote, piece of code ? Both involve application level 'protocols' to perform insider attacks, which are not so easy to tackle, I.e what Gary is describing is (to my view) not the ultimate insider, but a step toward a worsening of the security state of systems. regards, Pierre P. Quoting silky [EMAIL PROTECTED]: i really don't see how this is at all an 'insider' attack; given that it is the common attack vector for almost every single remote exploit strategy; look into the inner protocol of the specific app and form your own messages to exploit it. On 8/15/07, Gary McGraw [EMAIL PROTECTED] wrote: Hi sc-l, My darkreading column this month is devoted to insiders, but with a twist. In this article, I argue that software components which run on untrusted clients (AJAX anyone? WoW clients?) are an interesting new flavor of insider attack. Check it out: http://www.darkreading.com/document.asp?doc_id=131477WT.svl=column1 _1 What do you think? Is this a logical stretch or something obvious? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com ___ -- -- Pierre Parrend Ph.D. Student, Teaching Assistant INRIA-INSA Lyon, France [EMAIL PROTECTED] web : http://www.rzo.free.fr ___ 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. ___ ___ 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. ___
Re: [SC-L] Insider threats and software {EOG}
Hi Michael, I think thinking about firewalls and protocol analysis is missing the point almost entirely. Remember, the subverted client is behaving itself from the perspective of the server. It's just doing normal game client things...only in the case of a bot it is being driven by outside logic written by the no-longer-present gamer who wants to create virtual wealth while sleeping. How would a host-based firewall help? The GAMER controls the host! Why on earth would the gamer/attacker allow a firewall to get in the way of game client subversion? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael S Hines Sent: Thursday, August 16, 2007 11:04 AM To: SC-L@securecoding.org Subject: Re: [SC-L] Insider threats and software Doesn't an execution sandbox serve similar funtions to a firewall, but at the host level? Can't even more control be added to a sandbox than can be set on a firewall? Second, doesn't a host based firewall (even on desktops) provide the security you are talking about (providing they work propery - which is another topic). Am I missing the point? Or are you thinking of something that checks message queues for proper semantics and syntax (since some OS's are message based and work from message queues)? M. - Michael S Hines [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pierre Parrend Sent: Thursday, August 16, 2007 4:20 AM To: silky Cc: SC-L@securecoding.org Subject: Re: [SC-L] Insider threats and software Hello all, I do not agree with Mike's point of view. Of course the unique way to cheat a system is to understand how it is working, and to abuse it. But the main difference is that you can hardly talk about protocol in the case of applications: if you have a given protocol, you 'just' need to build a firewall that checks that the protocol is properly working. In the case of software level insider attack, you would therefore need a dedicated firewall for every application you provide, which seem difficult both in term of development and performance cost. The differences I see between the two cases are the following: - attacks are now performed at the applicative level. And no simple interface between the user and the application can be identified, since a heavy client is involved (the interface is no longer a single protocol, but a whole application). - the matter becomes even worse if the systems are dynamic (such as with MIDP, or OSGi, or any plug-in mechanism), which does not yet occurs with online games, but soon could. last case make a shift in the potential attacks quite likely: it is sufficient to make malicious components freely available to perform attacks, even without illegally modifying existing code. The problem of client-based attack is bound with the one of integration of off-the-shelf components: how is it possible to control the execution process for every self-developed of third party, local or remote, piece of code ? Both involve application level 'protocols' to perform insider attacks, which are not so easy to tackle, I.e what Gary is describing is (to my view) not the ultimate insider, but a step toward a worsening of the security state of systems. regards, Pierre P. Quoting silky [EMAIL PROTECTED]: i really don't see how this is at all an 'insider' attack; given that it is the common attack vector for almost every single remote exploit strategy; look into the inner protocol of the specific app and form your own messages to exploit it. On 8/15/07, Gary McGraw [EMAIL PROTECTED] wrote: Hi sc-l, My darkreading column this month is devoted to insiders, but with a twist. In this article, I argue that software components which run on untrusted clients (AJAX anyone? WoW clients?) are an interesting new flavor of insider attack. Check it out: http://www.darkreading.com/document.asp?doc_id=131477WT.svl=column1 _1 What do you think? Is this a logical stretch or something obvious? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com ___ -- -- Pierre Parrend Ph.D. Student, Teaching Assistant INRIA-INSA Lyon, France [EMAIL PROTECTED] web : http://www.rzo.free.fr ___ 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
Re: [SC-L] Insider threats and software
On 8/17/07, Gary McGraw [EMAIL PROTECTED] wrote: Hi, The point here is NOT to pull a person-in-the-middle attack against the protocol, but rather to subvert the client completely and have the subverted client do all of your talking for you. The most advanced (game)bot techniques that we describe in EOG work by shimming (in an almost invisible way) the game client, then setting up a communication channel with another processor after a hardware interrupt in the main game thread is thrown. For those of you with the book, see pages 228-230. A less hairy approach is to attach to the game client as a debugger and just call methods like there's no tomorrow. The only problem with that approach is it is like stomping around in the mud puddle and you are likely to be detected. Effectively then, you ARE the client. That's why I think it's more of an insider attack than your standard BO sploit. how is this different then sending malformed packets to an rpc interface? the rpc would normally take it's protocol from some app; but what you, as the smart attacker, have done is to review the app, exploit it's weakness's in client-side protocol assumptions (client will always send correctly formed packets) and profit. seems like the classic remote exploit development strategy. you are also 'mixing in' a bot as an exploit. it's not an exploit of the game in terms of compromising it, what you're actually compromising if the in-game protocols (not out-of-game-and-operating-system protocols). for example, there is a korean game for which you can buy a physical device that you attach to your mouse that plays the game for you. what sort of attack is this? it isn't any sort of classical attack. it's a automation of the game. which is a problem; granted, but not an 'insider attack'. why blur the line on what insider attack means? it will only make life worse/easier for CTO's to fob it off as too hard. if you specifically define it it can be acted on and solved. expanding the definition will only complicate matters, imho. gem p.s. I added a little bit of data on the justice league blog about this: http://www.cigital.com/justiceleague/2007/08/16/software-the-new-insider-threat/ -Original Message- From: silky [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 14, 2007 7:44 PM To: Gary McGraw Cc: SC-L@securecoding.org Subject: Re: [SC-L] Insider threats and software i really don't see how this is at all an 'insider' attack; given that it is the common attack vector for almost every single remote exploit strategy; look into the inner protocol of the specific app and form your own messages to exploit it. On 8/15/07, Gary McGraw [EMAIL PROTECTED] wrote: Hi sc-l, My darkreading column this month is devoted to insiders, but with a twist. In this article, I argue that software components which run on untrusted clients (AJAX anyone? WoW clients?) are an interesting new flavor of insider attack. Check it out: http://www.darkreading.com/document.asp?doc_id=131477WT.svl=column1_1 What do you think? Is this a logical stretch or something obvious? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com ___ 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. ___ -- mike http://lets.coozi.com.au/ ___ 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. ___ -- mike http://lets.coozi.com.au/ ___ 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. ___
Re: [SC-L] Insider threats and software
i really don't see how this is at all an 'insider' attack; given that it is the common attack vector for almost every single remote exploit strategy; look into the inner protocol of the specific app and form your own messages to exploit it. On 8/15/07, Gary McGraw [EMAIL PROTECTED] wrote: Hi sc-l, My darkreading column this month is devoted to insiders, but with a twist. In this article, I argue that software components which run on untrusted clients (AJAX anyone? WoW clients?) are an interesting new flavor of insider attack. Check it out: http://www.darkreading.com/document.asp?doc_id=131477WT.svl=column1_1 What do you think? Is this a logical stretch or something obvious? gem company www.cigital.com podcast www.cigital.com/silverbullet blog www.cigital.com/justiceleague book www.swsec.com ___ 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. ___ -- mike http://lets.coozi.com.au/ ___ 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. ___
Re: [SC-L] Insider threats and software
* Gary McGraw: My darkreading column this month is devoted to insiders, but with a twist. In this article, I argue that software components which run on untrusted clients (AJAX anyone? WoW clients?) are an interesting new flavor of insider attack. I really wish this were something new. 8-( In client/server applications, it's not too uncommon that the client connects to the server with a hard-coded password, uses that to download some kind of authentication table, and looks up a user-supplied password in it. If it's not found, the authentication fails. Apparantly, you can save some client licenses with such a setup. ___ 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. ___
