"Camera/Shy the Steganographical Browser"

From: ttudiaat_private
Date: Mon Oct 14 2002 - 06:01:27 PDT

  • Next message: Sym Security: "Re: Symantec Enterprise Firewall Secure Webserver info leak"

    "Camera/Shy the Steganographical Browser"
    
    
    Overview:
    ---------
      Several weaknesses have been discovered in
    Camera/Shy (c/s)
      the Steganographical Browser from "Hacktivismo"
        + Smaller than reported cryptographic key
        + Incorrect implementation
        + Detection of hidden content
    
    
    Description:
    ------------
    
    "CAMERA/SHY OVERVIEW
     .........
     Utilizing LSB steganographic techniques and AES-256
    bit
     encryption, this application enables users to share
    censored information
     with their friends by hiding it in plain view as
    ordinary gif images.
     Camera/Shy is the only steganographic tool that
    automatically scans for
     and delivers decrypted content straight from the Web.
     It is a stand-alone, Internet Explorer-based browser
    that leaves no trace
     on the user¡¦s system. As a safety feature Camera/Shy
    also includes security
     switches for protection against malicious HTML.
    Picture that."
     (from
    http://www.hacktivismo.com/news/modules.php?name=Content&pa=showpage&pid=12/)
    
    According to the overview from hacktivismo c/s
    features 256 AES (Rijndael)
    encryption.  An examination of the c/s source code
    proves this to be incorrect.
    The function "encryptHTML" is used for encrypting
    messages.
    As we can see below at ** c/s #1 the Rijndael cipher
    is initialized by passing
    the string located in "WideEdit3" to the the "InitStr"
    procedure of David Barton's
    DCPcrypt library.  The result of encryption in CBC
    mode is then base64 encoded
    using the Encode function of the base64 unit at ** c/s
    #2.
    
     - from Unit1.pas
    ---------------------------------------------------
     function
    TForm1.encryptHTML(encryptString:string):string;
     var
       Cipher: TDCP_rijndael;
    
     begin
        //  encrypt string
        if encryptString = '' then
        exit;
    
        Cipher:= TDCP_rijndael.Create(nil);
    
        Cipher.InitStr(WideEdit3.Text);          // ** c/s
    #1
    
       
    Cipher.EncryptCBC(encryptString[1],encryptString[1],Length(encryptString));
       
        result := base64.Encode(encryptString);  // ** c/s
    #2
    
        Cipher.Burn;  { Erase key information }
        Cipher.Free;
    
     end;
     - /Unit1.pas
    ------------------------------------------------------
    
    
    Side note:
    DCPcrypt beta2 allows InitStr to be called as
    InitStr(const Key: string; HashType: TDCP_hashclass);
    but as "Camera/Shy" is calling InitStr(const Key:
    string);
    we know that an older version of DCPcrypt is being
    used.
    
    Now we examine the code at "InitStr" inside DCPcrypt:
    
     - from DCPcrypt.pas
    -----------------------------------------------
     procedure TDCP_cipher.InitStr(const Key: string);
     var
       Hash: TDCP_sha1;
       Digest: array[0..19] of byte;  { SHA1 produces a
    20byte digest }
     begin
       if fInitialized then
         Burn;
       Hash:= TDCP_sha1.Create(Self);
       Hash.Init;
       Hash.UpdateStr(Key);
       Hash.Final(Digest);               // ** dcp/1
       Hash.Free;
       if MaxKeySize< 160 then
         Init(Digest,MaxKeySize,nil)     // ** dcp/2
       else
         Init(Digest,160,nil);           // ** dcp/3
    
       FillChar(Digest,Sizeof(Digest),$FF);
     end;
     - /DCPcrypt.pas
    ---------------------------------------------------
    
    From the above code we are able to determine that:
      ** dcp/1. "Key" (password string) is hashed using
    SHA-1
      ** dcp/2. If the maximum key size the particular
    TDCP_Cipher is
                less than 160 bits then truncate the "Key"
    hash digest
                and use it initialize the TDCP_Cipher with
    a nil IV.
      ** dcp/3. ELSE initialize the TDCP_Cipher using the
    160 bit hash
                digest and a nil IV.
    
    Side note:
    When TDCP_rijndael.Init is passed a nil IV, one is
    generated
    automatically by encrypting an 128-bit buffer of 0's
    using ECB
    mode with the same key as specified in the first
    paramater.
    ie: Init(const Key; Size: longint; InitVector:
    pointer)
    
    An examination of the code within Rijndael.pas is left
    as an
    exercise for the interested reader.
    
    This non-standard key size and method of
    initialization are not
    mentioned anywhere within the AES specification.
    While the Rijndael algorithm is used, it is incorrect
    to state
    that Camera/Shy uses "AES-256 bit encryption".
    Encryption is NOT performed with a 256 bit key and
    does NOT
    conform to AES specification. 
    
    
    Content detection
    Earlier it was mentioned that the encrypted message is
    base64
    encoded using the Encode function of the base64 unit
    at ** c/s #2.
    This information plus a quick examination of the
    primitive
    algorithms located in "InsertSteganography" and
    "ExtractSteganography" allows us to hastily discuss a
    method of
    detecting hidden content within any image produced by
    "Camera/Shy".
    Data that is embedded within an image takes the form
    of a string:
    
     [ SIGNATURE + Message + $00 ]
    
    Where "SIGNATURE" is an arbitary string entered by the
    user and
    "Message" is the encrypted message in base64 form.
    When we call a slightly modified
    "ExtractSteganography" with a
    standard non-stegged image as input, the resultant
    string should
    be of a pseudo random nature.  When we call the same
    function
    passing a stegged image as input, the resultant string
    will look
    like a short string of text ("SIGNATURE") followed by
    base64 encoded
    ciphertext.
    Software may be written to operate with a modified
    "ExtractSteganography" that can examine the resultant
    string as such:
      + IF several printable bytes are followed by 0x00 
      + THEN flag image and store extracted data
    
    Knowing this, it is TRIVIAL to write an automated
    application which could quickly examine a set of
    suspect images,
    locally or online, determine whether they are
    "Camera/Shy" and
    act according to its findings.
    ie: notify administration, block host/s, etc
    
    
    Conclusion:
    -----------
    
    The purpose of steganography is to conceal that fact
    that secret
    communication is taking place.  Easy detection of
    steganographic
    methods defeats the purpose of this hidden
    communication.
    If the steganographic methods employed are readily
    detectable, then
    they offer no advantages over straightforward
    encryption, only
    disadvantages. 
    
    With such a limited understanding of cryptography and
    steganography
    displayed by the authors of c/s, it is highly unlikely
    that thier
    contributions to "hacktivism" will have any positive
    effect.
    
    It is left to the reader to make up her/his mind as to
    whether
    "Hacktivismo" purposefully implemented an
    exceptionally weak/naive
    steganographic system and misled the general public
    about
    cryptographic methods used in "Camera/Shy", or simply
    did so
    out of pure ignorance and incompetence. 
    
    A false sense of security is worse than no security at
    all.
    
    
    Tested versions:
    ----------------
      Camera/Shy 0.2.22 Beta (current version)
    
    
    URLS:
    -----
      Camera/Shy |
    http://sourceforge.net/projects/camerashy/
      DCPcrypt   | http://www.cityinthesky.co.uk/cryptography.html
    
    -----------------------------------------------------------------
    < ¨C¤Ñ³£ Yahoo!©_¼¯ >  www.yahoo.com.tw
    



    This archive was generated by hypermail 2b30 : Tue Oct 15 2002 - 13:01:05 PDT