Nytro

Da, cred ca s-au terminat, ziceau cei de la suport ca au fost activate toate 5. Am sters din primul post licenta.

[TABLE=width: 626] [TR] [TD=width: 365, align: left]Renewal Kaspersky PURE 3.0 - 5 licenses (1 year)[/TD] [TD=width: 111, align: center]1[/TD] [TD=width: 75, align: right]$109.00[/TD] [TD=width: 75, align: center][/TD] [/TR] [TR] [TD=colspan: 2, align: center][TABLE=width: 476] [TR] [TD=bgcolor: #e5e5e5, align: center]Activation code: M19SY-VZ6BW-15VZF-REMOVED [/TD] [/TR] [/TABLE] [/TD] [/TR] [/TABLE] Am activat pe 3-4 calculatoare, deci ar trebui sa mai fie posibila activarea pe 1-2. Am rugamintea sa postati daca a mers sau nu. Nota: Kaspersky este dupa parerea mea cel mai bun antivirus, dar daca nu aveti un PC bun nu va obositi sa il instalati. Consuma extrem de multe resurse. Merge greu si un i5, cel putin cu setarile "paranoia" facute de mine.

Stiu ca e o porcarie, dar na, poate ii e util cuiva. Discount 10 euro pentru Agentie de turism – Oferte turism | Veltravel . Cod: VEL6MYLFGWR Valabilitate: 30 de zile calendaristice.

La mine, CodeBlocks + MinGW, la 1: 16777217.0 16777218.0 Am gresit pe 2. In C afiseaza "1". In C++ cu "-fpermissive" afiseaza tot "1". Nu am nici cea mai mica idee de ce. Restul le-am stiut.

Imi cumparasem pentru un an, dar nu il mai folosesc. Nu mai are chiar un an de valabilitate, dar cred ca mai e destul. Username: nytro Email: admin -at- rstforums . com Creation Date: 2014-02-17 (17.02.2014) Expiration Date: 2015-03-17 (17.03.2015) VPN Country: RU Plan: Dedicated IP Type of IP: UDP/1194 Assigned IP: 185.17.1.188 ---------------------------------------------- User: nytro Password: http://rstrullz (fara http - ca sa vada doar Registered users) ---------------------------------------------- Nu schimbati parola. PS: Nu puteti schimba adresa de mail fara "acordul meu". Asadar nu va obositi sa schimbati parola.

Bypassing Windows 8.1 Mitigations using Unsafe COM Objects In October last year I was awarded the first $100,000 bounty for a Mitigation Bypass in Microsoft Windows. My original plan was to not discuss it in any depth until Microsoft had come up with a sufficient changes to reduce the impact of the bypass. However as other researchers have basically come up with variants of the same technique, some of which are publically disclosed with proof-of-concept code it seemed silly to not discuss my winning entry. So what follows is some technical detail about the bypass itself. I am not usually known for finding memory corruption vulnerabilities, mainly because I don’t go looking for them. Still I know my way around and so I knew the challenges I would face trying to come up with a suitable mitigation bypass entry. I realised that about the only way of having a successful entry would be to take a difficult to exploit memory corruption vulnerability and try and find a way of turning that into reliable code execution. For that reason I settled on investigating the exploitation of a memory overwrite where the only value you could write was the number 0. Converting a 0 overwrite of this sort, while not impossible to exploit, certainly presents some challenges. I also stated that I could not disclose the existing contents of memory. If you have an information disclosure vulnerability then it is generally game over anyway, so I was confident that would not pass for a winning entry. ActiveX and COM The attack vector for the mitigation bypass was safe-scriptable COM objects. As COM is a general technology, not limited to safe-scripted environments such as Internet Explorer, there are many unsafe objects which could be abused if they were allowed to be created. To prevent this, hosts, such as Internet Explorer, use two mechanisms to determine whether an object is safe for being used in the host environment, Category IDs and the IObjectSafety interface. The Category IDs, CATID_SafeForScripting and CATID_SafeForInitializing can be added to a COM object registration to indicate to a COM host that the object is safe for either scripting or initialisation. These are static indicators, and are not particularly of interest. Things get more interesting with the IObjectSafety interface which is implemented by the COM object. The host can call the GetInterfaceSafetyOptions method to determine whether a COM object is safe to script or initialise (of course this means that the object must have already been created). The interface also has a secondary purpose; once a host has determined that an object is safe it can call the SetInterfaceSafetyOptions method to tell the object how safe it needs to be. This method has a particular implication; it allows COM objects to be written in a generic way with potentially dangerous functionality (such as arbitrary script code execution) and then secured at runtime by disabling the unsafe functions. The typical way this is implemented is by setting flags within the object's memory to indicate the security of the object. This is the attack vector chosen. If we have a suitable memory corruption vulnerability it might be possible to change these security flags to convert a secure object back to an insecure one and use that to circumvent in-place mitigations. A related topic is the setting of an object's site. A Site is normally a reference to the hosting environment for the COM object, such as the OLE container or hosting HTML document. This makes a number of security related functions possible, such as enforcing the same-origin policy for COM objects in a web page (through querying for the IHTMLDocument2 interface and reading the URL property), zone determination or accessing the host security manager. Depending on what we attack we might need to deal with the Site as well. The important point of all this is by default there are many objects which are unsafe until certain flags are stored within the memory allocated for the object. Therefore the unsafe state of these flags is the value 0, where as the safe state is non-zero. This means that if we have got a 0 overwrite vulnerability we can reset the security flags back to the unsafe state and exploit the unsafe functionality of the COM object. Attacking MSXML To demonstrate an attack against scriptable COM objects a suitable object is needed. It must meet some set of criteria to allow us to use the memory corruption vulnerability to bypass mitigations. I determined that the criteria were: The object must be creatable in common COM hosts without significant security issues such as being blocked by policy or site locking The object must be available on default Windows installations or be extremely common The object must do something of benefit to an attacker when insecure, but not expose that functionality when secure (otherwise it would just be a security vulnerability) It must be relatively trivial to convert from secure to insecure through a minimal number of zero memory overwrites The COM objects chosen for the demonstration are implemented by the MSXML libraries. Windows 8.1 comes with versions 3 and 6 of the MSXML library installed by default. They are pretty much considered de-facto secure as without them some websites would break; therefore there are no issues with site-locking or blacklisting. They can even be created in the immersive version of IE without issue. They also have some significant functionality when insecure, namely the ability to circumvent same-origin policy and also to execute fully-privileged scripts within the context of XSL transformation. So MSXML meets the first three criteria, but what about the 4th? Many of the objects that MSXML exposes implement the IObjectSafety interface which is the mechanism through which safety is enabled as shown above. The object also supports the INTERFACE_USES_SECURITY_MANAGER flag which means that the object will utilise the security manager from the hosted site to make some trust decisions. Through reverse engineering the safe objects such as DOMDocument and XMLHTTP, it can be seen that they all contain the COMSafeControlRoot structure, which is used to implement the IObjectSafety and security manager features. In MSXML3 this consists of 6 fields, in the default insecure version these values are all NULL, while in a secure version they contain pointers to site objects and security managers as well as the current security flags set through SetInterfaceSafetyOptions. The rough outline of this structure is shown below: Through inspection, I found that of the 6 values in memory only two were important when it came to bypassing the security mechanisms. This was a pointer to the host security manager at offset 4 and the security flags at offset 20. Crucially these can be reverted back to NULL without causing any other significant effect on the object’s functionality. This means that a very restricted memory corruption could achieve the desired effect, namely our overwrite with zero. Finding an Object in Memory The biggest issue with this technique is that whilst it would be easy enough to modify an object in memory to disable the security without an information disclosure vulnerability, we would not know where it was. If you had an information disclosure vulnerability you probably would not need to use this technique at all. The bypass must be able to guess the location of a valid object in memory and attack it blind. The design of typical scriptable COM hosts come in handy here to achieve this goal. They usually allow you to create an arbitrary number of new objects, this allows for the heap to be flooded with object instances The allocation of COM objects is up to the COM library to implement; therefore it might not be using best practice or it might disable security mitigations The scripting ability allows for executing specific sequences of operations to improve reliable allocation patterns In the general case this makes it a lot easier to use a heap flood technique to generate a reliable pattern of objects on the heap and of a large enough size to guess the location of an object. If a regular pattern of objects can be achieved we can use an arbitrary overwrite to modify values in memory through a guessed location and then find the insecure object to execute our code. There are some issues with the heap improvements in Windows 8. For a start there is a new mitigation called Low Fragmentation Heap Randomisation. The Low Fragmentation Heap (LFH) is a special memory heap used for small allocations to reduce the amount of memory fragmentation that occurs during allocation and freeing of memory. In Windows 8 the order of what blocks is allocated has a random element to it. This makes it more difficult to lay out guessable patterns of allocations. At least once you start allocating 1000s of objects it is still possible to find some level of reliability for allocations. However MSXML3 provides an ideal case, presumably for legacy reasons when running on a multi-processor system it creates its own heap passing the HEAP_NO_SERIALIZE flag. This means that the LFH is disabled which also disables some of the heap improvements in Windows 8. This makes the heap flooding considerably more reliable. The targeted COM object in that library is MSXML2.XMLHTTP.3.0. This is because this object has a considerably smaller heap footprint than DOMDocument which would be the more obvious choice. As long as the object is opened you can read the requestXML property (even without sending the request) to get a DOMDocument object. This document inherits the security settings of the parent XMLHTTP object which allows us to modify XMLHTTP and then use that to execute arbitrary script code. To lay out the heap the provided PoC creates 40,000 instances of XMLHTTP and stores them in an array. Each instance also has the ‘open’ method called on it and a request header set to increase the allocation size for a single object. This results in a repeating 8192 byte pattern of objects being created in memory which looks similar to the following: The actual code was quite simple: Once the heap was flooded the next step was to write the 0 values to a guessed address. The address was chosen empirically, and for the proof-of-concept the overwrite was actually performed using a custom control rather than a real memory corruption vulnerability. By guessing the base address of an object and writing 0s to offsets 4 and 20 we will have disabled the security on one XMLHTTP object, we just need to find which one. For that, the proof-of-concept just enumerated all allocated objects trying each one in turn with a XSL document with an msxsl:script tag containing JScript to start notepad. If the object is still secure then this process will throw an exception, if not we succeeded, notepad has been executed and we can stop looking. Real World Zero Overwrites Of course this entire bypass is predicated on finding a vulnerability which allows you to do an arbitrary overwrite with a 0. How likely is that in the real world? Well honestly I can not give any figures but don't forget that 0 is the typical default state for values, so any code which tries to initialize a value under an attackers control will probably set it to zero. A good example is COM itself. Every COM object must implement the IUnknown interface, the first function QueryInterface is used to convert the object to different interface types. It takes a pointer to the IID and a pointer to a pointer for the returned interface, assuming it supports the required interface. It is recommended that if the object doesn't support the interface it should ensure the outbound pointer is set to NULL before returning. If you've already guessed the location of a COM object you might only be a V-Table dereference away from your coveted arbitrary zero overwrite. Conclusions Obviously this particular example has limitations. It only worked reliably in 32 bit versions of IE as heap flooding is very difficult to do in a reliable way on 64 bit. Of course if you combined this technique with a memory disclosure vulnerability you can achieve code execution without needing to control EIP. The technique is more general than just COM objects in IE. Any structure in a program which has both safe and unsafe functionality is a suitable target. The PoC was necessary to demonstrate the potential. It is interesting that techniques like this are subject to convergent discovery, I wasn't the only person to stumble upon a similar idea, the only reason it is an issue now is the easy routes of exploitation have been closed. Sursa: Bypassing Windows 8.1 Mitigations using Unsafe COM Objects

PE: Portable Executable. Adica .exe, .dll, .sys, nu conteaza limbajul. Dar imi place mai mult asta: https://rstforums.com/forum/86741-cff-explorer.rst

PE Insider PE Insider is a free Portable Executable viewer for the community. It shares the same codebase for inspection as Cerbero Profiler and hence it supports the entire PE specification and is incredibly fast and stable. Click here to download the setup. Sursa: Cerbero - PE Insider

CFF Explorer [TABLE] [TR] [TD]Small announcement: the CFF Explorer was started as a side project many years ago. While I will continue to release updates from time to time, it is not going through radical improvements. If your organization needs professional PE inspection (not editing), then you might take a look at Cerbero Profiler (the commercial product of my company), which properly supports many file formats beyond the complete Portable Executable specification. In addition to that we also offer a completely free PE viewer for the community called PE Insider. [/TD] [TD] [/TD] [/TR] [/TABLE] Created by Daniel Pistelli, 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. Resource Editor (Windows Vista icons supported) capable of handling .NET manifest resources. The suite is available for x86 and x64. - Explorer Suite (Multi-Platform Version, Recommended) SHA1: 89CAB44D4956210570AB3123FBF13B2B7D870B91 - CFF Explorer (x86 Version, stand-alone, Zip Archive) SHA1: 7A287CD97BD9287C020C98C3496E284D04F5382D - CFF Explorer Extensions Repository The CFF Explorer was designed to make PE editing as easy as possible, but without losing sight on the portable executable's internal structure. This application includes a series of tools which might help not only reverse engineers but also programmers. It offers a multi-file environment and a switchable interface. Also, it's the first PE editor with full support for the .NET file format. With this tool you can easily edit metadata's fields and flags. If you're programming something that has to do with .NET metadata, you will need this tool. The resource viewer supports .NET image formats like icons, bitmaps, pngs. You'll be able to analyze .NET files without having to install the .NET framework, this tool has its own functions to access the .NET format. Useful links: - How to write a CFF Explorer Extension - CFF Explorer Scripting Language Documentation (v2) - CFF Explorer Scripting Language Documentation (v1) - CFF Explorer Extensions Repository Features: Process Viewer Drivers Viewer Windows Viewer PE and Memory Dumper Full support for PE32/64 Special fields description and modification (.NET supported) PE Utilities PE Rebuilder (with Realigner, IT Binder, Reloc Remover, Strong Name Signature Remover, Image Base Changer) View and modification of .NET internal structures Resource Editor (full support for Windows Vista icons) Support in the Resource Editor for .NET resources (dumpable as well) Hex Editor Import Adder PE integrity checks Extension support Visual Studio Extensions Wizard Powerful scripting language Dependency Walker Quick Disassembler (x86, x64, MSIL) Name Unmangler Extension support File Scanner Directory Scanner Deep Scan method Recursive Scan method Multiple results Report generation Signatures Manager Signatures Updater Signatures Collisions Checker Signatures Retriever [TABLE] [TR] [TD] Download the Explorer Suite [/TD] [TD] [/TD] [/TR] [/TABLE] [TABLE] [TR] [TD] [/TD] [TD] [/TD] [/TR] [/TABLE] Sursa: NTCore's Homepage

Avem un plan mai bun pentru asa ceva.

Deocamdata e ok o singura categorie de lucruri "free". Daca se vor gasi multe chestii "premium" de postat, vom face o subcategorie. Deocamdata, la ce se posteaza acolo, are acces oricine.

Four months ago we reviewed Bitdefender Internet Security 2014. The developer has just released the 2015 version of the antivirus application, bringing in new features and improvements concerning usability. We had the opportunity to take a look at the new product a bit early and evaluate it for ourselves. July 9th, 2014, 16:00 GMT · By Elena Opris NOTE: Bitdefender Internet Security 2015 was tested on 64-bit Windows 8.1 Pro. Installation and interface The setup procedure is similar to the one in the previous edition. It is speedy and customizable in terms of installation directory and proxy settings. Although it is not mentioned anywhere in the installer, the tool integrates a couple of entries into the Windows Explorer context menu, in order to quickly scan and shred files, folders and drives. As far as the interface is concerned, Bitdefender preserves the same dark and green theme. However, the buttons are flatter now and some elements have been removed to make the look cleaner overall. [TABLE=align: center] [TR] [TD][/TD] [TD][/TD] [/TR] [/TABLE] Install Bitdefender and visit the main panel The largest three buttons in the main menu provide access to the protection and privacy modules along with tools, while four lesser buttons enable users to quickly perform a scan, check for virus definition updates, optimize the disk by resolving junk files, invalid registry keys and privacy issues, as well as navigate the Internet via Safepay, Bitdefender's proprietary web browser which ensures secure online transactions. The autopilot mode can be activated with one click to apply optimized settings and let the application handle any threats automatically, thus letting users proceed with their usual PC activities. If disabled, it is possible to select an ideal profile based on the type of activity: standard, work, game or movie. PC protection configuration Bitdefender implements six layers of protection against viruses, worms, Trojans, rootkits, adware, spyware, and other types of malware: antivirus, vulnerability scans, antispam, firewall, web protection, and intrusion detection. [TABLE=align: center] [TR] [TD][/TD] [/TR] [/TABLE] Go to Protection to view all security modules Computer scans can be performed quickly to look into the usual hiding places of the system, such as Program Files and the Windows directory. When it comes to scan configuration, it is possible to adjust the on-access scanning and active virus control levels (permissive, normal, aggressive), create exclusions (files, CD/DVD and USB devices, mapped network drives) and personalize quarantine settings (e.g. delete old content). Additional scan options focus on the file types to take into account (all, only programs, archives) and types of objects to target (e.g. boot sectors, memory, registry, cookies, rootkits). These settings are also applicable to scheduled scan tasks. [TABLE=align: center] [TR] [TD][/TD] [TD][/TD] [/TR] [/TABLE] Configure antivirus settings and manage scan jobs Custom scans can be scheduled and created by specifying the exact files, directories and drives to verify, along with the severity level to favor either resources consumption or speed. They can be set to run with low priority, minimize the scan wizard to the system tray, as well as to shut down the PC, close the scan window or just show the summary window if no threats are found. Just like in the 2014 version, this new edition contains Rescue Mode, a feature that should be used in critical scenarios when the computer can no longer boot properly due to virus malware infiltration. [TABLE=align: center] [TR] [TD][/TD] [TD][/TD] [/TR] [/TABLE] Configure vulnerability settings and run a scan Vulnerability scans verify the operating system for weak points by looking into critical Windows updates, application updates, weak passwords, and media autorun. The antispam module filters emails in clients using the POP3 protocol, in order to weed out dangerous or unwanted messages. It can be set to block emails written in Asian or Cyrillic characters, submit spam and legit samples to the cloud to share information with other users in the Bitdefender community, as well as manage email addresses and domains separately for friends and spammers. [TABLE=align: center] [TR] [TD][/TD] [TD][/TD] [/TR] [/TABLE] Configure antispam and firewall settings Bitdefender comes packed with its own personal firewall that is automatically turned on at installation while deactivating the Windows Firewall to prevent any conflicts. It can block Internet Connection Sharing and network port scans, monitor wireless connections, follow pre- and user-defined rules to allow or deny Internet access to active processes, as well as manage network adapters. Web protection is provided by default via Search Advisor (a browser assistant that indicates trustworthy and suspicious websites), SSL scanning, along with shields against fraud and phishing links. The Bitdefender Toolbar is optional and includes the previously mentioned components which can be easily activated and deactivated with one click, together with a sandbox feature that confines all browsing activities into a virtual and secure environment. Any URLs can be excluded from the web protection module by adding them to a whitelist. [TABLE=align: center] [TR] [TD][/TD] [TD][/TD] [/TR] [/TABLE] Configure web protection and intrusion detection settings Lastly, the intrusion detection system is a safety measure against hacker attempts to get in the computer and corrupt data. It prevents any modifications to the critical system files and registry entries, informs users about DLL injection-based attacks and blocks the installation of malware drives. Its severity level can be set to permissive, normal or aggressive. Privacy configuration Bitdefender's privacy component has multiple purposes. It can securely delete files via File Shredder (also accessible via the Explorer context menu) to prevent third parties from recovering them using specialized tools, as well as monitor children's activity online and keep track of lost or stolen notebooks or Android devices via the parental control features (it requires online registration, free). [TABLE=align: center] [TR] [TD][/TD] [TD][/TD] [/TR] [/TABLE] Configure privacy settings and manage the Bitdefender Apart from the Safepay feature which was previously discussed, Bitdefender includes a Wallet that saves all login credentials to any sites when surfing the Internet (supported by Internet Explorer, Mozilla Firefox, Google Chrome), apps, email clients and wireless connections, putting them in a safe location protected with a password which is requested at every system startup (handy if the PC is shared with other users). It can be exported to file and imported on another computer running Bitdefender. New tools Internet Security 2015 brings additional tools dedicated to PC tuneup. OneClick Optimizer looks for junk files that unnecessarily take up disk space, invalid registry entries which may prevent system issues, along with browser traces that may compromise the user's activity, such as cache, cookies, temporary files and visited links. [TABLE=align: center] [TR] [TD][/TD] [TD][/TD] [/TR] [/TABLE] Visit the tools section and optimize the system with one click Startup Optimizer gives users the possibility of delaying or disabling apps which automatically run at system boot to increase Windows startup speed, as well as to view the boot time of each program and overall system. [TABLE=align: center] [TR] [TD][/TD] [TD][/TD] [/TR] [/TABLE] Manage autostart entries and clean up the PC PC Cleanup can be performed with typical settings to take into account browser cache, error reporting files, memory dumps and Windows junk files, or with customized options by excluding any of these areas. [TABLE=align: center] [TR] [TD][/TD] [TD][/TD] [/TR] [/TABLE] Defragment the disk and clean the registry A disk defragging tool allows users to select the exact drives to analyze and reduce fragments on and ensure better computer performance, while the registry cleaner tool previously mentioned in the OneClick Optimizer module can be separately run and personalized in terms of registry areas to clean (after analyzing all of them). [TABLE=align: center] [TR] [TD][/TD] [TD][/TD] [/TR] [/TABLE] Restore registry backups and identify duplicate files All registry keys are automatically backed up before removal, and they can be restored using a separate component. Furthermore, Bitdefender integrates a function that identifies and removes duplicate files in order to free up disk space and declutter the system. As far as profile configuration goes, it is possible to enable real-time optimization and let Autopilot manage profiles, activate battery mode for notebooks, as well as make some tweaks to the work, movie and game profiles, such as postponing Windows automatic updates along with user-defined background programs and maintenance tasks, as well as adjusting the power plan and visual settings for movies and games. [TABLE=align: center] [TR] [TD][/TD] [TD][/TD] [/TR] [/TABLE] Manage profile settings and examine events A feature available in the 2014 edition too, Safego is specially designed for Facebook to scan all links sent and received from friends via various locations like News Feed and comments, in order to make sure they are not infected with malware. It can be remotely accessed and has a mobile version available for smartphones. Events concerning each major component can be examined in a log area. In addition, Bitdefender automatically sends a weekly report with the security status and improvement tips, provided that the user is logged in. It is possible to password-protect the entire application and manage the automatic update frequency. Performance results A collection of 8,502 virus samples was submitted to the test, in order to verify Bitdefender's threat detection ratio. The test machine was an Intel Core i5-3470 @CPU 3.20GHz with 12GB RAM and 500GB Seagate Barracuda ST500DM002 7200RPM, running Windows 8.1 Pro. Default settings were applied. The collection did not include zero-day threats.The real-time guard was excellent! As soon as we triggered the extraction procedure of the 8,502 virus samples from the password-protected archive, Bitdefender immediately picked up on it and started eliminating files while remaining completely silent (no kind of notifications were shown). In the end, it left behind only 225 files. In the next step, we proceeded with a contextual scan to find out whether the tool was capable of detecting and removing more files, and we were right. It detected and eliminated 207 extra files, leaving behind only 30 items. Overall, Bitdefender had a success rate of 99.6%. In order to evaluate the app's scan speed, we ran a system scan (the primary drive had 156GB occupied space). Default settings were applied. Bitdefender finished the scan job in roughly 1 hour and 36 minutes. No false positives were spotted in these tests. CPU and RAM consumption was minimal. The tool was completely stealthy. The Good The redesigned interface definitely looks cleaner than the old one. Bitdefender's firewall has been simplified to allow less experienced users to configure it. The new profiles for work, games and movies have handy customization settings. The real-time guard is highly responsive and does an excellent job. Virus detection ratio was outstanding. Scan jobs were fast, while CPU and RAM usage was low. The Bad Although the interface is pretty attractive overall, some windows blend together depending on the order in which they were accessed. The duplicate finder takes a really long time to sort files into groups after finishing a scan job. The app sometimes becomes unresponsive when attempting to stop or cancel scan jobs. The Truth The new toolbox with PC tuneup features was not really necessary for an antivirus utility, since other apps which specialize in this category offer more advanced settings. Nevertheless, they are welcomed to quickly resolve common issues, in addition to the new profiles with optimized settings for working, gaming and watching movies. Built to last, Bitdefender continues to dominate the anti-malware solutions community. Since this is a brand new edition, professional tests have not been carried out yet (e.g. AV Comparatives, Virus Bulletin), but we're certain that Bitdefender Internet Security 2015 will continue to impress as far as real-time responsiveness, virus detection ratio, scan speed and resources consumption are concerned. Sursa: Bitdefender Internet Security Review

Isolated Heap for Internet Explorer Helps Mitigate UAF Exploits by Jack Tang (Threats Analyst) In the recent Microsoft security bulletin for Internet Explorer, we found an interesting improvement for mitigating UAF (User After Free) vulnerability exploits. The improvement, which we will name as “isolated heap”, is designed to prepare an isolated heap for many objects which often suffers from UAF vulnerabilities. Let’s use Internet Explorer 11 as an example. Before it was patched, the function CHeadElement::CreateElement allocates memory space from the heap. The code is as follows: Figure 1. The function CHeadElement::CreateElement From Figure 1, we can see the memory space is allocated from the heap g_hProcessHeap, which is the IE default heap. In other words, all these IE objects share the same heap. After the patch, in the sample location, the code was changed to the following: Figures 2 and 3. The function CHeadElement::CreateElement after the patch From Figures 2 and 3, we can see that Internet Explorer now allocates memory space from the heap g_hIsolatedHeap. In other words, these class objects which use the isolated heap do not share the same heap with IE’s other objects. How can an isolated heap mitigate UAF vulnerability exploits? The first routine of UAF vulnerability exploits is to use controlled objects to occupy the memory space which is owned by the UAF object. Some recent Internet Explorer zero-day vulnerabilities such as CVE-2014-0322 and CVE-2014-1776 used this technique. We can summarize the technique of occupying space in the following steps: Use String or Array to make a buffer which can be controlled by attacker. For example: “var d=b.substring(0,(0×340-2)/2);” Create an IE element object. For example: “g_arr[a]=document.createElement(‘div’)” Trigger vulnerability to free the target object. Set the attribute of the objects which is created by step 2 for many times with the String which is created in step 1. For example: for(a=0;a<arrLen;++a) { g_arr[a].className=d.substring(0,d.length); } In step 4, IE will allocate memory space in the heap g_hProcessHeap. In the example for step 4, we can see the following part of the call stack: Figure 4. The function CAttrArray::Set() calling the function RtlAllocateHeap() In figure 4 we see CAttrArray::Set() calling the function RtlAllocateHeap(). The call stack is done with the following code: Figure 5. It uses RtlAllocateHeap with heap “g_hProcessHeap” and then copies the String ‘s data to this buffer. Before the latest patch, if the RtlAllocateHeap has the correct size, the probability that an attacker-controlled buffer could occupy the freed object’s memory space is high. But after the latest patch, the freed object is allocated in heap g_hIsolatedHeap, so there is no probability that the freed object memory space is occupied by the attacker-controlled buffer. The solution is a good way to mitigate UAF vulnerability exploits. From the patch‘s code,the heap g_hIsolatedHeap is used by HTML and SVG DOM Elements (CXXXElement) and supporting elements such as CTreeNode, CMarkup, CAttribute and so on. These objects have a high probability of having the UAF vulnerability, so it is important that they are secured through the isolated heap. Can the isolated heap solution mitigate UAF vulnerabilities completely? No solution is perfect. The improvement implemented by Microsoft raises the difficulty in creating an exploit, but it does not eliminate the vulnerability completely. There are two theoretical ways to bypass this protection: If attackers can find an object which meets the following three criteria instead of String: Allocated with the isolated heap. Correct size for the UAF object. Easily control the content of the object. What is not clear is if attackers can find a reasonable way to perform the above attack. Many objects are still using the process heap, not the isolated heap. If these objects encounter UAF vulnerability, the isolated heap solution doesn’t work. However, Microsoft can easily add objects to use the isolated heap if this becomes a problem down the road. We are glad that Microsoft is continuing to improve the security of Internet Explorer and mitigating the abuse of vulnerabilities. While the isolated heap is not a perfect solution, it represents a significant improvement that will help mitigate attacks of this type moving forward. Sursa: Isolated Heap for Internet Explorer Helps Mitigate Exploit | Security Intelligence Blog | Trend Micro

[h=3]Destroying ROP gadgets with Inline code[/h]Prerequisite Reading: Previous ROP (Return Oriented Programming) article Traditionally in computer science, software developers using higher level languages and abstractions should not need to think about how the lower levels of the system works. For example, when writing a network application, one should ideally not need to worry about how the sequence numbers of the TCP protocol works. Two possible exceptions to this rule could be for security and performance. For security specifically, learning about instruction sequences emitted by compilers might help to avoid writing higher level (C/C++) code that could be used in ROP exploits. Normal non-inline functions have a binary code layout where multiple callers execute x86 "call" instructions to redirect execution to the address of the single instance of the non-inline function code in memory. However, an inline function in C/C++ is function whose emitted code is inserted by the compiler directly into the possibly multiple call sites of that function throughout the program. An example follows: #include <Windows.h>LPVOID notInlined() { return VirtualAlloc(NULL, 4096, MEM_COMMIT, PAGE_EXECUTE_READWRITE); } __forceinline LPVOID inlined() { return VirtualAlloc(NULL, 4096, MEM_COMMIT, PAGE_EXECUTE_READWRITE); } void main() { notInlined();//a call instruction will be placed here inlined();//the function’s code itself will be placed here //some additional code here } VirtualAlloc is a function that can be abused by ROP exploits to allocate Readable, Writeable and Executable memory. As shown in the C code above, the functions notInlined and inlined both call VirtualAlloc. Except for the __forceinline keyword in inlined, both notInlined and inlined are exactly identical in the C code. However, the binary code layout of each function looks very different. notInlined disassembly: push ebp mov ebp, esp push 40h push 1000h push 1000h push 0 call dword ptr[inlined!_imp__VirtualAlloc(0121b000)] pop ebp ret main function disassembly: push ebp mov ebp, esp call inlined!ILT + 0(_notInlined)(011f1005) push 40h //this push 1000h //is push 1000h //code push 0 //of call dword ptr[inlined!_imp__VirtualAlloc(0121b000)] //inlined //some additional code here xor eax, eax pop ebp ret In the above disassembly, the code for notInlined is in its own function as we would expect, and can be executed and returned from, by an x86 “call” instruction from anywhere in the program. However, the disassembly for the inlined function (in red text) is placed inline in the main function (the call site). The significance of the differing in-binary layouts of the two functions is that notInlined contains a very useful ROP gadget that ROP exploits can use, whereas the code for inlined does not contain the same ROP gadget. This difference is due to the fact that there is no x86 “ret” instruction in the code of inlined. If a ROP chain tried to execute inlined, if would be much more difficult to return from inlined back to the ROP chain. In summary, the inline keyword can be used as an architecture, compiler, and OS portable way to destroy ROP gadgets in code where often abused APIs are called. The cost of inlining code however, is that it increases the code size in the binary. The reason for a larger code size in the example above is that if inlined was called from a large number of places in the program, the full code of inlined would be inserted in the binary that many times. As with all exploit mitigation schemes, there still might be ways to bypass this technique such as using jmp instructions rather than ret instructions to chain together gadgets. References: inline, __inline, __forceinline Posted by Neil Sikka Sursa: InfoSec Research: Destroying ROP gadgets with Inline code

HTTP Response Splitting, Web Cache Poisoning Attacks, and Related Topics White Paper Amit Klein, Director of Security and Research Sanctum, Inc. March, 2004 Abstract ....................................................................................................................3 Introduction to HTTP Response Splitting ..............................................................3 Use Cases for Web Cache Poisoning .......................................................................5 The Basic Technique of HTTP Response Splitting .................................................6 Practical Considerations – The Web Server Mount Point ........................................8 Determining Where The second Response Message Starts ....................................12 Cache Poisoning– Practical Considerations..........................................................13 Cache Poisoning with Apache/2.0 – Practical Considerations................................14 Cache poisoning with NetCache 5.2 – Practical considerations .............................15 Cache Poisoning with Squid 2.4 - Practical Considerations ...................................17 Cache Poisoning and Cross Site Scripting with Internet Explorer 6.0 SP1 - Practical Considerations ......................................................................................................19 Other Indirect Web Cache Poisoning Attacks ......................................................21 Cross User Attacks – The Theory..........................................................................22 Hijacking a Page (HTTP response) with User Sensitive Information..................23 Other Practical Aspects .........................................................................................24 HTTP Response Splitting Vulnerability in the Wild ............................................25 Research Byproducts .............................................................................................25 Recommendations ..................................................................................................28 Conclusions.............................................................................................................29 Related work ..........................................................................................................30 References...............................................................................................................30 Appendix - Lab Environment................................................................................31 Download: http://dl.packetstormsecurity.net/papers/general/whitepaper_httpresponse.pdf

Attacks before system startup By Vyacheslav Rusakov, Sergey Golovanov on June 16, 2014. 5:34 pm A major objective pursued by malware writers when developing malicious code is to make it start as early as possible, enabling it to make key modifications to the operating system's code and system drivers, such as installing hooks, before the antivirus product's components initialize. As a result, malware and anti-malware products play cat and mouse of sorts, since they operate at the same level: the operating system, system drivers and rootkits all operate in kernel mode. Bootkits currently represent the most advanced technology available to cybercriminals. It enables malicious code to start before the operating system loads. The technology is implemented in numerous malicious programs. We have written about bootkits (such as XPAJ and TDSS (TDL4)) several times. The latest bootkit-related publication so far describes scenarios of targeted attacks based on the bootkit technology as implemented in The Mask campaign. However, such papers are not released often and some experts may get the impression that bootkits, like file viruses, are 'dead', that Trusted Boot has done its job and that the threat is no longer relevant. Nevertheless, bootkits do exist; they are in demand on the black market and are extensively used by cybercriminals for purposes which include conducting targeted attacks. Fragment of TDSS loader code in MBR Statistics First, let's have a look at KSN statistics. The table below represents a ranking of malicious programs that we detect as Rootkit.Boot.*, for the period from May 19, 2013 to May 19, 2014. [TABLE=class: pd48, width: 80%] [TR] [TD]Family[/TD] [TD=class: c]Users[/TD] [TD=class: c]Notifications[/TD] [/TR] [TR] [TD]Rootkit.Boot.Cidox[/TD] [TD=class: c]45797[/TD] [TD=class: c]60787[/TD] [/TR] [TR] [TD]Rootkit.Boot.Pihar[/TD] [TD=class: c]25490[/TD] [TD=class: c]75320[/TD] [/TR] [TR] [TD]Rootkit.Boot.Harbinger[/TD] [TD=class: c]19856[/TD] [TD=class: c]34427[/TD] [/TR] [TR] [TD]Rootkit.Boot.Sinowal[/TD] [TD=class: c]18762[/TD] [TD=class: c]420549[/TD] [/TR] [TR] [TD]Rootkit.Boot.SST[/TD] [TD=class: c]8590[/TD] [TD=class: c]73079[/TD] [/TR] [TR] [TD]Rootkit.Boot.Tdss[/TD] [TD=class: c]5388[/TD] [TD=class: c]19071[/TD] [/TR] [TR] [TD]Rootkit.Boot.Backboot[/TD] [TD=class: c]4344[/TD] [TD=class: c]9148[/TD] [/TR] [TR] [TD]Rootkit.Boot.Wistler[/TD] [TD=class: c]4230[/TD] [TD=class: c]13014[/TD] [/TR] [TR] [TD]Rootkit.Boot.Qvod[/TD] [TD=class: c]1189[/TD] [TD=class: c]1727[/TD] [/TR] [TR] [TD]Rootkit.Boot.Xpaj[/TD] [TD=class: c]690[/TD] [TD=class: c]2483[/TD] [/TR] [TR] [TD]Rootkit.Boot.Mybios[/TD] [TD=class: c]442[/TD] [TD=class: c]5073[/TD] [/TR] [TR] [TD]Rootkit.Boot.Plite[/TD] [TD=class: c]422[/TD] [TD=class: c]648[/TD] [/TR] [TR] [TD]Rootkit.Boot.Trup[/TD] [TD=class: c]300[/TD] [TD=class: c]7395[/TD] [/TR] [TR] [TD]Rootkit.Boot.Prothean[/TD] [TD=class: c]217[/TD] [TD=class: c]1407[/TD] [/TR] [TR] [TD]Rootkit.Boot.Phanta[/TD] [TD=class: c]167[/TD] [TD=class: c]5475[/TD] [/TR] [TR] [TD]Rootkit.Boot.GoodKit[/TD] [TD=class: c]120[/TD] [TD=class: c]131[/TD] [/TR] [TR] [TD]Rootkit.Boot.Smitnyl[/TD] [TD=class: c]100[/TD] [TD=class: c]3934[/TD] [/TR] [TR] [TD]Rootkit.Boot.Stoned[/TD] [TD=class: c]69[/TD] [TD=class: c]96[/TD] [/TR] [TR] [TD]Rootkit.Boot.Geth[/TD] [TD=class: c]60[/TD] [TD=class: c]166[/TD] [/TR] [TR] [TD]Rootkit.Boot.Nimnul[/TD] [TD=class: c]53[/TD] [TD=class: c]84[/TD] [/TR] [TR] [TD]Rootkit.Boot.Niwa[/TD] [TD=class: c]37[/TD] [TD=class: c]121[/TD] [/TR] [TR] [TD]Rootkit.Boot.Fisp[/TD] [TD=class: c]35[/TD] [TD=class: c]344[/TD] [/TR] [TR] [TD]Rootkit.Boot.CPD[/TD] [TD=class: c]25[/TD] [TD=class: c]39[/TD] [/TR] [TR] [TD]Rootkit.Boot.Lapka[/TD] [TD=class: c]19[/TD] [TD=class: c]21[/TD] [/TR] [TR] [TD]Rootkit.Boot.Yurn[/TD] [TD=class: c]8[/TD] [TD=class: c]18[/TD] [/TR] [TR] [TD]Rootkit.Boot.Aeon[/TD] [TD=class: c]6[/TD] [TD=class: c]6[/TD] [/TR] [TR] [TD]Rootkit.Boot.Mebusta[/TD] [TD=class: c]5[/TD] [TD=class: c]5[/TD] [/TR] [TR] [TD]Rootkit.Boot.Khnorr[/TD] [TD=class: c]4[/TD] [TD=class: c]4[/TD] [/TR] [TR] [TD]Rootkit.Boot.Sawlam[/TD] [TD=class: c]4[/TD] [TD=class: c]7[/TD] [/TR] [TR] [TD]Rootkit.Boot.Xkit[/TD] [TD=class: c]4[/TD] [TD=class: c]20[/TD] [/TR] [TR] [TD]Rootkit.Boot.Clones[/TD] [TD=class: c]1[/TD] [TD=class: c]1[/TD] [/TR] [TR] [TD]Rootkit.Boot.Finfish[/TD] [TD=class: c]1[/TD] [TD=class: c]1[/TD] [/TR] [TR] [TD]Total[/TD] [TD=class: c]136435[/TD] [TD=class: c]734601[/TD] [/TR] [/TABLE] Most bootkits are proactively detected using behavior-based technology as early as at the stage of their installation in the system. Alternatively, they can be detected the first time the antivirus product performs an automatic scan after system startup, resulting in the active infection removal procedure being launched. Note that the statistics shown above include only infected Master Boot Record detections. The figures also include data received from previously infected machines on which our antivirus solution was installed after the machines were infected. It can be seen in the table above that derivatives of TDSS - Pihar and SST - are among the TOP 5 bootkits detected. The Harbinger bootkit, which 'covers' adware, is in the third position and Sinowal is in fourth place in the ranking. First place is occupied, with a considerable lead, by Rootkit.Boot.Cidox. Since Cidox has played a special role in bootkit evolution, we will discuss its story in greater detail. Cidox: publicly available code Cidox is offered as a supplement to other malicious programs and is used to protect the malware with which it is distributed. This means that the bootkit is not used to build its own botnet TDSS-style. The initial versions of the malware were included in Kaspersky Lab antivirus databases three years ago, on June 28, 2011. Back then, Cidox was a breakthrough in malicious technology, because it was the first to infect VBR rather than MBR. Cidox was used to protect the banking Trojan Carberp, among other malicious programs. When the Carberp source code was published, the bootkit's source code was 'leaked' as well. As a result, Cidox re-enacted the story of the infamous ZeuS (Zbot) Trojan. While the 'leak' of ZeuS source code made it much easier to steal money from online banking systems, the publication of Cidox source code has meant that any more or less experienced programmer can have a go at writing malware which operates at the lowest level, before operating system startup. Fragment of Cidox source code Cidox is currently used to load and protect a variety of malware, including crimeware, blockers and malware designed to steal money in online banking systems. Targeted attacks The Mask campaign mentioned above was not a unique case of bootkits being used in targeted attacks. A while ago, we wrote about HackingTeam, a company whose software (including bootkits) is used when conducting police operations in various countries around the globe. Another company, FinFisher, offers similar services, while the software developed by it also includes a bootkit - Rootkit.Boot.Finfish, which happens to be in last place on our ranking. List of products and services from FinFisher's official website An analysis of products offered by FinFisher was presented in a Kaspersky Lab paper prepared for a Virus Bulletin conference. The presentation can be found on the VB website. BIOS. A quest for new starting points The never-ending struggle between antivirus solutions and malicious code is leading both the former and the latter to the next phase in their evolution. Malware writers have to search for new starting points, with the BIOS becoming one of these. However, things have hardly moved past test research, because mass modification of the BIOS is an 'inconvenient' operation for malware writers, which requires considerable effort to perform and can therefore be used only in highly targeted attacks. What dreams may come The classical BIOS system is now essentially a relict that is difficult to use and has numerous limitations. This was why a completely new unified modular interface, UEFI, was developed by the UEFI Forum consortium based on specifications initially provided by Intel. What UEFI offers: Support for modern equipment. Modular architecture. EFI Byte Code - architecture and drivers that are independent of the CPU type (x86, x86-64, ARM/ARMv8). Various extensions for UEFI, which are loaded from different media, including portable devices. Development using a high-level programming language (a dialect of C). Secure Boot. Network booting. We also recommend reading about the 10 most common misconceptions about UEFI. The following operating systems support UEFI: Linux using elilo or a special version of the GRUB boot loader. FreeBSD. Apple Mac OS X for Intel-compatible systems (v10.4 and v10.5 provide partial support, while v10.8 provides complete support). Microsoft Windows, starting from Windows Server 2008 and Windows Vista SP1 x86-64. Microsoft Windows 8 supports UEFI, including 32 bit UEFI, as well as secure boot. In short, what does UEFI offer? A simple, easy to understand, well-documented, unified and convenient method of development without resorting to 16-bit assembly programming. From the viewpoint of an anti-malware solution, UEFI is a very good place to implement something like a rescue disk. First, the rescue disk's code will run before the operating system and boot loader start; second, UEFI offers easy hard drive access, as well as more or less easy network access; third, a simple and easy-to-understand GUI can be created. Just what the doctor ordered when one has to deal with sophisticated and actively resisting threats such as bootkits. From the viewpoint of malicious code developers, all of the above is also advantageous for a bootkit, enabling it to provide more reliable protection for malware. At least until firmware developers take care to implement proper protection. However, before moving on to protection functionality, we would like to address one important issue. Equipment manufacturers develop their firmware themselves and make their own decisions regarding support for optional features offered by the UEFI specification. Such features include, first and foremost, protecting firmware in SPI Flash from modification and secure boot. In the case of UEFI, we have the classical problem of Convenience vs. Security. Threats and protections mechanisms It comes as no surprise that, as UEFI became universally implemented, it attracted the interest of independent researchers as a potential attack vector (one, two, three). The list of possible penetration points is quite extensive and includes compromising (injecting, replacing or infecting) OS boot loaders and EFI, compromising UEFI drivers, directly accessing SPI Flash from the operating system and many others. In the case of booting in UEFI+Legacy (CSM) mode, old methods of infecting the system used by bootkit developers remain effective. It is also quite obvious that if the pre-boot execution environment is compromised, all the Windows security mechanisms, such as Patch Guard, driver signature verification etc., are rendered useless. The UEFI specification version 2.2 included a new secure boot protocol, which was to provide a secure pre-boot execution environment, as well as protection against malicious code being executed from potentially vulnerable points. The secure boot protocol defines the process used to verify the modules being loaded, such as drivers, the OS boot loader and applications. These modules should be signed with a special key and the digital signature should be verified before loading a module. The keys used to verify modules should be stored in a dedicated database protected against penetration, such as a TPM. Keys can be added or modified using other keys, which provide a secure method of modifying the database itself. Based on the above, implementation of the following security mechanisms by firmware and operating system developers can be regarded as optimal from the security viewpoint: Protecting SPI Flash against malicious modification. Disabling support for upgrading firmware from the operating system. Blocking access to critical UEFI sections, including most environment variables. Completely abandoning the use of CSM. Protecting the system volume containing UEFI drivers, boot loader and applications from malicious modification. Operating system and firmware developers should implement and enable Secure Boot (as well as the Trusted Boot mechanism implemented in Windows OS). Protecting the key storage from modification. Protecting the mechanism used to update the database in which keys are stored from spoofing and other types of attacks. Implementing protection against "Evil Maid" attacks, which involve physical access to the computer. Using the expertise accumulated by leading anti-malware companies and implementing anti-malware technologies at the firmware level. However, it should be kept in mind that as more advanced protection mechanisms are implemented, cybercriminals will come up with more advanced attacks against UEFI. The methods currently used are based on replacing the UEFI boot loader for the Windows 8 operating system. During its initialization, the malicious OS loader loads a replaced loader into memory, disables Patch Guard security mechanisms and driver signature verification using one method or another, sets the necessary hooks and passes control to the original loader code. In the case of Mac OS using full-disk encryption, an original approach is used, which is based on implementing a simple UEFI keylogger to obtain the secret passphrase entered by the user on the keyboard to decrypt contents of the hard drive at system startup. In all other respects, the method based on replacing or infecting the system boot loader is applicable in this case, as well. Conclusion Bootkits have evolved from Proof-of-Concept development to mass distribution and have now effectively become open-source software. Launching malicious code from the Master Boot Record (MBR) or the Volume Boot Record (VBR) enables cybercriminals to control all the stages of OS startup. This type of infection has essentially become standard for malware writers. Its implementation is based on proven, well-researched technologies. Importantly, these technologies are available on a variety of resources in the form of source code. In the future, this may lead to a significant increase in the amount of malware based on these technologies, with only minor changes in individual programs' logic of operation. We expect to see new modifications of TDSS and Cridex, which are already familiar to cybercriminals. We are also concerned that such malware might be used in other types of attacks perpetrated by cybercriminals, e.g., in systems which use Default Deny technologies. Crucially, the state-of-the-art anti-malware technologies implemented in our products are successful in combating such infections. Since it is hard to predict now what specific methods of masking, blocking or resisting anti-malware products will be invented by cybercriminals in the near future, implementing anti-malware technologies at the firmware level, in combination with the protection mechanisms described above, will enable security solutions to neutralize rootkits and bootkits before malicious code is able to take control. In addition, incorporating an anti-malware module in UEFI will simplify the process of removing infection and the development of new methods for detecting newly-developed bootkits that use new, advanced masking techniques, as well as rootkits which interfere with the operation of the system or the anti-malware solution. P.S. Special thanks from the authors to Vasily Berdnikov for his help in researching material for this paper. Sursa: https://securelist.com/blog/research/63725/attacks-before-system-startup/

[h=1]GKsu and VirtualBox Root Command Execution by Filename (CVE-2014-2943)[/h]Posted by Brandon Perry in Metasploit on Jul 7, 2014 11:59:03 AM [h=2]Poisoning VirtualBox via Crafted Filenames[/h]When I began researching this, I believed the vulnerability laid within Virtualbox, but I realized this was not true after a bit. The vulnerability being hit is actually within gksu itself. In fact, virtual box did everything right (sort of). I do take advantage of a weakness in the way they validate their extension packs, but the reason the vulnerability results in a root shell is because the vulnerability is hit after gksu escalates privs to root. You *must* install the extension pack via the helper app, so that means double clicking or opening from the graphical UI. This also works when reinstalling the same (but maliciously-renamed) extension pack. Incidentally, this bug was already reported in the maintainer's bug tracker, but it seems unclear of the true, dangerous scope of the bug, when it comes to things like VirtualBox, various package manageres, et cetera. Articol: https://community.rapid7.com/community/metasploit/blog/2014/07/07/virtualbox-filename-command-execution-via-gksu

[h=3]Writing Slack Space on Windows[/h]By Diego Urquiza. I’m a Foundstone intern in NYC office and for a project I decided to write a tool to remove file slack space. In this post I’ll introduce the methods I took in writing the tool then provide the tool itself. Hope you enjoy it! [h=1]About[/h] File Slack Space is the amount of unused space at the end of a file’s last cluster. File systems organize file data through an allocation unit called clusters. Clusters are composed in sequence sectors on a disk that contains a set amount of bytes. A disk that has 512 byte sectors and 8 sectors per cluster would have a total of 4 kilobytes (4096 bytes). Since the file system organizes files into clusters, there ends up being unused space at the end of clusters. From a security standpoint, unused space can contain previous data from a deleted file that can contain valuable information. When a user chooses to delete a file, the file system will delete the pointer to the location of the file data on disk. This enables the operating system to read the data space as available space so when a new file is created, the file system will write over the old data that the user thought he or she deleted. My tool aims to write over the file slack space multiple times with meaningless data so that any prior data cannot be retrieved. [h=1]Download[/h] Download my tool here: https://github.com/OpenSecurityResearch/slacker [h=1]Approaching The Problem[/h] When I began this project I saw two possible approaches: Find the location of every file’s last cluster, move the pointer to the end of the file data, and write zero's until the end of the cluster Resize the file, read/write the data, then trim it back down [h=2]Moving the File Pointer[/h] This seemed like a feasible approach since the unused files were inconsequential. However, after tackling it for about a week, I found out everything can and will go wrong. Depending on what type of file system was in use, each disk’s data would be organized differently. Moreover, if the file data was too small it would go into the master file table (in the case of NTFS file system) and if the data was larger than a cluster, it would be organized non-contiguously on the logical disk. Using the Windows API functions can become frustrating to use since you need to map the file virtual cluster to the logical cluster while finding the volume offset. Therefore, writing meaningless data to the disc can become tragic if the byte offset from the beginning of disc is wrong ( the next cluster over can be a system file ). Here’s a code snip for this approach: /**********Find the last Cluster ***********************************/DWORD error = ERROR_MORE_DATA; returns = DeviceIoControl(hfile.hanFile, FSCTL_GET_RETRIEVAL_POINTERS, &startVcn, sizeof(startVcn), &output, sizeof(output), &bytesReturned, NULL); DWORD lastExtentN = retrievalBuffer->ExtentCount - 1; LONGLONG lastExtent = retrievalBuffer->Extents[lastExtentN].Lcn.QuadPart; LONGLONG lengthOfExtent = retrievalBuffer->Extents[lastExtentN].NextVcn.QuadPart - retrievalBuffer->Extents[lastExtentN - 1].NextVcn.QuadPart; while (error == ERROR_MORE_DATA){ error = GetLastError(); switch (error){ case ERROR_HANDLE_EOF: //file sizes 0-1kb will return EOF error cout << "ERROR_HANDLE_EOF" << endl; returns = true; break; case ERROR_MORE_DATA: cout << "ERROR_MORE_DATA" << endl; startVcn.StartingVcn = retrievalBuffer->Extents[0].NextVcn; case NO_ERROR: cout << "NO_ERROR, here is some info: " << endl; cout << "This is the lcnextent : " << retrievalBuffer->Extents[lastExtentN].Lcn.QuadPart << endl; cout << "This is the nextvnc: " << retrievalBuffer->Extents[lastExtentN].NextVcn.QuadPart << endl; cout << "This is the Extent count: " << retrievalBuffer->ExtentCount << endl; cout << "This is the Starting Vnc: " << retrievalBuffer->StartingVcn.QuadPart << endl; cout << "The length of the cluster is: " << lengthOfExtent << endl; cout << "The last cluster is: " << lastExtent + lengthOfExtent - 1 << endl << endl << endl; returns = true; break; default: cout << "Error in the code or input error" << endl; break; } } [h=2]Resizing Tricks[/h] The second approach was to resize the file and trim it back down. Resizing the file was the right (safe) direction to go. You can easily iterate through all the files on a volume and set file handlers for each one. Then, with each file handle you can calculate the file slack space based on the system information (bytes per sector and sectors per cluster). Finally, move the file pointer to the beginning of the slack space, save the pointer location, write zero’s to the end of the cluster, trim the file back down to the saved pointer location, and do it again. It is important to write meaningless data multiple times because even after one write over, the old data can still be retrieved. This method unfortunately cannot be used on files in use. Here’s a code snip from this approach: /******************* Loop to write random 0s and 1s to the end of the file(4 times) **********/for( int a = 2; a<6;a++){ //Alternate 0s and 1s int b,c; b = 2; c = a%b; char * wfileBuff = new char[info.slackSpace]; memset (wfileBuff,c,info.slackSpace); returnz = SetFilePointer(info.hanFile, info.fileSize.QuadPart,NULL,FILE_BEGIN); if(returnz ==0){ cout<<"Error with SetFilePointer"<<endl; return 0; } /**** Lock file, Write data, Unlock file *******/ if(LockFile(info.hanFile, returnz, 0, info.slackSpace, 0) != 0) returnz =WriteFile(info.hanFile, wfileBuff, info.slackSpace, &dwBytesWritten, NULL); if(returnz ==0){ cout<<"There is an error with WriteFile"<<endl; cout<<"Error: "<<GetLastError()<<endl; return 0; } if(UnlockFile(info.hanFile, returnz, 0, info.slackSpace, 0) != 0); /***********************************************/ //cout<<dwBytesWritten<<endl<<endl; system("pause"); //Cut out the extra data written from the file if(!SetEndOfFile(info.tempHan)){ cout<<"Error seting the end of the file"<<endl; return 0; } Even though the second approach has its drawbacks, it is safer and can work on different file systems. The focus for the next sequence will be optimization of speed and the addition of extra features. Some of the features would include finding the file offset of a file from the disc(can be useful for finding bad sectors), displaying volume information and file information such as size available. Working on this project was an interesting experience that has helped me grow from a computer forensic perspective and I can’t wait to see what I can do next. Posted by OpenSecurity Research at 3:15 PM Sursa: Open Security Research: Writing Slack Space on Windows

CryptoWall Encrypted File Recovery and Analysis Monday, 7. July 2014 A couple of weeks ago I got a call from a client that one of their employees had clicked on an attachment named “electronic_fund_transfer.zip” in a spam email. Naturally, the employee opened the PDF from within the zip file and then clicked “Run” to launch the executable inside. In a typical organization, the main concern in such a situation would be what data was exfiltrated from the environment, not the data that was lost due to not having proper backups. You could just wipe the system and restore any lost data from backup, and spend your time figuring out what the malware accomplished while on the system. Well, this client didn’t have working backups in place and the user had also mounted file server shares to his laptop. So, not only did his data get encrypted, some of the data on the file server did as well, with no backups for months of either system. When the client first contacted me they called it “CryptoDefense” which we can indeed decrypt without issue because there is plenty of data out there on how to do that. Naturally, once we arrived on site, we quickly found out that this was the much more advanced CryptoWall malware that doesn’t store the private key needed to decrypt the files on the local system. At that point I was between a rock and a hard place because we had initially told them it was possible to recover the encrypted data. However, the majority of resources on the Internet indicate that it’s not possible to recover data at all when CryptoWall is installed as opposed to CryptoDefense. Most file recovery methods suggest using VSS copies to recover the data or backups, otherwise you’re simply out of luck. In these cases, I do not consider paying the data terrorists as an option. So, as part of our basic Triage process, we obtained memory and disk images. These helped a lot in understanding how this malware works and achieving the ultimate goal of recovering the data. To work with the malware for this blog post I created a virtual machine, fresh to launch this malware on, to run a few scans and tests. My first goal was to determine how this malware was encrypting the data and in which method it was deleting the original files. I searched the strings file created from the volatility strings plugin. I used IDA pro on the “vofse.exe” file that does the encryption part (it’s the second file that is downloaded after sicac.exe). The ransomware was simply using the DeleteFile Function to remove the files after making a copying from the original file. This screenshot is where the ransomware finds the file and creates a copy of it. Here is a screenshot with the DeleteFile function highlighted. So, I made a disk image before installing the malware and another after letting the malware run to “encrypt” the files. First, to get a list of the files it “encrypted” I printed out the list it makes in the registry. To find the registry key that the malware created, look in “HKCU\Software\<unique ID>\ CRYPLIST\” as it contains a list of the encrypted files. root@BT:~/volatility-master# python vol.py -f win7.vmem –profile=Win7SP1x64 printkey -K “Software\1C1AA48085BD197637A78463CBBE8BC2\CRYPTLIST” Legend: (S) = Stable (V) = Volatile —————————- Registry: \??\C:\Users\malware\ntuser.dat Key name: CRYPTLIST (S) Last updated: 2014-06-09 12:45:57 UTC+0000 Subkeys: Snip… Values: REG_DWORD C:\Users\malware\Documents\00698_snowmountains_1920x1200.jpg : (S) 2054688515 2054688515 Snip… REG_DWORD C:\Users\malware\Documents\400 – Linux Software RAID Rebuild.doc : (S) 2054688515 REG_DWORD C:\Users\malware\Documents\Cisco_2014_ASR.pdf : (S) 2054688515 REG_DWORD C:\Users\malware\Documents\GrrCON-Challenge.docx : (S) 2054688515 REG_DWORD C:\Users\malware\Documents\Microsoft SQL Server AlwaysOn Solutions Guide for High Availability and Disaster Recovery.docx : (S) 2054688515 REG_DWORD C:\Users\malware\Documents\Sophos_ZeroAccess_Botnet.pdf : (S) 2054688515 REG_DWORD C:\Users\malware\Documents\YARA User’s Manual 1.6.pdf : (S) 2054688515 REG_DWORD C:\Users\malware\Downloads\00698_snowmountains_1920x1200.jpg : (S) 2054688515 Snip… I then opened “GrrCON-Challenge.docx” (one of the encrypted documents) in a hex editor, copied the raw hex values, and searched through both of my disk images, before the malware, and after the malware. While the file itself was removed according to the malware it was still in the same spot on disk at offset 004c000 in both disk images. Here is the file in the “malwarevm-before.001”: Here is the “GrrCON-Challenge.docx” document at the same offset 004c000 on the “aftermalwarevm-cryptowall.001” I also opened the encrypted version of “GrrCON-Challenge.docx” and then searched the “aftermalwarevm-cryptowall.001” to find where it was located on disk to confirm they create a new file compared to the old disk image. I will note one very interesting fact: while I have two versions of the “GrrCON-Challenge.docx” file, the malware only created one encrypted version. Now that I have confirmed that the malware isn’t fully deleting the files, I want to test it out on some more files to see how much data I can recover. I ran one of my favorite file recovery tools called R-Studio (Yes, I like it because it’s fast and saves me some time from the more manual solutions available). R-Studio is a very simple program. Basically, all you have to do is mount a drive and scan it, and then choose which file types you want to look for. I just used the default configuration on the “aftermalwarevm-cryptowall.001”. I selected the Microsoft Word 2007 XML Document (.docx) and noticed I had two sets of files. The ones with file names are the encrypted version by CryptoWall and the ones without names are the files that were deleted recoverable from slack space. Based on the file size and hex values I know “70.docx” is my “GrrCON-Challenge.docx” file, so I clicked on the view process before recovering the file to ensure it’s the proper file from the hex view and not the encrypted file. I was indeed correct because the picture above lists the file header as “PK” which is the proper file header in the docx file. Listed below is a screenshot of the encrypted file and its header so we know if we are looking at an encrypted file or not. In my test example all encrypted files start with the header “CE FE” in hex, which will be different on each system that is hit will CryptoWall. So I recovered all the files and ran a sha256 hash verification to ensure all my recover files matched the original files. Recovered File Hash Check Original File Hash Check I only tested with a few files in the following formats, docx, doc, pdf, and jpg. As a disclaimer with all file recovery some files may not be recoverable if the slack space was overwritten. In each separate case, file recovery will depend on how many files were encrypted, and how much free space the drive had before it had to start overwriting old slack space for new files. If anyone wants to look at the attachment that launched the attack, here it is, along with the malwr.com automated analysis, which is somewhat helpful. *Note: you have to sign up to download the file, and use at your own risk. I am not responsible for any damages you cause to yourself. https://malwr.com/analysis/ZmU1MzE0MmU5MmExNDc5YjkxMDQ2ZmI1ZWEyYjM4Nzk/ In my client’s case I was able to recover approximately %95 of the files, however based on their actual need we only searched for the critical documents and nothing that was lost from the user’s personal files. Just because ransomware encrypts the data doesn’t mean it’s lost forever because to actual erase the files would be much more time consuming and resource intensive. It also would be impossible to actually zero out the files on a file server because the user doesn’t have the proper permissions to access the raw drive in that method (*If permissions are properly setup that is, and User quotas are in place). If anyone would like the files used in this blog post, I would be happy to share the full images. I would also be happy to accept comments and questions just send me an email to wyattroersma (at) gmail. If anyone would like to know more about memory forensics I’d recommend pre-ordering this The Art of Memory Forensics The Art of Memory Forensics: Detecting Malware and Threats in Windows, Linux, and Mac Memory: Michael Hale Ligh, Andrew Case, Jamie Levy, AAron Walters: 9781118825099: Amazon.com: Books. Also if anyone needs assistance with Cryptowall or any other piece of malware please visit nvint.com. I’d like to Thank Andrew Case and Michael Hale Ligh for their advise and review of this blog post write up. I’d also like to thank DoctorW0rm a reddit user who found some technical flaws which I have corrected from “CryptoLocker to CryptoDefense” Sursa: » CryptoWall Encrypted File Recovery and Analysis

Disect Android APKs like a Pro - Static code analysis I've started writing this IPython notebook in order to make myself more comfortable with Android and its SDK. Due to some personal interests I thought I could also have a look at the available RE tools and learn more about their pros & cos. In particular I had a closer look at AndroGuard which seems to be good at: Reverse engineering, Malware and goodware analysis of Android applications ... and more (ninja !) I was charmed but its capabilities and the pythonic art of handling with APKs. In the 2nd step I've needed a malware to play it, so I had a look at Contagio Mobile. There I've randomly chosen a malware and got stucked with Fake Banker. There are some technical details about the malware itself gained during automated tests which can be read here. This article will only deal with the static source code analysis of the malware. A 2nd part dedicated to the dynamic analysis is planed as well. Articol complet: Disect Android APKs like a Pro - Static code analysis

From a Username to Full Account Takeover In the past year there have been many major data breach incidents in which usernames, email addresses and sometimes even passwords were compromised. Some of these incidents included big organizations with millions of usernames leaked. According to the 2014 Trustwave Global Security Report, “The volume of data breach investigations increased 54 percent over 2012” and “45 percent of data thefts involved non-payment card data”. In my personal blog I wrote a post describing how I obtained the ability to extract email addresses hosted on Google's email service Gmail, including email addresses belonging to corporates that externalized their email management through Google Apps for Business. After reading my blog post people questioned how important email addresses and usernames really are. “Why is it such a big deal when email addresses or usernames are stolen?” is a question I get asked fairly frequently. This post will attempt to answer that question. Usernames, Emails and Phone Numbers In most applications today, we login by providing two identifiers – a username and a password. The use of an email address or phone number as a username has been adopted by almost every big website out there, and by all of Alexa’s Top 10 sites, including Google, Facebook, Yahoo, Microsoft Live and more. The common usage of email addresses as usernames sometimes leads end users to think that the sign-on for any given site is a "single sign-on" and enter the password for their email account. This results in the re-use of credentials and if that third-party site is hacked, the attacker would have access to not only that account, but the user's e-mail account as well. A username can also be used to contact the user by e-mail or phone, supporting malicious activities such as phishing attacks and spam campaigns. Username leakage is permanent, Password leakage is not "To help ensure customers' trust and security on [e-commerce site], I am asking all users to change their passwords." This quote is taken out of an email I received from a big e-commerce site in May 2014, following a data breach. At some point in time, every computer user is going to be asked to replace their password. Can you imagine getting the following message when usernames have been leaked? "To help ensure customers' trust and security on [e-commerce site], I am asking all users to change their email addresses." How can you change your email address when almost any other website out there identifies you the same way? Let's say your email address has been leaked, are you going to change your Google, Facebook and Windows Live usernames? Username leakage is cross-site As I mentioned earlier, your email address is being used for authentication everywhere. If it has been exposed, it can be used to access your Google account, Facebook account or trying to hack into your smartphone via your Apple Id or your Google Play account name. What damage can be done by stockpiling usernames? Different attack vectors can be used depending on whether the username is also a means of contacting a user (email/phone). The following figure lists ten possible attack vectors (coloring has nothing to do with severity in this case). The ones colored in purple can be launched regardless of the username's structure, while the ones colored in blue are cases in which the username is also an email or a phone number: Attack vectors available to attacker who obtained usernames. Bruteforce and dictionary attacks The log-in process is completed by sending a username and a password to the application. If attackers obtain a username, they can then launch Bruteforce and Dictionary attacks on a given username to try and determine the password: Bruteforce attack – the attacker tries all possible password combinations. Dictionary attack – the attacker uses a large list with thousands of possible passwords that are commonly used as a password. A Bruteforce or Dictionary attack is successful when a username-password combination which results in a successful login is found. This allows for the full takeover of an account. Note that in some cases a "security-lockout" mechanism is implemented, which locks a username from authenticating after a threshold of failed login attempt was reached. Reverse-Bruteforce Attacks Sometimes an attacker just wants to hack as many accounts as possible with the least amount of effort. For such cases, and in case a "security-lockout" mechanism is implemented, reverse-bruteforce attacks might be the chosen attack vector. Assuming a site only allows five failed login attempts before locking out an account, the attacker chooses the four most common passwords which comply with the site's password policy. If we use SpiderLabs’ analysis based on 2,000,000 leaked passwords, such passwords could be: “123456”, “123456789”, “1234” and “password”. Now, for every given password in the above list, we are going to try every username we've obtained. The bigger the list of leaked usernames, the bigger the number of fully hacked accounts will likely be. Denial-of-Service Attacks In this case, if a site only allows five failed login attempts before locking out an account, the attacker chooses five unlikely passwords and tries all of them for every leaked username. The result would be the locking of all accounts potentially rendering a website completely useless. Some websites automatically unlock accounts after a predefined period of time, but the attacker can repeat the attack endlessly to bypass such countermeasures and continuously lock the accounts again. Non-Web Vectors Obtained usernames can be used to attack non-web based systems. This is often the case where the obtained usernames are also used for authentication in a domain network. A discovered username can be used to launch attacks on VPN gateways, FTP services and remote administration interfaces such as SSH and Remote Desktop. Reputation Damage to the Brand Name (Bad Press) This attack vector is fairly self-explanatory. The attacker can just dump all of the leaked information in services such as pastebin.com, and the media would take care of the rest. It’s not so rare to see a story of stolen usernames turn into a headline to the effect of “Company XY hacked, 300,000 accounts compromised!” with no regard to whether or not any accounts were actually fully compromised. The combination of a company’s name with the word “hacked” in a headline alone can make a stock drop, lead many fearful customers to contact the customer service personnel, or even lead to breach-related lawsuits. Attack Other Applications At the beginning of this article I've mentioned that username leakage might be "cross-site." If the compromised information is used to identify you in other applications, these applications are also subject to some of the attacks mentioned throughout this post. Now, we'll move on to discussing the attacks that are made possible if the usernames are also email addresses or phone numbers. Phishing and Vishing (Voice Phishing) Usernames are half of full account takeover. The other half is the password. Attackers can use email addresses and phone numbers to contact users and trick them into giving their passwords away. Let's discuss the following hypothetical scenario: An attacker obtained a million email addresses from a site The attacker dumps the information into pastebin.com and informs the media of the hack The attacker contacts the users with sophisticated email messages claiming to be from the site The phishing message informs users of the data breach and urges them to change their password by following a link Some of the users that verified the breach on the online media choose to follow the link which leads them into a phishing site – masquerading as the actual site The users are asked to enter their existing password before creating a new one The attacker can now use the information to completely takeover the account on the hacked site Spam lists and Spam Campaigns Maintaining a list of emails can be very profitable for attackers. Such lists can be sold to spammers for money. The attackers may also choose to offer spam services themselves. In a spam campaign, the leaked usernames would be used to contact users by email or phone in order to present commercials or spread malware. Spear-Phishing Attacks An attacker may sometimes choose their target more carefully as targeted attacks on specific users might be harder to detect and investigate, and some targets are more valuable than others. Let’s say that the attacker notices the following email address in the list of exposed emails: "super.mega.admin@example.com" Using common logic, the attacker understands that compromising the computer used by this specific user is invaluable. He then attempts to create targeted phishing attacks only on this selected user. If successful, the attacker would be granted access to an organization’s key assets. “Forgot Your Password?” Sometimes the easiest way to hack an account is to utilize the “forgot password” recovery process. Forgot password pages are most often the weakest link in a site's authentication schema. You are often required to provide your username, email or phone number, and then answer a few personal questions. Such a question may be "what is your mother's maiden name?", which is far easier to guess or obtain than your actual password. Completing the "forgot password" process successfully often results in full account takeover. As mentioned before, such attacks could also be launched on other websites in which your leaked contact information is being used as your username. Exploit Other Vulnerabilities Some web-related vulnerabilities require the user to click a malicious link on the website. Among such attacks are OWASP TOP 10 attacks such as cross-site-scripting and cross-site-request-forgery. Exposed emails can be used to contact users and ask them to access the site, activating and enhancing other attacks. Cyber Warfare Different parties (such as governments) aim to create the most complete information base for their attacks. Adding usernames and contact information to their arsenal is something that should also worry the reader. Summary Usernames, email addresses and phone numbers are invaluable pieces of information for attackers. They can be used in a large variety of attacks which in some cases result in full account takeover. When it comes to username leakage – size matters. The bigger the list of exposed username the more damage can be done by a malicious entity. Posted by Oren Hafif on 10 June 2014 Sursa: From a Username to Full Account Takeover - SpiderLabs Anterior

[h=3]Word Exploit Delivery using MIME HTML Web Archive[/h]The creativity and research seen in Anti-virus evasion is interesting, not to considered the "maturing" nature of AV industry We have, multiple times in the past, came across Microsoft Office related exploits packaged and delivered as MIME HTML documents with a .doc extension. Surely Microsoft Word is known to handle and process such documents. Recently we came across a well known exploit for MS12-0158, which is detected by almost all major Anti-virus software in its raw form, however we noticed 100% evasion against the common AV products, when delivered as a MIME HTML package. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]MIME HTML Package of MS12-0158 Exploit[/TD] [/TR] [/TABLE] Anybody analysing a malicious Word document will be surprised at the first look of the content of the file. During further investigation, it was found that Microsoft Word support what is called a MIME HTML Web Archive. It was identified that the HTML code in turn invokes a known to be vulnerable control with data that triggers a Stack based Buffer Overflow in MSCOMCTL.OCX. The parameter to the ListView control that exploits the vulnerability is also embedded as a part of the document: [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]The part is referenced by ActiveX control initialisation earlier in the document.[/TD] [/TR] [/TABLE] Even though the sample evaded all AVs we tested at the time of writing, the above document part in its raw form (Base64 decoded) seem to be quite well known among AV products. The next step was to look into the exploit itself and the shellcode responsible for delivering the payload. A quick look on the decoded bytes gave an idea about the possible nature of the exploit and the start of the shellcode. Multiple NOP (0x90) bytes were identified prepended to a jmp short (0xeb) instruction. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Hexdump of param data passed to ListView control[/TD] [/TR] [/TABLE] Here 0x27583c30 is a platform independent address of JMP ESP instruction in MSCOMCTL.OCX used as a RETURN ADDRESS for exploitation of the vulnerability. The JMP ESP return is used for transition to shellcode that follows the return address. The RETURN ADDRESS in the above dump is immediately followed by the shellcode that starts with a bunch of NOP instruction. Upon closer inspection, the shellcode was found to be XOR encoded. The decoder decodes the actual payload by performing XOR operation on each byte with 0xBF as the key. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]XOR decoding of shellcode[/TD] [/TR] [/TABLE] The 2nd stage shellcode in turn performs the following: Extracts an embedded executable from the document. Decodes the executable. Drops and runs the executable from the Temporary Directory. The dropped executable in turn runs a VBE payload which is persisted by creating a shortcut in the current user startup directory. Sursa: 3S Labs: Word Exploit Delivery using MIME HTML Web Archive

/* Windows XP CD Key Verification/Generator v0.03 by z22 Compile with OpenSSL libs, modify to suit your needs. http://www.slproweb.com/download/Win32OpenSSL-v0.9.8b.exe History: 0.03 Stack corruptionerror on exit fixed (now pkey is large enough) More Comments added 0.02 Changed name the *.cpp; Fixed minor bugs & Make it compilable on VC++ 0.01 First version compilable MingW */ #include <stdio.h> #include <string.h> #include <openssl/bn.h> #include <openssl/ec.h> #include <openssl/sha.h> #include <assert.h> #define FIELD_BITS 384 #define FIELD_BYTES 48 unsigned char cset[] = "BCDFGHJKMPQRTVWXY2346789"; static void unpack(unsigned long *pid, unsigned long *hash, unsigned long *sig, unsigned long *raw) { // pid = Bit 0..30 pid[0] = raw[0] & 0x7fffffff; // hash(s) = Bit 31..58 hash[0] = ((raw[0] >> 31) | (raw[1] << 1)) & 0xfffffff; // sig(e) = bit 58..113 sig[0] = (raw[1] >> 27) | (raw[2] << 5); sig[1] = (raw[2] >> 27) | (raw[3] << 5); } static void pack(unsigned long *raw, unsigned long *pid, unsigned long *hash, unsigned long *sig) { raw[0] = pid[0] | ((hash[0] & 1) << 31); raw[1] = (hash[0] >> 1) | ((sig[0] & 0x1f) << 27); raw[2] = (sig[0] >> 5) | (sig[1] << 27); raw[3] = sig[1] >> 5; } // Reverse data static void endian(unsigned char *data, int len) { int i; for (i = 0; i < len/2; i++) { unsigned char temp; temp = data; data = data[len-i-1]; data[len-i-1] = temp; } } void unbase24(unsigned long *x, unsigned char *c) { memset(x, 0, 16); int i, n; BIGNUM *y = BN_new(); BN_zero(y); for (i = 0; i < 25; i++) { BN_mul_word(y, 24); BN_add_word(y, c); } n = BN_num_bytes(y); BN_bn2bin(y, (unsigned char *)x); BN_free(y); endian((unsigned char *)x, n); } void base24(unsigned char *c, unsigned long *x) { unsigned char y[16]; int i; BIGNUM *z; // Convert x to BigNum z memcpy(y, x, sizeof(y)); // Copy X to Y; Y=X for (i = 15; y == 0; i--) {} i++; // skip following nulls endian(y, i); // Reverse y z = BN_bin2bn(y, i, NULL); // Convert y to BigNum z // Divide z by 24 and convert remainder with cset to Base24-CDKEY Char c[25] = 0; for (i = 24; i >= 0; i--) { unsigned char t = BN_div_word(z, 24); c = cset[t]; } BN_free(z); } void print_product_id(unsigned long *pid) { char raw[12]; char b[6], c[8]; int i, digit = 0; // Cut a away last bit of pid and convert it to an accii-number (=raw) sprintf(raw, "%d", pid[0] >> 1); // Make b-part {640-....} strncpy(b, raw, 3); b[3] = 0; // Make c-part {...-123456X...} strcpy(c, raw + 3); // Make checksum digit-part {...56X-} assert(strlen© == 6); for (i = 0; i < 6; i++) digit -= c - '0'; // Sum digits while (digit < 0) digit += 7; c[6] = digit + '0'; c[7] = 0; printf("Product ID: 55274-%s-%s-23xxx\n", b, c); } void print_product_key(unsigned char *pk) { int i; assert(strlen((const char *)pk) == 25); for (i = 0; i < 25; i++) { putchar(pk); if (i != 24 && i % 5 == 4) putchar('-'); } } void verify(EC_GROUP *ec, EC_POINT *generator, EC_POINT *public_key, char *cdkey) { unsigned char key[25]; int i, j, k; BN_CTX *ctx = BN_CTX_new(); // remove Dashs from CDKEY for (i = 0, k = 0; i < strlen(cdkey); i++) { for (j = 0; j < 24; j++) { if (cdkey != '-' && cdkey == cset[j]) { key[k++] = j; break; } assert(j < 24); } if (k >= 25) break; } // Base24_CDKEY -> Bin_CDKEY unsigned long bkey[4] = {0}; unsigned long pid[1], hash[1], sig[2]; unbase24(bkey, key); // Output Bin_CDKEY printf("%.8x %.8x %.8x %.8x\n", bkey[3], bkey[2], bkey[1], bkey[0]); // Divide/Extract pid_data, hash, sig from Bin_CDKEY unpack(pid, hash, sig, bkey); print_product_id(pid); printf("PID: %.8x\nHash: %.8x\nSig: %.8x %.8x\n", pid[0], hash[0], sig[1], sig[0]); BIGNUM *e, *s; /* e = hash, s = sig */ e = BN_new(); BN_set_word(e, hash[0]); endian((unsigned char *)sig, sizeof(sig)); s = BN_bin2bn((unsigned char *)sig, sizeof(sig), NULL); BIGNUM *x = BN_new(); BIGNUM *y = BN_new(); EC_POINT *u = EC_POINT_new(ec); EC_POINT *v = EC_POINT_new(ec); /* v = s*generator + e*(-public_key) */ EC_POINT_mul(ec, u, NULL, generator, s, ctx); EC_POINT_mul(ec, v, NULL, public_key, e, ctx); EC_POINT_add(ec, v, u, v, ctx); EC_POINT_get_affine_coordinates_GFp(ec, v, x, y, ctx); unsigned char buf[FIELD_BYTES], md[20]; unsigned long h; unsigned char t[4]; SHA_CTX h_ctx; /* h = (fist 32 bits of SHA1(pid || v.x, v.y)) >> 4 */ SHA1_Init(&h_ctx); t[0] = pid[0] & 0xff; t[1] = (pid[0] & 0xff00) >> 8; t[2] = (pid[0] & 0xff0000) >> 16; t[3] = (pid[0] & 0xff000000) >> 24; SHA1_Update(&h_ctx, t, sizeof(t)); memset(buf, 0, sizeof(buf)); BN_bn2bin(x, buf); endian((unsigned char *)buf, sizeof(buf)); SHA1_Update(&h_ctx, buf, sizeof(buf)); memset(buf, 0, sizeof(buf)); BN_bn2bin(y, buf); endian((unsigned char *)buf, sizeof(buf)); SHA1_Update(&h_ctx, buf, sizeof(buf)); SHA1_Final(md, &h_ctx); h = (md[0] | (md[1] << 8) | (md[2] << 16) | (md[3] << 24)) >> 4; h &= 0xfffffff; printf("Calculated hash: %.8x\n", h); if (h == hash[0]) printf("Key valid\n"); else printf("Key invalid\n"); putchar('\n'); BN_free(e); BN_free(s); BN_free(x); BN_free(y); EC_POINT_free(u); EC_POINT_free(v); BN_CTX_free(ctx); } void generate(unsigned char *pkey, EC_GROUP *ec, EC_POINT *generator, BIGNUM *order, BIGNUM *priv, unsigned long *pid) { BN_CTX *ctx = BN_CTX_new(); BIGNUM *k = BN_new(); BIGNUM *s = BN_new(); BIGNUM *x = BN_new(); BIGNUM *y = BN_new(); EC_POINT *r = EC_POINT_new(ec); unsigned long bkey[4]; // Loop in case signaturepart will make cdkey(base-24 "digits") longer than 25 do { BN_pseudo_rand(k, FIELD_BITS, -1, 0); EC_POINT_mul(ec, r, NULL, generator, k, ctx); EC_POINT_get_affine_coordinates_GFp(ec, r, x, y, ctx); SHA_CTX h_ctx; unsigned char t[4], md[20], buf[FIELD_BYTES]; unsigned long hash[1]; /* h = (fist 32 bits of SHA1(pid || r.x, r.y)) >> 4 */ SHA1_Init(&h_ctx); t[0] = pid[0] & 0xff; t[1] = (pid[0] & 0xff00) >> 8; t[2] = (pid[0] & 0xff0000) >> 16; t[3] = (pid[0] & 0xff000000) >> 24; SHA1_Update(&h_ctx, t, sizeof(t)); memset(buf, 0, sizeof(buf)); BN_bn2bin(x, buf); endian((unsigned char *)buf, sizeof(buf)); SHA1_Update(&h_ctx, buf, sizeof(buf)); memset(buf, 0, sizeof(buf)); BN_bn2bin(y, buf); endian((unsigned char *)buf, sizeof(buf)); SHA1_Update(&h_ctx, buf, sizeof(buf)); SHA1_Final(md, &h_ctx); hash[0] = (md[0] | (md[1] << 8) | (md[2] << 16) | (md[3] << 24)) >> 4; hash[0] &= 0xfffffff; /* s = priv*h + k */ BN_copy(s, priv); BN_mul_word(s, hash[0]); BN_mod_add(s, s, k, order, ctx); unsigned long sig[2] = {0}; BN_bn2bin(s, (unsigned char *)sig); endian((unsigned char *)sig, BN_num_bytes(s)); pack(bkey, pid, hash, sig); printf("PID: %.8x\nHash: %.8x\nSig: %.8x %.8x\n", pid[0], hash[0], sig[1], sig[0]); } while (bkey[3] >= 0x62a32); base24(pkey, bkey); BN_free(k); BN_free(s); BN_free(x); BN_free(y); EC_POINT_free®; BN_CTX_free(ctx); } int main() { // Init BIGNUM *a, *b, *p, *gx, *gy, *pubx, *puby, *n, *priv; BN_CTX *ctx = BN_CTX_new(); // make BigNumbers a = BN_new(); b = BN_new(); p = BN_new(); gx = BN_new(); gy = BN_new(); pubx = BN_new(); puby = BN_new(); n = BN_new(); priv = BN_new(); // Data from pidgen-Bink-resources /* Elliptic curve parameters: y^2 = x^3 + ax + b mod p */ BN_hex2bn(&p, "92ddcf14cb9e71f4489a2e9ba350ae29454d98cb93bdbcc07d62b502ea12238ee904a8b20d017197aae0c103b32713a9"); BN_set_word(a, 1); BN_set_word(b, 0); /* base point (generator) G */ BN_hex2bn(&gx, "46E3775ECE21B0898D39BEA57050D422A0AF989E497962BAEE2CB17E0A28D5360D5476B8DC966443E37A14F1AEF37742"); BN_hex2bn(&gy, "7C8E741D2C34F4478E325469CD491603D807222C9C4AC09DDB2B31B3CE3F7CC191B3580079932BC6BEF70BE27604F65E"); /* inverse of public key */ BN_hex2bn(&pubx, "5D8DBE75198015EC41C45AAB6143542EB098F6A5CC9CE4178A1B8A1E7ABBB5BC64DF64FAF6177DC1B0988AB00BA94BF8"); BN_hex2bn(&puby, "23A2909A0B4803C89F910C7191758B48746CEA4D5FF07667444ACDB9512080DBCA55E6EBF30433672B894F44ACE92BFA"); // Computed data /* order of G - computed in 18 hours using a P3-450 */ BN_hex2bn(&n, "DB6B4C58EFBAFD"); /* THE private key - computed in 10 hours using a P3-450 */ BN_hex2bn(&priv, "565B0DFF8496C8"); // Calculation EC_GROUP *ec = EC_GROUP_new_curve_GFp(p, a, b, ctx); EC_POINT *g = EC_POINT_new(ec); EC_POINT_set_affine_coordinates_GFp(ec, g, gx, gy, ctx); EC_POINT *pub = EC_POINT_new(ec); EC_POINT_set_affine_coordinates_GFp(ec, pub, pubx, puby, ctx); unsigned char pkey[26]; unsigned long pid[1]; pid[0] = 640000000 << 1; /* <- change */ // generate a key generate(pkey, ec, g, n, priv, pid); print_product_key(pkey); printf("\n\n"); // verify the key verify(ec, g, pub, (char*)pkey); // Cleanup BN_CTX_free(ctx); return 0; } Sursa: http://antiwpa.planet-dl.org/Other/tmp/xpkey-0.03.cpp.txt

Egresser - Tool to Enumerate Outbound Firewall Rules Egresser is a tool to enumerate outbound firewall rules, designed for penetration testers to assess whether egress filtering is adequate from within a corporate network. Probing each TCP port in turn, the Egresser server will respond with the client’s source IP address and port, allowing the client to determine whether or not the outbound port is permitted (both on IPv4 and IPv6) and to assess whether NAT traversal is likely to be taking place. How it Works The server-side script works in combination with Iptables - redirecting all TCP traffic to port 8080 where the ‘real’ server resides. The server-side script is written in Perl and is a pre-forking server utilising Net::Server::Prefork, listening on both IPv4 and IPv6 if available. Any TCP connection results in a simple response containing a null terminated string made up of the connecting client’s IP and port. Feel free to use Telnet to interact with the service if you are in a restricted environment without access to the Egresser client (our Egresser server can be found at egresser.labs.cyberis.co.uk, which you are free to use for legitimate purposes). The client is also written in Perl and is threaded for speed. By default it will scan TCP ports 1-1024, although this is configurable within the script. It is possible to force IPv4 with the ‘-4’ command line argument, or IPv6 with ‘-6’; by default it will choose the protocol preferred by your operating system. If you want to explicitly list all open/closed ports, specify the verbose flag (-v), as normal output is a concise summary of permitted ports only. Why? It is recommended that outbound firewall rules are restricted within corporate environments to ensure perimeter controls are not easily circumvented. For example, inadequate egress filtering within an organisation would allow a malicious user to trivially bypass a web proxy providing filtering/AV/logging simply by changing a browser’s connection settings. Many other examples also exist - many worms spread over SMB protocols, malware can use numerous channels to exfiltrate data, and potentially unauthorised software (e.g. torrent/P2P file sharing) can freely operate, wasting corporate resources and significantly increasing the likelihood of malicious code being introduced into the environment. Generally, it is recommended that all outbound protocols should be restricted, allowing exceptions from specific hosts on a case-by-case basis. Web browsing should be conducted via dedicated web proxies only, with any attempted direct connections logged by the perimeter firewall and investigated as necessary. Egresser is a simple to use tool to allow a penetration tester to quickly enumerate allowed ports within a corporate environment. Download Egresser (client and server) can be downloaded from our GitHub respoitory - https://github.com/Cyberisltd/Egresser. Screenshot Posted by Cyberis at 16:16 Sursa: Cyberis Blog: Egresser - Tool to Enumerate Outbound Firewall Rules