Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | [NT] WINS Replication Remote Vulnerability |
|---|---|
| Date: | 29 Nov 2004 10:52:05 +0200 |
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com - - promotion The SecuriTeam alerts list - Free, Accurate, Independent. Get your security news from a reliable source. http://www.securiteam.com/mailinglist.html - - - - - - - - - WINS Replication Remote Vulnerability ------------------------------------------------------------------------ SUMMARY WINS is "a Microsoft NetBIOS name server, that basically eliminates the need for broadcast packet to resolve a NetBIOS computer name to an IP address". WINS has a feature called WINS replication, where one or more WINS servers exchange information with each other about the computers on their respective networks. WINS replication is done on TCP port 42 using a Microsoft proprietary protocol. During this protocol flow, a memory pointer is sent from server to client, and the client uses that to talk with the server. If a special crafted packet is sent to the server, an attacker can control the pointer and can make it point to an attacker-controlled buffer and eventually write 16 bytes at any location. DETAILS Affected: All known versions of Wins.exe are affected. Windows 2000 SP2-4 were tested. Technical Details: The packet that we are sending looks like this: ---------------------------- | size of packet | (excluding 4 bytes of size field) ---------------------------- | XX XX FF XX | ---------------------------- | real addres pointer | ---------------------------- | identified long | ---------------------------- | ... (etc) | ---------------------------- The size of the packet is passed as argument to HeapAlloc (wins checks that size is less than 0x2F87F8). The second dword is the condition we have to pass to trigger the bug. Finally the address pointer that from now on we call "myself" points to a special structure used by wins to exchange information between servers. To exploit it, what we do is try to point myself to a buffer that we can control, what we do is send a big packet of about 0x40000 bytes so we can guess where it would be. Once we point to something that we control, we need to point to a specific structure that looks like this: ---------------------------- | WHERE -x048 | ---------------------------- | ... | ... ---------------------------- | WHAT | 0x24 ---------------------------- | WHAT2 | ---------------------------- | WHAT3 | ---------------------------- | WHAT4 | ---------------------------- Obviously, where is the address that we want to write to, and what* are the 16 bytes that we are writing to where address. So we have three problems arise: (a) How to point exactly to our crafty structure b) Where to write (c) What to write The (a) point is resolved creating a special structure with "where-0x48" * 9 and what * 14, if we repeat this structure, we could brute force the structure and with less than 3 tries we will have our Write16 primitive. (Note: Access Violations are caught by wins.exe). The (c) point is resolved guessing an approximate address of the 0x40000 bytes malloc. Now, (b) point is the hardest value to find, and is related to point (a) and c. Because as Oded Horovitz has documented, and common sense says, when a large amount of bytes is freed, it is returned back to the OS, and the consequence are that our function pointer has to be triggered before HeapFree is executed, so we have to discard PEB function pointer. In order not to loose all the advantages that the big buffer gives us, we try to find the return address by brute forcing the stack. Useful ollydbg breakpoints (SP3) Breakpoints: Address Module Active Disassembly Comment 01012EEC wins Always CALL DWORD PTR DS:[<&KERNEL32.Create 01013404 wins Log MOV EDI,DWORD PTR DS:[<&KERNEL32.lst 01013413 wins Log MOV ESI,DWORD PTR DS:[<&KERNEL32.lst 01015D93 wins Log CALL DWORD PTR DS:[<&KERNEL32.lstrcp 0101811D wins Log CALL DWORD PTR DS:[<&KERNEL32.lstrcp 0102117C wins Always PUSH ESI 0102122E wins Always MOV ESI,wins.01026520 01021274 wins Always ADD EAX,4 01021294 wins Always CMP EAX,-1 010212AE wins Always ADD EDX,4 010212DA wins Always PUSH wins.01026A68 010212E4 wins Always CALL wins.01012ACC 01021368 wins Always PUSH wins.01003CAC 01021397 wins Always JMP wins.010212FF 010213E7 wins Always CALL wins.01022C8B recv 240 01021403 wins Always CALL wins.010224AA recv4 01021423 wins Always JNB wins.010212FF 0102143E wins Always CALL <JMP.&WS2_32.#151> 01021460 wins Always CALL wins.0102185C 010214CF wins Always DEC ECX 010214E9 wins Always JMP SHORT wins.010214C9 010214F7 wins Always JMP wins.01021416 01021526 wins Always CALL DWORD PTR DS:[<&WS2_32.#1>] 01021563 wins Always CALL wins.01012806 0102158A wins Always CALL wins.01012DB1 010215B8 wins Always JNZ SHORT wins.010215C3 010215C8 wins Always CALL wins.01022040 010215D2 wins Always XOR EAX,EAX 01021614 wins Always CALL DWORD PTR DS:[<&KERNEL32.Interl 01021622 wins Always MOV DWORD PTR SS:[EBP-4FC],ESI 0102165E wins Always CALL wins.01012DB1 01021676 wins Always JE wins.010212FF 0102167F wins Always CALL DWORD PTR DS:[<&WS2_32.#14>] 010216BE wins Always CALL wins.01012806 01021790 wins Always JMP wins.010216FC 010217EE wins Always MOV EAX,DWORD PTR SS:[EBP-14] 0102197D wins Always PUSH EBP 0102252B wins Always MOV EAX,DWORD PTR SS:[EBP-4] 010225FE wins Always CALL wins.0102240C Discovery Method: This exploit was discovered by tracing through the processes with Ollydbg and manually analyzing the disassembly by Nicolas Waisman. History: Research and Exploited by Immunity Researcher Nicolas Waisman, May, 2004. Released to VSC May, 2004. Released to public 26 November, 2004 ADDITIONAL INFORMATION The information has been provided by Nicolas Waisman. The original article can be found at: <http://www.immunitysec.com/downloads/instantanea.sxw> http://www.immunitysec.com/downloads/instantanea.sxw ======================================== This bulletin is sent to members of the SecuriTeam mailing list. To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com ==================== ==================== DISCLAIMER: The information in this bulletin is provided "AS IS" without warranty of any kind. In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [NT] MailEnable IMAP Service Remote Buffer Overflow, SecuriTeam |
|---|---|
| Next by Date: | [EXPL] Remote Buffer Overflow in Prozilla, SecuriTeam |
| Previous by Thread: | [NT] MailEnable IMAP Service Remote Buffer Overflow, SecuriTeam |
| Next by Thread: | [EXPL] Remote Buffer Overflow in Prozilla, SecuriTeam |
| Indexes: | [Date] [Thread] [Top] [All Lists] |