Microsoft Research: Strider GhostBuster Rootkit Detection and "...stealth software that hides in BI

Discussion in 'Computer Security' started by David H. Lipman, Sep 20, 2005.

  1. On Tue, 20 Sep 2005, Art wrote:

    > On Tue, 20 Sep 2005 20:19:46 GMT, "David H. Lipman"
    > <DLipman~nospam~@Verizon.Net> wrote:
    >
    > >From: "Art" <>
    > >
    > >
    > >|
    > >| Haven't you ever downloaded a BIOS update and reflashed a BIOS? How
    > >| would/did you know it wasn't infested? Presumably a insider job would
    > >| pass the checksum test.
    > >|

    >
    > >I get them directly from a trusted location.

    >
    > That's obviously the best bet but the point is that it's still a
    > gamble. You were insisting that it's impossible. I'm simply pointing
    > out that it's not impossible, however unlikely it might be.


    Sabotaged BIOSes are not only possible but one was shipped to customers.
    Isn't there *anyone* here who remembers this thread from 1998?
    http://www.chebucto.ns.ca/~af380/happy-birthday.txt

    --
    ``Why don't you find a more appropiate newsgroup to post this tripe into?
    This is a meeting place for a totally differnt kind of "vision impairment".
    Catch my drift?'' -- "jim" in alt.disability.blind.social regarding an
    off-topic religious/political post, March 28, 2005
     
    Norman L. DeForest, Sep 21, 2005
    #21
    1. Advertising

  2. David H. Lipman

    Art Guest

    On Wed, 21 Sep 2005 00:34:56 -0300, "Norman L. DeForest"
    <> wrote:

    >Sabotaged BIOSes are not only possible but one was shipped to customers.
    >Isn't there *anyone* here who remembers this thread from 1998?
    > http://www.chebucto.ns.ca/~af380/happy-birthday.txt


    Notice how "Gareth" insisted that it couldn't be a "virus" if Dr
    Solomon couldn't find it. That's the amusing part :)

    Art

    http://home.epix.net/~artnpeg
     
    Art, Sep 21, 2005
    #22
    1. Advertising

  3. From: "Norman L. DeForest" <>


    |
    | Sabotaged BIOSes are not only possible but one was shipped to customers.
    | Isn't there *anyone* here who remembers this thread from 1998?
    | http://www.chebucto.ns.ca/~af380/happy-birthday.txt
    |
    | --
    | ``Why don't you find a more appropiate newsgroup to post this tripe into?
    | This is a meeting place for a totally differnt kind of "vision impairment".
    | Catch my drift?'' -- "jim" in alt.disability.blind.social regarding an
    | off-topic religious/political post, March 28, 2005

    Thanx Norman !

    http://www.f-secure.com/v-descs/birthday.shtml

    http://www.softheap.com/internet/cmos-viruses_23.html

    On November 13th, some PCs around the world will play the Happy Birthday song through the PC
    speaker.

    http://virusview.net/info/virus/j&a/notvirus.html

    A "former" programmer at American Megatrends managed to sabotage a BIOS run. The specific
    information is listed below:

    BIOS Manufacturer: American Megatrends
    BIOS Version: M82C498 Evaluation BIOS v1.55
    BIOS Category: IBM PC/AT
    BIOS ID Bytes: FC 01 00
    BIOS Date: 04/04/93


    --
    Dave
    http://www.claymania.com/removal-trojan-adware.html
    http://www.ik-cs.com/got-a-virus.htm
     
    David H. Lipman, Sep 21, 2005
    #23
  4. David H. Lipman

    Roger Wilco Guest

    "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
    news:dgIXe.6951$nV1.1668@trnddc06...
    > http://research.microsoft.com/rootkit/
    >
    > States the following...
    > "Note: there will be some false positives. Also, this does not detect

    stealth software that
    > hides in BIOS, Video card EEPROM, disk bad sectors, Alternate Data

    Streams, etc. "
    >
    > We have discussed the possibility of infecting a BIOS over and over

    and the consensus has
    > been that is not possible.


    If enough room exists in the chips, malware can be stored there. IIRC
    the consensus was that a "virus or worm" would most likely not be
    written to do this because of the hardware specific nature of the code.
    In other words, there wouldn't be enough homogeneity netwide to support
    a successful worm or virus using this method. However with a specific
    target in mind, a rootkit could be made very sticky - to survive a
    normal wipe/reinstall.

    ....and for the "name one" naysayers around here - it should be noted
    that some cases existed where a vulnerability exploit was known to the
    underground for years before being noted by "white hat" computer
    security experts.

    > Based upon my studying both viruses and hardware I can't see how
    > it is possible. Yet the above Microsoft web site on a RootKit

    Detector indicates
    > "...stealth software that hides in BIOS, Video card EEPROM".
    >
    > From what I believe to be true, this is faux information and pure FUD.
    >
    > If anyone has specific information (backed by authoratative URLs such

    as from the IEEE or
    > some other organization) I welcome the replies. Both PRO and CON for

    the above statement.

    Will a book written by Greg Hoglund and Gary McGraw do?

    Exploiting Software
    How to Break Code

    ISBN 0-201-78695-8
     
    Roger Wilco, Sep 22, 2005
    #24
  5. David H. Lipman

    Roger Wilco Guest

    "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
    news:pKJXe.5376$9a2.2038@trnddc04...
    > From: "Art" <>
    >
    > the consensus was that no known malware infects the BIOS.
    > |
    > >> Based upon my studying both viruses and hardware I can't see how
    > >> it is possible.

    > |
    > | Why? You can download BIOS updates and reflash.
    > |
    >
    >
    > they are specifically written by the hardware manufacturer for

    specific mother using a
    > specific tupe of Flashable RAM or programable ROM.


    This makes it a poor choice for malware that needs to be portable
    between hardware platforms, but rootkits don't need to be portable.

    > That is one thing, but to insert code
    > and haver the BIOS still functional seems a bit far fetched.


    The BIOS routine runs on the processor almost without restriction
    (direct addressing, no protection) - there is no reason to assume all of
    the necessary code is in that location. The code could be fragmented and
    stored in multiple option ROM locations and stitched together for
    instance when shadowed.

    The bottom line is that what was once firmware has now entered the realm
    of (malicious) mobile code.
     
    Roger Wilco, Sep 22, 2005
    #25
  6. From: "Roger Wilco" <>


    |
    | The BIOS routine runs on the processor almost without restriction
    | (direct addressing, no protection) - there is no reason to assume all of
    | the necessary code is in that location. The code could be fragmented and
    | stored in multiple option ROM locations and stitched together for
    | instance when shadowed.
    |
    | The bottom line is that what was once firmware has now entered the realm
    | of (malicious) mobile code.
    |

    It will fail CRC checks.

    --
    Dave
    http://www.claymania.com/removal-trojan-adware.html
    http://www.ik-cs.com/got-a-virus.htm
     
    David H. Lipman, Sep 22, 2005
    #26
  7. David H. Lipman

    Sugien Guest

    "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
    news:bEnYe.24103$fb6.9862@trnddc08...
    > From: "Roger Wilco" <>
    >
    >
    > |
    > | The BIOS routine runs on the processor almost without restriction
    > | (direct addressing, no protection) - there is no reason to assume all of
    > | the necessary code is in that location. The code could be fragmented and
    > | stored in multiple option ROM locations and stitched together for
    > | instance when shadowed.
    > |
    > | The bottom line is that what was once firmware has now entered the realm
    > | of (malicious) mobile code.
    > |
    >
    > It will fail CRC checks.
    >

    maybe maybe not; because it could be configured to more or less be
    invisible.
    --
    From the Desk of Sugien
    /}
    @###{ ]::::::Dino-Soft Software::::::>
    \}
     
    Sugien, Sep 22, 2005
    #27
  8. David H. Lipman

    Imhotep Guest

    David H. Lipman wrote:

    > From: "Art" <>
    >
    >
    > |
    > | That's a no-brainer. It could do many kinds of different damage to a
    > | hard drive, including making it unuseable without a reformat. Even
    > | something as simple as refusing to boot and just hanging in a infinite
    > | loop is a example.
    > |
    > | Art
    > |
    > | http://home.epix.net/~artnpeg
    >
    > I can't see a vendor releasing a BIOS that did not pass a quality control
    > check.
    >


    Honestly, I have come across many buggy BIOSes...you notice it more when you
    are working with Linux/BSD...

    Im
     
    Imhotep, Sep 23, 2005
    #28
  9. David H. Lipman

    Roger Wilco Guest

    "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
    news:bEnYe.24103$fb6.9862@trnddc08...
    > From: "Roger Wilco" <>
    >
    >
    > |
    > | The BIOS routine runs on the processor almost without restriction
    > | (direct addressing, no protection) - there is no reason to assume

    all of
    > | the necessary code is in that location. The code could be fragmented

    and
    > | stored in multiple option ROM locations and stitched together for
    > | instance when shadowed.
    > |
    > | The bottom line is that what was once firmware has now entered the

    realm
    > | of (malicious) mobile code.
    > |
    >
    > It will fail CRC checks.


    Only if it has errors. Error in this context is a difference between the
    data the CRC's cyclic check sum was generated from and the new CRC
    cyclic check sum calculated from the data when received. How would a
    legitimate BIOS Upgrade reflash work if the checksum reference was
    inalterable? CRC's work because noise can't be expected to calculate new
    checksums, and they work better than simple parity checks for
    reliability and provide for error correction methods instead of only
    retransmission requests.
     
    Roger Wilco, Sep 23, 2005
    #29
  10. From: "Roger Wilco" <>


    |
    | Only if it has errors. Error in this context is a difference between the
    | data the CRC's cyclic check sum was generated from and the new CRC
    | cyclic check sum calculated from the data when received. How would a
    | legitimate BIOS Upgrade reflash work if the checksum reference was
    | inalterable? CRC's work because noise can't be expected to calculate new
    | checksums, and they work better than simple parity checks for
    | reliability and provide for error correction methods instead of only
    | retransmission requests.
    |

    If it comes from the factory (malicious or not) it will not fail a CRC check. IFF code could
    be appended to the BIOS routines maliciously it would fail a CRC check.

    --
    Dave
    http://www.claymania.com/removal-trojan-adware.html
    http://www.ik-cs.com/got-a-virus.htm
     
    David H. Lipman, Sep 23, 2005
    #30
  11. David H. Lipman

    Jim Byrd Guest

    Hi Roger - Just a small technical point to keep people from making wrong
    assumptions. There are a number of different coding techniques, some useful
    for varying degrees of error detection depending upon their redundancy such
    as number of errors detected or errors runs of some specific length, and
    there are others which can be used to generate syndromes which can be used
    for error correction as well, the most commonly known probably being
    Reed-Solomon codes. A CRC (as technically defined) is only an error
    detection code, not an error correcting one.

    --
    Regards, Jim Byrd, MS-MVP
    My Blog, Defending Your Machine, here:
    http://defendingyourmachine.blogspot.com/

    "Roger Wilco" <> wrote in message
    news:
    > "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in message
    > news:bEnYe.24103$fb6.9862@trnddc08...
    >> From: "Roger Wilco" <>
    >>
    >>
    >>>
    >>> The BIOS routine runs on the processor almost without restriction
    >>> (direct addressing, no protection) - there is no reason to assume all of
    >>> the necessary code is in that location. The code could be fragmented and
    >>> stored in multiple option ROM locations and stitched together for
    >>> instance when shadowed.
    >>>
    >>> The bottom line is that what was once firmware has now entered the realm
    >>> of (malicious) mobile code.
    >>>

    >>
    >> It will fail CRC checks.

    >
    > Only if it has errors. Error in this context is a difference between the
    > data the CRC's cyclic check sum was generated from and the new CRC
    > cyclic check sum calculated from the data when received. How would a
    > legitimate BIOS Upgrade reflash work if the checksum reference was
    > inalterable? CRC's work because noise can't be expected to calculate new
    > checksums, and they work better than simple parity checks for
    > reliability and provide for error correction methods instead of only
    > retransmission requests.
     
    Jim Byrd, Sep 23, 2005
    #31
  12. David H. Lipman

    Steve Welsh Guest

    Re: Microsoft Research: Strider GhostBuster Rootkit Detection and"...stealth software that hides in BIOS, Video card EEPROM"

    Why would it fail?

    There is nothing magical about a CRC - it simply does a logical XOR
    against a known polynomial. If someone is clever enough to inject
    malicious code into BIOS, I would dareay that they are also clever
    enough to make sure it passes CRC.

    CRC is designed (and is very good at) detecting bit and burst errors
    _in_transit_ - if someone deliberately manipulates the code of a BIOS
    update ( whatever) to pass CRC, then it _will_ pass CRC, unless it is
    corrupted en-route

    Steve

    David H. Lipman wrote:
    > From: "Roger Wilco" <>
    >
    >
    > |
    > | Only if it has errors. Error in this context is a difference between the
    > | data the CRC's cyclic check sum was generated from and the new CRC
    > | cyclic check sum calculated from the data when received. How would a
    > | legitimate BIOS Upgrade reflash work if the checksum reference was
    > | inalterable? CRC's work because noise can't be expected to calculate new
    > | checksums, and they work better than simple parity checks for
    > | reliability and provide for error correction methods instead of only
    > | retransmission requests.
    > |
    >
    > If it comes from the factory (malicious or not) it will not fail a CRC check. IFF code could
    > be appended to the BIOS routines maliciously it would fail a CRC check.
    >
     
    Steve Welsh, Sep 23, 2005
    #32
  13. David H. Lipman

    nemo_outis Guest

    "David H. Lipman" <DLipman~nospam~@Verizon.Net> wrote in
    news:jZYYe.2631$SG3.1591@trnddc07:

    > From: "Roger Wilco" <>
    >
    >
    >|
    >| Only if it has errors. Error in this context is a difference between
    >| the data the CRC's cyclic check sum was generated from and the new
    >| CRC cyclic check sum calculated from the data when received. How
    >| would a legitimate BIOS Upgrade reflash work if the checksum
    >| reference was inalterable? CRC's work because noise can't be expected
    >| to calculate new checksums, and they work better than simple parity
    >| checks for reliability and provide for error correction methods
    >| instead of only retransmission requests.
    >|
    >
    > If it comes from the factory (malicious or not) it will not fail a CRC
    > check. IFF code could be appended to the BIOS routines maliciously it
    > would fail a CRC check.
    >



    Not so. CRCs are an excellent protection against accidental code changes;
    they're a piss-poor protection against intentional changes.

    CRCs (despite being polynomials) have a linear structure. That is,
    considered as a hash function it is simple to generate clashes/duplicates.
    Given one CRC it is a trivial matter to generate a sequence that will
    result in the same CRC. The modified code to be spliced in need only have
    a few discretionary bytes (beyond its true "payload") somewhere before,
    within, or after it, and voila: same CRC!

    The industry should have chosen one-way hash functions (e.g., SHA family)
    rather than CRC, but that's water under the bridge now.

    Regards,
     
    nemo_outis, Sep 24, 2005
    #33
  14. David H. Lipman

    Roger Wilco Guest

    "Jim Byrd" <> wrote in message
    news:...
    > Hi Roger - Just a small technical point to keep people from making

    wrong
    > assumptions. There are a number of different coding techniques, some

    useful
    > for varying degrees of error detection depending upon their redundancy

    such
    > as number of errors detected or errors runs of some specific length,

    and
    > there are others which can be used to generate syndromes which can be

    used
    > for error correction as well, the most commonly known probably being
    > Reed-Solomon codes. A CRC (as technically defined) is only an error
    > detection code, not an error correcting one.


    Thanks Jim. I only meant that CRC is an improvement in reliability over
    simple parity checks which in turn improves efficacy of any error
    correction scheme they are applied to. Parity checks only detect odd
    numbers of errors and are oblivious to even numbered errors and CRC is a
    vast improvement over this - the main point I was trying to make was
    that a correct CRC is not an indicator that data was not manipulated,
    only that it was probably not manipulated by some dumb process such as
    random bit switching or some transmission noise effect.
     
    Roger Wilco, Sep 24, 2005
    #34
  15. David H. Lipman

    Jim Byrd Guest

    YW, Roger - Your point's well taken - I just didn't want people to be
    mislead into thinking that a CRC could be used by itself for error
    corrections. :)

    --
    Regards, Jim Byrd, MS-MVP
    My Blog, Defending Your Machine, here:
    http://defendingyourmachine.blogspot.com/

    "Roger Wilco" <> wrote in message
    news:
    > "Jim Byrd" <> wrote in message
    > news:...
    >> Hi Roger - Just a small technical point to keep people from making wrong
    >> assumptions. There are a number of different coding techniques, some

    useful
    >> for varying degrees of error detection depending upon their redundancy

    such
    >> as number of errors detected or errors runs of some specific length, and
    >> there are others which can be used to generate syndromes which can be

    used
    >> for error correction as well, the most commonly known probably being
    >> Reed-Solomon codes. A CRC (as technically defined) is only an error
    >> detection code, not an error correcting one.

    >
    > Thanks Jim. I only meant that CRC is an improvement in reliability over
    > simple parity checks which in turn improves efficacy of any error
    > correction scheme they are applied to. Parity checks only detect odd
    > numbers of errors and are oblivious to even numbered errors and CRC is a
    > vast improvement over this - the main point I was trying to make was
    > that a correct CRC is not an indicator that data was not manipulated,
    > only that it was probably not manipulated by some dumb process such as
    > random bit switching or some transmission noise effect.
     
    Jim Byrd, Sep 25, 2005
    #35
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Annette Kurten

    New stealth rootkit

    Annette Kurten, Apr 9, 2005, in forum: Computer Support
    Replies:
    22
    Views:
    2,446
    trout
    Apr 9, 2005
  2. Blue Event Horizon
    Replies:
    6
    Views:
    3,135
    raincoater
    Sep 9, 2006
  3. Replies:
    18
    Views:
    6,843
    Sue Perficial
    Nov 23, 2005
  4. Pamela Fischer
    Replies:
    4
    Views:
    844
  5. Rootkit detection and removal

    , Mar 12, 2006, in forum: Computer Support
    Replies:
    5
    Views:
    2,652
    Plato
    Mar 12, 2006
Loading...

Share This Page