Closed Thread
Page 2 of 2 FirstFirst 12
Results 11 to 20 of 20

Thread: Conficker??? real or fake

  1. #11
    ReignInChaos's Avatar
    ReignInChaos is offline Learning Programmer
    Join Date
    Feb 2009
    Location
    NJ
    Posts
    46
    Blog Entries
    5
    Rep Power
    12

    Re: Conficker??? real or fake

    I feel that if a person or group that this almighty power to unleash havoc on the world, why would they want all this comotion about it. Granted they are being put in the public eye, but if their intent is to cause damage wouldn't they want to be discrete about it?. If you look at it from an objectively, the media (with the help of a few experts after the hype already took place) blew this up. I am not doubting the virus is real and I'm not saying its a fake, however I'm saying that its not as cracked up as it played out to be.

  2. CODECALL Circuit advertisement
    Join Date
    Always
    Location
    Advertising world
    Posts
    Many

     
  3. #12
    Johnson695 is offline Newbie
    Join Date
    Jun 2009
    Posts
    2
    Rep Power
    0

    Re: Conficker??? real or fake

    fake even if you try you wont get it sorry

  4. #13
    Pro
    Pro is offline Newbie
    Join Date
    Jun 2009
    Location
    Newbury Park, CA
    Posts
    7
    Rep Power
    0

    Re: Conficker??? real or fake

    Johnson695:

    hxxp://google.com/#hl=en&q=Conficker

    No, Conficker is real. Unless all this is just some made up by magic voodoo CIA/NSA agent controlling google to put out a fake worm that never existed. Also the magic voodoo CIA/NSA agent would have to pay off all of those reverse engineers, anti malware companies, and random bloggers / pod casters around the world reporting there findings. It's real, sorry.

    ReignInChaos:

    This worm does do some revolutionary stuff when it comes to malware. Although it spreads using some "old methods" the way it authenticates is in my opinion beautiful. Not saying its new, but it's new to malware.

    It's also unlikely that "they" wanted this attention. However "they" did prepare for it seeing how it wont target anything in Poland (if I recall correctly). Likely done to avoid getting arrested if found out.

  5. #14
    Showstopper's Avatar
    Showstopper is offline Programmer
    Join Date
    Jul 2009
    Posts
    170
    Blog Entries
    3
    Rep Power
    12

    Re: Conficker??? real or fake

    How Conficker makes use of MS08-067 ?

    This article concerns the spreading technique used by this virus, particularly the way it exploits the MS08-
    067 security vulnerability in the Server Service of Windows.

    MS08-067 Technical Details.
    RPC protocol in Server Service supports a remote procedure converting any path (for instance,
    \\C\Program Files\..\Windows) to Canonicalization path (\\C\Windows). But Windows does not handle well
    overly long path, resulting in buffer overrun.
    To concretize, Windows (svchost process) uses NetpwPathCanonicalize() function of netapi32.dll library
    to perform the above mentioned operation. The pseudo-code comes following:
    func _NetpwPathCanonicalize(wchar_t* Path)
    {
    // check Path length
    if( !_function_check_length(Path) )
    return;
    ...
    _CanonicalizePathName(Path);
    ...
    return;
    }
    func _CanonicalizePathName(wchar_t* Path)
    {
    // protect stack with cookie - /GS
    _save_security_cookie();
    ...
    wchar _wcsBuffer[420h];
    ...
    // this is the function causing the overrun
    wcscat(wcsBuffer,Path);
    ...
    // converting function
    _ConvertPathMacros(wcsBuffer);
    ...
    return;
    }
    As we can see from the pseudo-code, NetpwPathCanonicalize() checks the length of the path before
    passing it into CanonicalizePathName() function. However, CanonicalizePathName() uses wcscat() to
    copy the path into a local variable (wcsBuffer). The consequence is that the function wouldn’t create a
    buffer-overflow in the first run but it would in the subsequents. For example, the contents of wcsBuffer
    after each call to this function would be:
    - Call 1 : wcsBuffer = “\\a\aaaaa\aaaa\..\..\a”
    - Call 2 : wcsBuffer = “\\a\aaaaa\aaaa\..\..\a\\a\aaaaa\aaaa\..\..\a”
    - Call 3 : wcsBuffer = “\\a\aaaaa\aaaa\..\..\a\\a\aaaaa\aaaa\..\..\a\\a\a aaaa\aaaa\..\..\a”
    -...
    So we can definitely overflow Server Service with several calls to NetpwPathCanonicalize() function
    remotely providing appropriate path length. Up to this point, it seems as if the road had been cleared out.
    But two other obstacles appear:
    Cookie: The CanonicalizePathName() function was built with /GS option, which protects it with a
    cookie put before the return address. Whenever the return address is overwritten, so is the cookie
    and the system therefore knows that a buffer overflow has been encountered.
    DEP: the process of Server Service (svchost.exe) is protected with DEP by default. As a result, if
    Shellcode is put on stack, DEP won’t allow code execution.
    What exploiting techniques were used by Conficker?
    Now let’s draw our attention to a function used in CanonicalizePathName(), which is called
    ConvertPathMacros() by Microsoft. This function does not perform any check against the cookie and
    hence was taken advantage by Conficker to redirect control to Shellcode.
    The article of Microsoft [2] also mentioned the ConvertPathMacros() function but did not describe its role
    in the exploitation correctly. More precisely, Microsoft pointed out that this function used a local variable
    to store the buffer and the exploitation would overflow it in order to overwritten the return address of
    ConvertPathMacros().
    But in actuality, ConvertPathMacros() does not have any portion of code that directly copies and
    overflows such local buffer. It is made possible to overwrite the return address of this function owing to a
    weakness in its string processing algorithm. As a consequence, wcscpy() function, which is called within
    ConvertPathMacros(), has its return address overwritten.
    For DEP bypassing, Conficker makes use of ZwSetInformationProcess() function to disable DEP in
    runtime mode. After that, Conficker redirects control to Shellcode on stack.
    Conficker uses instructions available in AcGenral.dll library, which is loaded by svchost, to overcome both
    previous protection mechanisms.
    So with this method of exploiting, Conficker just needs to call NetpwPathCanonicalize() one time to
    successfully attack.
    Spreading module of Conficker
    Using above exploiting techniques, Conficker can exploit many different Windows versions (XP SP2/SP3,
    English, Italian,...). With a particular IP address, Conficker will try attacking with a lot of malicious code,
    each for one version of Windows. This increases the rate of success. Here comes the pseudo-code:
    func __Thread_Attack (IpAddress)
    {
    ...
    // Create an Url for shellcode to download virus.
    url = Make_Url_Download();
    ...
    While(1)
    {
    // If connection fails, abort.
    if( ! IsConnect(IpAddress)) return;
    ...
    // Create attacking buffer, each time call Make_Buffer(),
    // a buffer for a particular Windows version will be created.
    buffer = Make_Buffer(url, buffer);
    ...
    // Attack
    Attack(IpAddress, buffer);
    // Wait 1 second, if successfully exploit, break from the loop.
    // if not, try the next exploiting buffer.
    if( WaitForSingleObject(1000) != WAIT_TIMEOUT ) break;
    }
    }
    Conficker Shellcode activity
    - Decode (Xor with 0xC4).
    - Get the addresses of necessary API functions: LoadLibrary(), ExitThread().
    - Load urlmon.dll library into the process.
    - Get the address of URLDownloadToFileA() function in urlmon.dll.
    - Download virus from the attacking computer using http protocol.
    - Source address used for download: http://xxxxxxort/xxxxx
    - Downloaded virus is saved under the name x.
    - Kill the thread (ExitThread).

    After reversing Conficker, I found 51 Windows versions that could be attacked by Conficker (SP1, SP2
    SP3 and languages are considered different versions). One interesting thing is that the addresses of the
    exploiting module for different versions of Windows used by Conficker are the same as those of
    metasploit exploit code. This shows high possibility that the virus creator take these addresses from
    metasploit. The following a list of operating system susceptible to Conficker.
    1 Windows 2000.
    2 Windows XP SP2/SP3 English.
    3 Windows XP SP2/SP3 Arabic.
    4 Windows XP SP2/SP3 Taiwan.
    5 Windows XP SP2/SP3 Chinese.
    6 Windows XP SP2/SP3 Czech.
    7 Windows XP SP2/SP3 Danish.
    8 Windows XP SP2/SP3 German.
    9 Windows XP SP2/SP3 Greek.
    10 Windows XP SP2/SP3 Spanish.
    11 Windows XP SP2/SP3 Finnish.
    12 Windows XP SP2/SP3 French.
    13 Windows XP SP2/SP3 Hebrew.
    14 Windows XP SP2/SP3 Hungarian.
    15 Windows XP SP2/SP3 Italian.
    16 Windows XP SP2/SP3 Japanese.
    17 Windows XP SP2/SP3 Korean.
    18 Windows XP SP2/SP3 Dutch.
    19 Windows XP SP2/SP3 Norwegian.
    20 Windows XP SP2/SP3 Polish.
    21 Windows XP SP2/SP3 Brazilian.
    22 Windows XP SP2/SP3 Portuguese.
    23 Windows XP SP2/SP3 Russian.
    24 Windows XP SP2/SP3 Swedish.
    25 Windows XP SP2/SP3 Turkish.
    26 Windows 2003 SP1/SP2 English.

  6. #15
    dirkfirst is offline Programming Expert
    Join Date
    May 2006
    Posts
    354
    Rep Power
    23

    Re: Conficker??? real or fake

    I heard a lot about this virus but I haven't heard of anyone becoming infected. Did anyone get this virus?

  7. #16
    Showstopper's Avatar
    Showstopper is offline Programmer
    Join Date
    Jul 2009
    Posts
    170
    Blog Entries
    3
    Rep Power
    12

    Re: Conficker??? real or fake

    Quote Originally Posted by dirkfirst View Post
    I heard a lot about this virus but I haven't heard of anyone becoming infected. Did anyone get this virus?
    Yeah there was an educated guess that the botnet had around 10million people. I dont know how they came up with that but I would disagree. I have analyzed HJT logs that had conficker.

  8. #17
    forerx is offline Newbie
    Join Date
    Aug 2009
    Posts
    1
    Rep Power
    0

    Re: Conficker??? real or fake

    I think it fake , what about you?
    Thank you for your article(Made Easy Forex)

  9. #18
    Join Date
    Jun 2007
    Location
    Kosovo
    Posts
    660
    Rep Power
    23

    Re: Conficker??? real or fake

    conficker is a creat worm i heard that the programmer is german thats why the name is conficker Con for Configuration and Ficker for Fucker the most coolest part is that the whole code is polymorphic

  10. #19
    h4x Guest

    Re: Conficker??? real or fake

    windows = toy for nabs.
    only those will get infected. too bad money from bank can be traced.

  11. #20
    Join Date
    Oct 2007
    Location
    /dev/null
    Posts
    4,513
    Blog Entries
    8
    Rep Power
    59

    Re: Conficker??? real or fake

    I think it's a sort of Sasquatch or Loch Ness Monster. There have been grainy pictures, molds of footprints, etc., but no one has ever caught one. Very likely it could still exist...very elaborate hoax if it's not.
    Last edited by dargueta; 09-14-2009 at 08:34 PM. Reason: Fixed bad grammar
    sudo rm -rf /

Closed Thread
Page 2 of 2 FirstFirst 12

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Similar Threads

  1. Real basic
    By Qwerty73 in forum Visual Basic Programming
    Replies: 4
    Last Post: 10-27-2010, 11:48 AM
  2. Fake Progress Bar?
    By hibby50 in forum C# Programming
    Replies: 7
    Last Post: 04-16-2009, 06:58 PM
  3. Access App to real App
    By makenoiz in forum General Programming
    Replies: 2
    Last Post: 01-16-2009, 08:03 PM

Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts