Месяц: Июнь 2020

Original text by Andrea Brancaleoni (@nJoyneer – thypon)

A security testing tool to facilitate GraphQL technology security auditing efforts.

InQL can be used as a stand-alone script or as a Burp Suite extension.

InQL Stand-Alone CLI
Running 

• Queries, mutations, subscriptions
• Its fields and arguments
• Objects and custom object types

InQL can inspect the introspection query results and generate clean documentation in different formats such as HTML and JSON schema. InQL is also able to generate templates (with optional placeholders) for all known basic data types.
For all supported options, check the command line help:

usage: inql [-h] [--nogui] [-t TARGET] [-f SCHEMA_JSON_FILE] [-k KEY]

            [-p PROXY] [--header HEADERS HEADERS] [-d] [--generate-html]

            [--generate-schema] [--generate-queries] [--insecure]

            [-o OUTPUT_DIRECTORY]

InQL Scanner

optional arguments:

-h, --help show this help message and exit

--nogui Start InQL Without Standalone GUI [Jython-only]

-t TARGET Remote GraphQL Endpoint (https://<Target_IP>/graphql)

-f SCHEMA_JSON_FILE Schema file in JSON format

-k KEY API Authentication Key

-p PROXY IP of web proxy to go through (http://127.0.0.1:8080)

--header HEADERS HEADERS

-d Replace known GraphQL arguments types with placeholder

values (useful for Burp Suite)

--generate-html Generate HTML Documentation

--generate-schema Generate JSO N Schema Documentation

--generate-queries Generate Queries

--insecure Accept any SSL/TLS certificate

-o OUTPUT_DIRECTORY Output Directory

InQL Burp Suite Extension
Since version 1.0.0 of the tool, InQL was extended to operate within Burp Suite. In this mode, the tool will retain all the capabilities of the stand-alone script and add a handy user interface for manipulating queries.
Using the 

• Search for known GraphQL URL paths; the tool will grep and match known values to detect GraphQL endpoints within the target website
• Search for exposed GraphQL development consoles (GraphiQL, GraphQL Playground, and other common consoles)
• Use a custom GraphQL tab displayed on each HTTP request/response containing GraphQL
• Leverage the templates generation by sending those requests to Burp’s Repeater tool (“Send to Repeater”)
• Leverage the templates generation and editor support by sending those requests to embedded GraphIQL (“Send to GraphiQL”)
• Configure the tool by using a custom settings tab

To use 

• Download the Jython Jar
• Start Burp Suite
• Extender Tab > Options > Python Enviroment > Set the location of Jython standalone JAR
• Extender Tab > Extension > Add > Extension Type > Select Python
• Download the latest 
  inql_burp.py
   release here
• Extension File > Set the location of 
  inql_burp.py
   > Next
• The output should now show the following message: 
  InQL Scanner Started!

In the future we might consider integrating the extension within Burp’s BApp Store.

Burp Extension Usage
Getting started with the 

1. Load a GraphQL endpoint or a JSON schema file location inside the top input field
2. Press the “Load” button
3. After few seconds, the left panel will refresh loading the directory structure for the selected endpoint as in the following example:

• url
  • query
    • timestamp 1
      • query1.query
      • query2.query
    • timestamp 2
      • query1.query
      • query2.query
  • mutation
  • subscription

4. Selecting any query/mutation/subscription will load the corresponding template in the main text area

InQL Stand-Alone UI
Since version 2.0.0, InQL UI is now able to operate without requiring BURP. It is now possible to install InQL stand-alone for 

• Download and Install Jython. This can be obtained on macOS through brew 
  brew install jython
   or on Ubuntu derivates through 
  apt-get install -y jython
• Install inql through pip with 
  jython -m pip install inql
• Start the UI through jython with 
  jython -m inql

InQL Documentation Generator
In either BURP or in Stand-Alone mode, InQL is able to generate meaningful documentation for available GraphQL entities. Results are available as HTML pages or query templates.
The resulting HTML documentation page will contain details for all available 

The following screenshot shows the use of templates generation:

Credits
Author and Maintainer: Andrea Brancaleoni (@nJoyneer – thypon)
This project was made with love in Doyensec Research island.Download Inql

Original text by vincss

LNK test file GIT

Shell Link Binary File Format, which contains information that can be used to access another data object. The Shell Link Binary File Format is the format of Windows files with the extension «LNK», we call it a shortcut file. Regarding the structure of this format is very complicated, Microsoft has provided a document about LNK file format for reference^[1].
I’ve followed the Microsoft patches for a long time. In 2018, I found that they had 2 LNK bugs which were fixed and all of them were RCE. Recently, @Lays found a bunch of LNK file parsing bugs, so with this binary file format I think it is suitable for fuzzing. However, you need to reverse and learn how to handle this LNK file on Windows.
Introduction
File Explorer, previously known as Windows Explorer, is a file manager application that has been included with releases of the Microsoft Windows operating system from Windows 95 onwards. It provides a graphical user interface for accessing the file systems. It is also the component of the operating system that presents many user interface items on the screen such as the taskbar and desktop.
Explorer has a lot of features, each version of the operating system has been upgraded it by Microsoft. Here I discovered that the Explorer will automatically parsing the LNK file if the LNK file appears in the context that the Explorer is accessing. For example, if we are on the desktop, the Explorer will parse the LNK files that appear on the desktop and maybe in some secondary directory (about the depth of the folder that the Explorer can access, I don’t know).
Introduce parsing LNK file in Explorer
How can we build an arsenal to fuzz this LNK file format? We need to rely on Explorer, debug it, use Windbg attach to process explorer.exe:

I put break-point at 2 functions are CreateFileA and CreateFileW, I guess that Explorer will use it to read the file before parsing.

After a few breaks on the CreateFileW function, I saw the explorer calling the CreateFileW function with the file «Process Hacker 2.lnk», this LNK file is on the desktop. I view the call stack at this breakpoint:

We can see that a series of APIs related to CShellLink are called in the windows.storage.dll. Here I returned to MSDN to learn about these CShellLink related API and I found this^[2]:

It is possible to create an LNK parsing program using the IShellLink interface. Based on what MSDN provides I use IPersistFile to load and parsing LNK files, this is the harness I use to fuzzing.

I debug the test with the harness that I built on the file «test_debug.lnk»

Comparing the call stack between my harness and Explorer looks quite similar. I decided to use this harness for fuzzing.
Fuzzing LNK
Corpus for this LNK file I found is also quite available on the Github repo. I found and downloaded, then used them to fuzz. With the familiar winafl^[3] and Dynamorio^[4], I used it with coverage_module windows.storage.dll. Run fuzzing with 1 master and  7 slave. About fuzzing and coverage, you can read my blogs before^[5][6].
After some time running fuzzing, I went back to check my crashes, I found 4 unique crashes:

• Out of bound read in windows_storage!CRegFolder::_AttributesOf
• Out of bound read in windows_storage!CRegFolder::_CreateCachedRegFolder
• Out of bound read in shell32!CControlPanelCategoryFolder::_IsValidCategoryPidl
• Double free in windows_storage!DSA_DestroyCallback

I checked these 4 crashes on Explorer, only double-free bug can cause explorer.exe crash, 3 out of bound read bugs do not cause explorer.exe crash. I reported all 4 bugs to Microsoft, Microsoft only accepted one of my double-free bug, they rejected the rest because the crash did not occur on the default configuration of the system and could not be exploited (regarding the default configuration of the system, I think due to the harness I use is not complete like Explorer when parsing 1 LNK file).
CVE-2020-1299
The double-free bug I found above was fixed in this June patch of Microsoft, here is a bit of the cause of this bug:We have struct DSA as follows:

DSA object:

struct DSA
{
  INT nItemCount;
  LPVOID pData;
  INT nMaxCount;
  INT nItemSize;
  INT nGrow;
};DSA object^[7] is initialized at DSA_Create^[8] and insert items with DSA_InsertItem^[9]. While inserting additional items, it will allocate a memory area for the pData field in the struct DSA.
When releasing DSA object, the program has called DSA_DestroyCallback function twice to release the same DSA object.

The function s_DestroyCacheItemCB has an error:

When freeing the pData field, it did not check the availability of this memory, resulting in a double-free bug. The pData memory has been free before, I don’t analyze further why the DSA object was destroyed twice due to some condition in the previous thread.
For this bug, we can use after free on the DSA object to trigger RCE.
Conclusion
Above is the whole process I researched to find an attack surface for the LNK file, apply fuzzing to find fault of the LNK parsing process. At the time I found this bug, I only targeted the windows.storage.dll DLL without knowing that LNK had another type: LNK search (after ZDI published blog which analyzed a bug of @Lays, I realized this format)^[10]. In addition to windows.storage.dll used to parsing LNK files, there are also windows.storage.search.dll and StructuredQuery.dll. The following blog I will talk about some bugs I found in StructuredQuery.dll but Microsoft does not fix it although it may cause DOS temporarily. Microsoft suggests that I can blog about those bugs and they are confident that they can answer every customer’s questions with bugs they don’t fix.

[1] https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-shllink/16cb4ca1-9339-4d0c-a68d-bf1d6cc0f943

[2] https://docs.microsoft.com/en-us/windows/win32/shell/links

[3] https://github.com/googleprojectzero/winafl

[4] https://github.com/DynamoRIO/dynamorio

[5] https://ezqelusia.blogspot.com/2020/05/start-fuzzing-fuzz-various-image-viewers.html

[6] https://ezqelusia.blogspot.com/2020/05/microsofts-first-bug.html

[7] https://docs.microsoft.com/en-us/windows/win32/api/dpa_dsa/

[8] https://docs.microsoft.com/en-us/windows/win32/api/dpa_dsa/nf-dpa_dsa-dsa_create

[9] https://docs.microsoft.com/en-us/windows/win32/api/dpa_dsa/nf-dpa_dsa-dsa_insertitem[10] https://www.zerodayinitiative.com/blog/2020/3/25/cve-2020-0729-remote-code-execution-through-lnk-files

Original text by DTM

Introduction

This short post explores the file formats .searchConnector-ms and .library-ms. Both of these file formats have default file associations on most Windows versions. They integrate with Windows to show content from a arbitrary location which can also be a remote location by specifying a WebDAV share. As seen in the header image to this post these files can be creatively applied to blend in as legitimate folders.

Try these examples at https://github.com/dtmsecurity/examples:

• Documents.searchConnector-ms
• Pictures.library-ms

Playing with these files

I started out by digging out documentation [1] for the search connector file format. When I specified a HTTP URL I noticed Windows making PROPFIND requests. So I then set out to set up a WebDAV server for testing. I found the TrustedSec blog [2] useful. However, I made a few tweaks which I think are down to me using a more recent version of wsgidav than when the article was written.

I settled for a YAML config of the following — allowing a read-only mount point:

I then ran wsgidav as follows (after sorting the certificate out with certbot):

.searchConnector-ms

I then successfully made my *.searchConnector-ms file work — hurray! Clicking on my file (where the file extension is hidden even if the file extension is set to show in Windows it seems) gave my remote folder.

The above output shows the XML format I put together for this copy and pasting largely from the Microsoft article. Another related file format is referenced *.osdx — However, when I tried to create one of these in Windows 10, I kept on getting an error ‘Unsupported in this Windows version’. But the article eludes that (maybe for older versions of Windows) you can cause search connector files to be loaded via this other format.

.library-ms

When exploring the search connector format, it was clear that there is similarities with the *.library-ms. The default libraries in Windows are stored in:

Check out the default libraries, as these denote your ‘Documents’,’Pictures’ etc. These can also be modified to point at remote locations and clicking on a *.library-ms file can give the similar results to above as shown below. Note: the warning about being an ‘unsupported library location’.

The above output shows an example XML file for a *.libary-ms file.

Why is this interesting?

As far as email phishing goes URLs and file attachments are subject to more stringent checks. You could include a WebDAV link directly in an email, or attach an *.lnk file or similar but these are much more widely known and obvious attack vectors.

I find these lesser known files interesting from a payload delivery perspective as you can see from the header picture they can be trivially made to look like local or internal file locations.  If you can get someone to click on one you at the very least have some record of the interaction (assuming WebDAV / Web Client is enabled). You can potentially tempt someone to click a payload held within the shared folder which then may now only checked by an inline proxy. This potentially side steps some of the whole end-to-end delivery suite of security products you typically face if they do not perceive these file formats as a threat.

On the flip side there is a potential option to modify existing *.libary-ms files post compromise in order to:

• Show different content to a user i.e. persistence via a document lying around.
• Trick users into saving data to a familiar location which is actually remote.

Mitigations

• Disable the Web Client to prevent WebDAV being used to access remote locations.
• Block or monitor WebDAV connections via enterprise proxy.
• Apply a whitelist of allowed file types for email attachments and downloads.
• Monitor the integrity of *.library-ms files.

[1] https://docs.microsoft.com/en-us/windows/win32/search/search-sconn-desc-schema-entry

[2]  https://www.trustedsec.com/blog/how-to-set-up-a-quick-simple-webdav-server-for-remote-file-sharing/