Didier Stevens

Thursday 4 April 2019

Quickpost: Browsers & Content-Disposition

Filed under: Quickpost — Didier Stevens @ 0:00

A quick check confirmed that response header Content-Disposition can direct browsers to display or save a file.

I used my tcp-honeypot.py to serve 3 HTTP responses:

HTTP/1.1 200 OK
Content-Disposition: inline

Line 1
Line 2
Line 3

 

HTTP/1.1 200 OK
Content-Disposition: attachment

Line 1
Line 2
Line 3

 

HTTP/1.1 200 OK
Content-Disposition: attachment; filename=”test.js”

Line 1
Line 2
Line 3

 

Only the Content-Disposition response header changes between these 3 responses.

With Content-Disposition response header “inline”, Internet Explorer displays the content inside the browser window:

With Content-Disposition response header “attachment”, Internet Explorer proposes to save the content to disk using a generated filename:

With Content-Disposition response header “attachment; filename=”test.js””, Internet Explorer proposes to open or save the content to disk using the provided filename test.js:

When option Open is selected, file test.js will be opened with the Windows scripting host (after warnings are clicked away).

The behavior of Edge is quite similar:

Google Chrome saves the file to disk without prompting the user (attachment):

And Firefox prompts the user (attachment):

Tests were conducted on a fully patched Windows 10 1809 machine, with default configurations for Internet Explorer and Edge.

The latest versions of Chrome and Firefox were installed with default configurations.


Quickpost info


Saturday 23 March 2019

Quickpost: PDF Tools Download Feature

Filed under: My Software,PDF,Quickpost — Didier Stevens @ 9:34

When I’m asked to perform a quick check of an online PDF document, that I expect to be benign, I will just point my PDF tools to the online document. When you provide an URL argument to pdf-parser, it will download the document and perform the analysis (without writing it to disk).


Quickpost info


 

Monday 3 December 2018

Quickpost: Developing for ESP32 with the Arduino IDE

Filed under: Hardware,Quickpost,WiFi — Didier Stevens @ 0:00

I have a couple of ESP32’s that can also be programmed with the Arduino IDE, provided the necessary board manager is installed:

After starting the IDE

I open the preferences:

