Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Attacking Sandboxes

Posted by kdawson on Sun Jul 15, 2007 07:05 PM
from the just-another-brick-in-the-wall dept.
Security IT
SkiifGeek writes "Many anti-malware applications use a sandbox as a tool to help identify potentially malicious software. Now knowledge is spreading about techniques and methods that can allow sandboxed software to target the sandbox itself (and by extension the application that applied it). While attacks that specifically target sandboxing applications are probably a little way off, this technology can be considered the logical extension of techniques and procedures to identify the presence of hosted systems (VMWare, Virtual PC, etc.)."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Attacking Sandboxes 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Enter the Sandbox (Score:2, Funny)

    by Anonymous Coward
    So when will we be able to attack the Matrix?

  • Sandbox the sandbox (Score:4, Funny)

    by robo_mojo (997193) on Sunday July 15 2007, @07:08PM (#19871733)
    That's ok. We can just sandbox the sandbox and still be safe.

    • Re:Sandbox the sandbox (Score:5, Funny)

      by langelgjm (860756) on Sunday July 15 2007, @07:19PM (#19871833) Journal
      But who will sandbox the sandboxers?

    • Re:Sandbox the sandbox (Score:5, Funny)

      by GizmoToy (450886) on Sunday July 15 2007, @07:23PM (#19871861) Homepage
      You know, this was marked as Funny but I wouldn't be surprised if this was suggested as a solution at some point. "Hell, just wrap it in another (insecure) layer and it'll be fine."

      • Re:Sandbox the sandbox (Score:5, Interesting)

        by CastrTroy (595695) on Sunday July 15 2007, @08:47PM (#19872345) Homepage
        Sounds like the security methods most online banking systems use. Here's the current layers:
        • password
        • mother's maiden name/ what's you're favourite movie
        • secret picture
        • randomized keypad for entiring password

        It's all layers of useless crap piled on top of eachother which doesn't stop the real problem of people falling for stupid fishing sites, and entering a password in a site that looks like their bank's. If they really wanted to add real security they'd hand out RSA key fobs to everyone instead of adding layers of stuff that makes it look more secure but actually isn't.

        • Re: (Score:3, Insightful)

          by billcopc (196330)
          So you're saying the RSA key fob isn't another useless insecure layer of crap ? Have you even HEARD their sales pitch ?

          • Re:Sandbox the sandbox (Score:4, Insightful)

            by Poltras (680608) on Sunday July 15 2007, @10:20PM (#19872827) Homepage
            as long as USERS don't understand it, yes it is useless. Secure the communication and provide X509 certs all you want, if the user think it's a bank, he will enter his password.

            • Re: (Score:3, Insightful)

              by mcrbids (148650)
              as long as USERS don't understand it, yes it is useless. Secure the communication and provide X509 certs all you want, if the user think it's a bank, he will enter his password.

              I don't think you understand what he's really saying - you could hand out RSA key fobs and/or client certificates that authenticate the browser to the bank. Without that, the password would/could be utterly useless.

              If the bank uses the key fob, you can't enter by password alone. If the bank uses client certificates, then that must be

              • Re: (Score:2, Interesting)

                by 0xygen (595606)
                How does prevent the existing real time man in the middle attack?

                e.g. user visits phisherman's site, phisherman's server visits bank, passes on RSA auth request to user's browser, user's browser passes auth request back to phisherman, who passes it to bank. Phisherman now logged on as user?
              • '' I don't think you understand what he's really saying - you could hand out RSA key fobs and/or client certificates that authenticate the browser to the bank. Without that, the password would/could be utterly useless. ''

                A very low-tech approach would be this: On your paper bank statement that you receive every month, print a list of twenty 10-digit access codes. Each access code can be only used by you, in the following month, and only once. One month delay so you can tell your bank if the statement didn't

        • Re: (Score:3, Informative)

          by arminw (717974)
          ..... If they really wanted to add real security they'd hand out RSA key fobs to everyone......

          Does that mean the use is restricted to the users own computers or any others that has the correct interface and software which is able to send the key-fob data to the bank's server at the correct time?

          A password will work with *any* computer, but a piece of hardware, whether key-fob or biometric scanner will only work with a computer that has the correct software installed on it. That software would have to be st
          • No. It's restricted to people who can submit the correct username and password, and correct number from the keyfob, in the three fields on the bank's login form, within X minutes for when the number from the keyfob is valid.

            Alternatively, if you have a smart keyfob, you punch in your password (cached for say 5 minutes) and then out comes some new number which you then use to log in.

            There are plenty of other alternatives - ask the crypto people.

            Still you do not want to be using an untrusted computer since on

        • falling for stupid fishing sites
          Yeah, somehow these places always manage to hook me with their bait.

      • Re: (Score:2, Interesting)

        by Meski (774546)
        When the real layer is equally insecure, how will you know you have reached it?

      • Re: (Score:3, Insightful)

        by Miseph (979059)
        Because the AV/S/M app is frequently able to obtain all sorts of wacky permissions and access, it could be viable to piggyback on it into otherwise secure systems. For example, if an AV was set up such that it could scan encrypted data, then exploiting it to get past the encryption could be feasible.

  • Serves us right (Score:3, Funny)

    by jimbug (1119529) on Sunday July 15 2007, @07:13PM (#19871777)
    for building a box out of sand. what were we thinking?

  • Old news (Score:4, Informative)

    by Nick_taken (1090721) on Sunday July 15 2007, @07:18PM (#19871819)
    Theres a simple detection program called RedPill that probes a simple method to do so, vmware leaves a lot of registry keys on windows, VirtualBox lacks supports for hardware breakpoints, cpu cycles counts is another way to detect virtualization, and some packed malware dont even run on virtual machines because of memory management, software packed with armadillo do not run on vbox and it used to fail on vmware player until they fixed that bug.

    "Thwarting Virtual Machine Detection" is a nice paper on virtual machine detection.

    • Re: (Score:3, Insightful)

      by QuantumG (50515)
      It's pretty trivial to find a dozen ways to detect a virtual machine, just make a project that generates some random bytes and then jump to the bytes. Put the program in a script that calls it over and over again with a seed for the random number generator. When the VM crashes, look at the last seed that was used. Run the program again with that seed to confirm it is repeatable. This also happens to be a good way to detect if your VM is any good and fix it when it isn't. Unfortunately, many things are

  • Strike vs Counterstrike (Score:5, Insightful)

    by mcrbids (148650) on Sunday July 15 2007, @07:18PM (#19871821) Journal
    There will never, ever be an end to this.

    As long as people are imperfect (and they always will be) there will be measures, countermeasures, and counter-counter measures. New techniques will make old ones obsolete, and even newer techniques will make the once-new techniques no longer apply.

    With this understanding, any technology that can outsurvive more than one or two iterations of other products in the same field becomes "venerable" and "stable".

    Which makes now a particularly good time to appreciate the guys who worked out the spec for TCP/IP some 30 (?) years ago. Despite going from mainframes, to minis, to PCs, and now on to the era of ubiquitous computing, the basic concepts and ideas behind the TCP/IP specification continue to hold steady and useful. They managed to come up with a technology, that whatever flaws have actually been found, hasn't come up against any real show-stoppers. None.

    To which I can only say: WOW.
    • uhhh.. TCP hijacking is almost just as easy now as it was 10 years ago. Back then you didn't have a whole lot of switches (they were much more expensive than hubs) so you could sniff packets for other hosts easier, but the act of hijacking TCP connections is still a major flaw in the protocol. We just work around it.

      • Back then you didn't have a whole lot of switches (they were much more expensive than hubs) so you could sniff packets for other hosts easier,

        Would that really be considered a flaw in TCP/IP though? That's really Ethernet's (L2/L1) fault, TCP/UDP (Layer 4) and IP (Layer 3) aren't really involved with hubs/non-L3 switches (Layer 1 and 2 respectively).

        On another note:

        How many of the major flaws/security issues have been entirelly the fault of the protocol's specification? I honestly don't know, I usually don

        • Re: (Score:3, Insightful)

          by QuantumG (50515)
          It's not about being able to sniff packets. That just makes it more applicable because, back then, you didn't need to be upstream. Today, if you're upstream of an end point you can hijack a TCP connection.

      • I thought that TCP hijacking was possible because of vulnerbilities in Sequence number generation in some TCP implementations, which have now been fixed?

      • Re:Strike vs Counterstrike (Score:4, Insightful)

        by mcrbids (148650) on Monday July 16 2007, @02:12AM (#19873909) Journal
        TCP hijacking is almost just as easy now as it was 10 years ago.

        It may be even easier. Who cares? However you look at it, TCP is doing its job. If you want to prevent against hijacking, the layered topology of the communication stack lets you prevent that at a higher level. (EG: Using encryption - which can be interrupted, but not hijacked)

        TCP hijacking is merely a side effect of a missing layer in the stack of your application.
      • If you can't do blind hijacking then TCP is fine and doing it's job.

        Just use SSL if you want more security. There's no point paying the extra cost of encryption when you don't need it.

        You need to do lots of extra stuff (check certs etc) if you do not want to be hijacked by MITM attacks.
    • CS .. now WoW ... are you sure you're posting in the right thread?

  • Once again, they didn't read the article. (Score:5, Insightful)

    by Cafe Alpha (891670) on Sunday July 15 2007, @07:28PM (#19871883) Journal
    The article didn't say that they've found code that attacks sandboxes, it said that they've found code that detects a sandbox (VMWare for instance) and plays innocent so as to avoid detection through the sandbox.

    It also said that software has been found that detects when it's attached to a debugger. Big deal, copy protection schemes have been doing that for decades.

    The article then goes on to FUD that code that attacks the sand box "must" be coming.

    Oh, it must be coming. Uhuh.
    • Interesting. So is there a way to SIMULATE running in a sandbox - in terms of a simple program could be installed by Joe Idiot and use up very few cpu cycles, so that the malware would believe the system was being sandboxed and thus behave innocently?
      • Sure that's called running stuff in a sandbox with hardware sandbox support.

        Just wait till Intel VT and AMD Pacifica improve.
      • Yes, that may be the case right now, but at one time the internet was the domain of the highly competent developers and look how that turned out.

  • Umm... yes? And? (Score:5, Interesting)

    by Opportunist (166417) on Sunday July 15 2007, @07:43PM (#19871985)
    That malware detects VMs is old news. I'd wager about 60% of current malware has VM detection built in. About as many have debugger detection. Some overlapping allowed.

    So far, malware that "breaks out" of the sandbox would be new to me (though I'd be grateful for a sample). Though, seriously, why not run a VM with Windows (to analyze) on a box running Linux? I'd be very interested if someone manages to do the feat of creating a piece of malware that manages to break out of the sandbox and then run on a machine with a completely different operating system.

    If you wanna throw another stick between the malware's feet, run the VM on a non-i386 architecture. If someone manages to break out of THAT and manages to hijack my machine, he really earned it and should get it.
  • Stuff like this will make VMWare, Parallels, and others improve their product so it becomes difficult (if not impossible) to detect that the host is virtual.

    By the same token, it suggests a new attack against malware.... find out what makes a piece of malware think it's running on a VM and then make a physical machine react the same way. The possibilities are endless here.
    • Well, it isn't the point of VMWare and Parallels to ensure that it isn't detectable. A simple check of the video card driver or something else similar will show that it is indeed a virtual machine. If you wanted to build a VM that was much harder to detect, then it could be done. But instead VMWare et al have other priorities such as increasing the efficiency and adding management functions. If you have malware installed on your ESX server, then you got more issues then whether or not it can detect that
      • ........A simple check of the video card driver or something else similar will show that it is indeed a virtual machine.......

        Not if the VM is emulates the actual HARDWARE accurately. Ultimately, if the emulation software is written to behave EXACTLY the same way the hardware it is emulating, there can be no SURE way any software running under that emulator can determine whether it is running on real hardware or not. Modern microprocessors are combinations of hardware and software also. The software part is
  • To detech VMware, it's almost trivial. VMware can be detected with a built-in backdoor. The backdoor is a configurable setting that's on a lot of times. Programs like VMware Tools use it to enhance KVM operations. An easier check would be to look on the system to see if your network driver is the VMware NIC drivers.

    "Piercing the abstraction" as they call it in the business, however, is much more difficult especially on a VM running on top of VMware's ESX, which don't actually interact with the guest OS
    • Setup a callgate, call it, the exceptions generated will be subtlety wrong. There's a lot of real weird stuff in the Intel instruction set that VMWare doesn't even try to emulate because the only OS that uses even 1% of it is OS2.

      These are so called WONTFIX bugs.. all VMs have them. There ain't enough hours in the day to worry about every nook and cranny of the x86 architecture.

  • Detecting virtualization? (Score:4, Funny)

    by macemoneta (154740) on Sunday July 15 2007, @10:19PM (#19872821)
    Being able to detect virtualization would be great, if the technique can be generically applied [wikipedia.org].

    There is no spoon [wikipedia.org]

    • Re:Arms race for nothing (Score:4, Interesting)

      by dbIII (701233) on Sunday July 15 2007, @11:25PM (#19873193)

      Meanwhile, I avoid ALL forms of anti-malware tools, and magically I rarely get infected. When I do

      Isn't once enough for anyone? You did format and restore from a known good backup or install media afterwards didn't you? There's a tendency lately to trust that whoever had full control of your PC did nothing but run a set script and blindly hope that there is nothing else on there. I've played with various removal tools when people have given me compromised machines and different tools gave me different answers the other tools could not detect - perhaps there were some things neither could detect, hard to be sure especially when you are booting from a compromised system.

      Fdisk it from orbit - it's the only way to be sure.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.