RE: USB delivered attacks

From: Brian Taylor (drak3_at_comcast.net)
Date: 06/05/04

  • Next message: mak_pen_at_hotmail.com: "Wireless pentesting requirements" 
    To: "'R. DuFresne'" <dufresne@sysinfo.com>, <mak_pen@hotmail.com>
Date: Sat, 5 Jun 2004 14:21:48 -0400

    -----Original Message-----
    From: R. DuFresne [mailto:dufresne@sysinfo.com]

    <SNIP>

    "This is old news though, security 101 kind of stuff. Just because a
    new
    toy comes out does not imply it should not play by the rules of the
    other
    toys in the chest. If this is found in an audit then the company that
    hired you has real policy issues for you to outline to them and they
    will
    then need to address."

    I agree fully with Ron. We're now crossing into that infinite, inky pit
    known as "a hacker could...". It is sort of a déjà vu from the thread
    on the Incidents list. We have had good testing and results that
    actually gave some great answers. USB keys and other (tiny) removable
    devices have given us a new pain from a security standpoint. But like
    anything else, it has to start with policy. BUT the process has to
    follow as well. In this example, I have seen policies that stated that
    booting from cd or floppy is not allowed on workstations or servers, yet
    their IT departments (who built servers or sent orders to vendors to
    configure them) had no process or subsequent audits about disabling
    these features from the BIOS during build time. They simply applied the
    stock image and were done with it. However, if everything was done
    properly, you would simply add to your list of areas to check as
    technology changes. You aren't re-inventing the wheel every time
    something new comes out that is simply a variation on a theme
    (floppy-->zip drive-->CD--USB key-->???). Lock down bootable devices
    when appropriate. Audit and update list of devices as technology/trends
    change or on an annual basis.

    From a physical-access pen-testing standpoint, this is definitely one of
    those "DOH!" issues. Of course *we* think about things like that, but
    do your average clients? I would assume many of the pen-testers here
    also suggest policy to their clients. In that regard, this is
    definitely one for them to consider. Both in policy and audits to ensure
    that it is being done at the most crucial point--the introduction of a
    new resource on the network.

    Sorry to bring policy in a pen-testing discussion, but I believe that
    there is some overlap. IMO, finding holes in technology, policy and
    process can yield the same results.

    --BT

  • Next message: mak_pen_at_hotmail.com: "Wireless pentesting requirements"

    Relevant Pages

    • RE: Auditing file deletion
      ... regarding this in the security event log. ... Default Domain Controllers Policy. ... Click Computer Configuration, double-click Windows Settings, ... double-click Audit Policy. ...
      (microsoft.public.windows.server.sbs)
    • Re: Auditing file deletion
      ... You won't have to wade through the tonnes of audit logs, but have to set filters to watch the activity you care about. ... The problem is that hundreds of other Object Access events get logged, not just the file and directory deletions. ... regarding this in the security event log. ... Default Domain Controllers Policy. ...
      (microsoft.public.windows.server.sbs)
    • RE: Auditing Workstation logons from DC
      ... You have already configured Domain Security Settings for Audit account ... the both Default Domain Controllers Policy and Default Domain Security ... GPO may be overriding the audit policy setting that you configured. ...
      (microsoft.public.windows.server.sbs)
    • Re: audit folder/file delet
      ... >size of the security log and only audit the bare number of permissions for the bare ... >> I try to audit a folder and its subdirectory for deletion. ... >> first to enable in local security policy, audit policy, audit object ...
      (microsoft.public.win2000.security)
    • Re: Audit Deleting of files
      ... you can't just do an audit on the machine. ... >audit policy for your domain: ... >then click Security. ... >setting take effect only when the policy setting is ...
      (microsoft.public.win2000.security)