And add the board manager URL for the ESP32 (https://dl.espressif.com/dl/package_esp32_index.json):

And via the Tools menu I launch the Boards Manager:

And install the ESP32 board manager:

And then I can select the right board (ESP32 Dev Module):

Then I can connect my ESP32 board to my Windows machine, and it will complain about missing drivers:

I install the CP210x drivers:

Then I can select the right port in the Tools menu:

And now everything is ready to program my ESP32. I will start with the WiFiScan example:

Which can then be compiled and uploaded to the ESP32 board:

Once it is uploaded and running, I can connect to the ESP32 board via the serial monitor:

 

 

Monday 26 November 2018

Quickpost: Compiling with Build Tools for Visual Studio 2017

Filed under: Quickpost — Didier Stevens @ 0:00

Compiling C/C++ programs with Microsoft’s command-line compilers is possible, even if you don’t have Visual Studio installed. You can do this with the Build Tools for Visual Studio 2017 (a free download).

Go to https://visualstudio.microsoft.com/downloads/ and download the Build Tools:

The downloaded file does not include the build tools, but it’s a stager that will download the necessary build tools. It requires .NET, you might get an error if the proper version is not installed:

Installing the correct .NET framework will fix this problem:

Once this download is completed, you can get to the actual installer where you choose the tools you want:

I selected the Visual C++ build tools, a download of about 1 GB:

Once the build tools are installed, you can open a shell via the start menu:

The C/C++ compiler is invoked with command cl:

As an example, I’m compiling the following program:


Quickpost info


 

Monday 19 November 2018

Quickpost: Compiling 32-bit Static ELF Files on Kali

Filed under: Quickpost — Didier Stevens @ 0:00

Here I compile EICARgen on Kali Linux to a 32-bit, statically linked Linux executable.

gcc’s option -m32 creates a 32-bit executable on 64-bit Linux.

If you get this error:

then one way to solve it is by installing libc6-dev-i386 (apt install libc6-dev-i386):

Then option -m32 can be used to create a 32-bit executable:

This executable will not run on 64-bit system that don’t have the libraries we just installed. A work-around is to statically link the ELF file with option -static:

 


Quickpost info


Monday 5 November 2018

Quickpost: Using pcapy with Npcap on Windows

Filed under: Quickpost — Didier Stevens @ 0:00

I installed pcapy on a Windows machine, but importing in Python failed due to a missing DLL.

Process Monitor showed me what was missing: wpcap.dll, a WinPcap DLL:

The DLL was missing because I had installed Npcap (an alternative for WinPcap, that provides loopback packet capture).

This problem can be fixed by setting a toggle to install a WinPcap compatible API (e.g. wpcap.dll) during installation:


Quickpost info


Monday 24 September 2018

Quickpost: Signing Windows Executables on Kali

Filed under: Quickpost — Didier Stevens @ 0:00

Windows executables (PE files) can be signed on Kali using osslsigncode.

osslsigncode needs to be installed:

apt install osslsigncode

Then you need a certificate. For this demo, I’m using a self-signed cert.

The command to sign file demo-x64.exe with the demo certificate using SHA1 and timestamping, is:

osslsigncode sign -certs cert-20180729-110705.crt -key key-20180729-110705.pem -t http://timestamp.globalsign.com/scripts/timestamp.dll -in demo-x64.exe -out demo-x64-signed.exe

The signed file is demo-x64-signed.exe

To dual sign this executable (add SHA256 signature), use this command:

osslsigncode sign -certs cert-20180729-110705.crt -key key-20180729-110705.pem -t http://timestamp.globalsign.com/?signature=sha2 -h sha256 -nest -in demo-x64-signed.exe -out demo-x64-dual-signed.exe

The signed file is demo-x64-dual-signed.exe

Of course, Windows reports the signatures as invalid, because we used a self-signed certificate. For a valid signature, you can add your certificate to the trusted root certificates store, buy a code-signing certificate, …

For single SHA256 signing, use the second osslsigncode command without option -nest.

 


Quickpost info


Monday 17 September 2018

Quickpost: Compiling EXEs and Resources with MinGW on Kali

Filed under: Quickpost — Didier Stevens @ 0:00

To compile a Windows executable with version information and an icon on Kali, we use MinGW again.

The version information and icon (demo.ico) we want to use are defined in a resource file (demo.rc):

#include "winver.h"


#define IDI_ICON1                       101

/////////////////////////////////////////////////////////////////////////////
//
// Version
//

#define VER_FILEVERSION             0,0,0,1
#define VER_FILEVERSION_STR         "0.0.0.1\0"

#define VER_PRODUCTVERSION          0,0,0,1
#define VER_PRODUCTVERSION_STR      "0.0.0.1\0"

#ifndef DEBUG
#define VER_DEBUG                   0
#else
#define VER_DEBUG                   VS_FF_DEBUG
#endif

VS_VERSION_INFO VERSIONINFO
FILEVERSION     VER_FILEVERSION
PRODUCTVERSION  VER_PRODUCTVERSION
FILEFLAGSMASK   VS_FFI_FILEFLAGSMASK
FILEFLAGS       VER_DEBUG
FILEOS          VOS__WINDOWS32
FILETYPE        VFT_APP
FILESUBTYPE     VFT2_UNKNOWN
BEGIN
    BLOCK "StringFileInfo"
    BEGIN
        BLOCK "040904E4"
        BEGIN
            VALUE "CompanyName", "example.com"
            VALUE "FileDescription", "demo"
            VALUE "FileVersion", VER_FILEVERSION_STR
            VALUE "InternalName", "demo.exe"
            VALUE "LegalCopyright", "Public domain"
            VALUE "OriginalFilename", "demo.exe"
            VALUE "ProductName", "demo"
            VALUE "ProductVersion", VER_PRODUCTVERSION_STR
        END
    END
    BLOCK "VarFileInfo"
    BEGIN
        VALUE "Translation", 0x409, 1252
    END
END


/////////////////////////////////////////////////////////////////////////////
//
// Icon
//

// Icon with lowest ID value placed first to ensure application icon
// remains consistent on all systems.
IDI_ICON1               ICON                    "demo.ico"
/////////////////////////////////////////////////////////////////////////////

More info on the VERSIONINFO resource can be found here.
We use the resource compiler windres, and then the gcc compiler.

Compile for 64-bit:

x86_64-w64-mingw32-windres demo.rc demo-resource-x64.o
x86_64-w64-mingw32-gcc -o demo-x64.exe demo-resource-x64.o demo.c

Compile for 32-bit:

i686-w64-mingw32-windres demo.rc demo-resource-x86.o
i686-w64-mingw32-gcc -o demo-x86.exe demo-resource-x86.o demo.c

 

DemoResource_V_0_0_0_1.zip (https)
MD5: 9104DDC70264A9C2397258F292CC8FE4
SHA256: 722B3B52BAE6C675852A4AC728C08DBEEF4EC9C96F81229EF36E30FB54DC49DE


Quickpost info


Tuesday 28 August 2018

Quickpost: Compiling DLLs with MinGW on Windows

Filed under: Quickpost — Didier Stevens @ 0:00

MinGW is not only available on Kali, of course, but also on Windows. Compiling a DLL is very similar.

MinGW is installed in folder C:\msys64 on my machine.

 

To compile 64-bit executables, you need to start the 64-bit shell first: launch C:\msys64\mingw64.exe

Then you can compile the DLL:

gcc -shared -o DemoDll-x64.dll DemoDll.cpp

For 32-bit executables, it’s the 32-bit shell: launch C:\msys64\mingw32.exe

Then you can compile the DLL:

gcc -shared -o DemoDll-x86.dll DemoDll.cpp

 

It’s also possible to start the shell and compile from a BAT file:

call C:\msys64\msys2_shell.cmd -mingw64 -here -c "gcc -shared -o DemoDll-x64.dll DemoDll.cpp"
call C:\msys64\msys2_shell.cmd -mingw32 -here -c "gcc -shared -o DemoDll-x86.dll DemoDll.cpp"

 

 


Quickpost info


Saturday 18 August 2018

Quickpost: Revisiting JA3

Filed under: Networking,Quickpost — Didier Stevens @ 0:00

A year ago I tried out JA3. Time for a new test.

This new version no longer crashes on some packets, it’s more stable. However, there’s a bug when producing json output, which is easy to fix.

The JA3 Python program no longer matches TLS fingerprints: it produces a list of data (including fingerprint) for each client Hello packet.

Running this new version on the same pcap file as a year ago (and extracting the fingerprints) yields exactly the same result: 445 unique fingerprints, 7588 in total.

I have more matches this time when matching with the latest version of ja3fingerprint.json: 75 matches compared to 24 a year ago.

Notice that Shodan is one of the matched fingerprints.

Let’s take a closer look:

I’m looking for connections with fingerprint digest 0b63812a99e66c82a20d30c3b9ba6e06:

80.82.77.33 is indeed Shodan:

Name: sky.census.shodan.io
Address: 80.82.77.33


Quickpost info


Next Page »

Blog at WordPress.com.