nullmethod

Jekyll Arbitrary File Write

2014-01-14T00:00:00+00:00

Because Jekyll was sanitizing file paths prior to URL decoding the path, it was possible to set a permalink to write a generated page outside of the output directory. This is not an issue for most users of Jekyll. It is if you are GitHub and build users’ sites for pages.github.com.

More Info

Jekyll Release Notes

GitHub Vulnerability Responsible Disclosure

2013-07-01T00:00:00+00:00

Reflected XSS in render.github.com and some parameter tomfoolery to prompt users to approve for a set of OAuth scopes and actually approve another set.

More Info

GitHub Security

PGP Universal Server Private Key Disclosure

2012-08-30T00:00:00+00:00

Improper session handing within PGP Universal Server allows a socket connection to assume the authentication of a previously established socket.

More Info

Direct object reference in Punchd

2012-02-01T00:00:00+00:00

Direct object reference in Punchd to allow the unauthorized modification of other users’ records.

More Info

Google HoF

Disabling WPS on Wireless APs via Firmware Modification

2012-01-04T00:00:00+00:00

Due to the recent horribleness discovered in WPS, I have been very uncomfortable with the security of my home wireless network. Just last year I purchased new wireless APs from Linksys (E4200 and WRT320N) and unfortunately both of these models continue to respond to PIN External Registrar requests, even if WPS is not configured on the router. As of now no firmware updates have been published by Linksys to disable this so I investigated the possibility to perform the modification myself. Luckily, all of the tools required have already been developed and it appears that the WPS functionality can be easily disabled via filesystem changes.

I took the following steps to disable WPS in the Linksys firmware. Obviously, it’s possible I may have jacked up my AP in the process, I heed the warning that you may do the same, and I take no responsibility if you do.

Download and install the Firmware Modification Kit

This is a set of tools and scripts developed to extract and rebuild firmware filesystems. I had used binwalk and unsquashfs in the past, but this contains a number of modifications to make it easy to perform the rootfs extraction. These instructions are all you will need to get started.

Download your router’s firmware image

Linksys hosts their images at http://homesupport.cisco.com/en-us/support/linksys. For the E4200 I had to use an older version than currently hosted (1.0.01) from http://www.dd-wrt.com/phpBB2/viewtopic.php?p=620773 as the squashfs extraction did not work properly with the latest image.

Slice and dice the image and extract the rootfs

~/firmware-mod-kit-read-only/trunk# ./extract-ng.sh ./FW_E4200_1.0.01.010_US_20110221_code.bin
Firmware Mod Kit (build-ng) 0.73 beta, (c)2011 Craig Heffner, Jeremy Collake
http://www.bitsum.com

Scanning firmware...

DECIMAL     HEX         DESCRIPTION
-------------------------------------------------------------------------------------------------------
32          0x20        TRX firmware header, little endian, header size: 28 bytes,  image size: 9560064 bytes, CRC32: 0x8F8B2A81 flags/version: 0x10000
758932      0xB9494     Squashfs filesystem, little endian, version 3.0, size: 8796875 bytes, 1474 inodes, blocksize: 65536 bytes, created: Mon Feb 21 05:16:54 2011

Extracting 758932 bytes of  header image at offset 0
Extracting squashfs file system at offset 758932
Extracting squashfs files...
Firmware extraction successful!
Firmware parts can be found in 'fmk/*'

Identifying these binaries was not an exhaustive task, basically find / -name "*wps*" and a quick strings to see if WPS-like things such as WFA-SimpleConfig-Registrar-1-0 showed up (I’m a mad reverse engineer…). I kept a bogus symlink (busybox will just error) as it seemed like a better idea than ENOENT.

tl;dr this is a huge hack and will likely break things

~/firmware-mod-kit-read-only/trunk# cd fmk/rootfs/bin/
~/firmware-mod-kit-read-only/trunk/fmk/rootfs/bin# mv wps_monitor wps_monitor.old
~/firmware-mod-kit-read-only/trunk/fmk/rootfs/bin# ln -s busybox wps_monitor

For the WRT320N I also removed the files /bin/wps_ap and /bin/wps_enr. They seemed equally WPS related.

Rebuild the firmware image

~/firmware-mod-kit-read-only/trunk# ./build-ng.sh 
Firmware Mod Kit (build-ng) 0.73 beta, (c)2011 Craig Heffner, Jeremy Collake
http://www.bitsum.com
  
Building new squashfs file system...
Creating little endian 3.0 filesystem on fmk/new-filesystem.squashfs, block size 65536.
  
Little endian filesystem, data block size 65536, compressed data, compressed metadata, compressed fragments
Filesystem size 8590.70 Kbytes (8.39 Mbytes)
  23.00% of uncompressed filesystem size (37343.77 Kbytes)
Inode table size 11992 bytes (11.71 Kbytes)
  25.08% of uncompressed inode table size (47823 bytes)
Directory table size 11251 bytes (10.99 Kbytes)
  42.89% of uncompressed directory table size (26233 bytes)
Number of duplicate files found 162
Number of inodes 1475
Number of files 1244
Number of fragments 183
Number of symbolic links  129
Number of device nodes 0
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 102
Number of uids 1
  root (0)
Number of gids 0
Remaining free bytes in firmware image: 3948
Processing 1 header(s) from fmk/new-firmware.bin...
Processing header at offset 32...checksum(s) updated OK.
CRC(s) updated successfully.
Finished! New firmware image has been saved to: fmk/new-firmware.bin

Flash the new firmware image

It’s at ./fmk/new-firmware.bin. This is just the same as you would the factory firmware. I made sure to make a backup of my configuration file first, but to each their own.

Results

Prior to modifying the firmware, the following happened.

~# iw wlan0 scan
BSS 58:6d:8f:aa:bb:cc (on wlan0)
  freq: 2422
  beacon interval: 100
  capability: ESS Privacy ShortSlotTime (0x0411)
  signal: -61.00 dBm
  last seen: 3036 ms ago
  SSID: meganetprime
  Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 
  ... blah blah ...
  WPS:   * Version: 1.0
     * Manufacturer: Linksys
     * Model: Linksys E4200
     * Device name: Linksys E4200
     * Config methods: Label, PBC
  WMM:   * Parameter version 1
     * u-APSD
     * BE: CW 15-1023, AIFSN 3
     * BK: CW 15-1023, AIFSN 7
     * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
     * VO: CW 3-7, AIFSN 2, TXOP 1504 usec

Now, this happens

BSS 58:6d:8f:aa:bb:cc (on wlan0)
  TSF: 112947587 usec (0d, 00:01:52)
  freq: 2422
  beacon interval: 100
  capability: ESS Privacy ShortSlotTime (0x0411)
  signal: -67.00 dBm
  last seen: 1640 ms ago
  SSID: meganetprime
  Supported rates: 1.0* 2.0* 5.5* 11.0* 18.0 24.0 36.0 54.0 
   ... blah blah ...
  WMM:   * Parameter version 1
     * u-APSD
     * BE: CW 15-1023, AIFSN 3
     * BK: CW 15-1023, AIFSN 7
     * VI: CW 7-15, AIFSN 2, TXOP 3008 usec
     * VO: CW 3-7, AIFSN 2, TXOP 1504 usec

and before with reaver-wps:

~# reaver --pin=11223344 -vv -i mon4 -b 58:6d:8f:aa:bb:cc

Reaver v1.3 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner 

[+] Waiting for beacon from 58:6D:8F:AA:BB:CC
[+] Switching mon4 to channel 3
[+] Associated with 58:6D:8F:AA:BB:CC (ESSID: meganetprime)
[+] Trying pin 11223344
[!] WARNING: Last message not processed properly, reverting state to previous message
[+] Trying pin 11223344
[+] Trying pin 11223344
[!] WARNING: Last message not processed properly, reverting state to previous message
[+] Trying pin 11223344
[+] Key cracked in 12 seconds
[+] WPS PIN: '11223344'
[+] WPA PSK: 'myridiculouslylongkeythatsimpossibletotypeonakindle'
[+] AP SSID: 'meganetprime'

After new firmware:

Reaver v1.3 WiFi Protected Setup Attack Tool
Copyright (c) 2011, Tactical Network Solutions, Craig Heffner 

[?] Restore previous session? [n/Y] n
[+] Waiting for beacon from 58:6D:8F:AA:BB:CC
[+] Switching mon5 to channel 3
[+] Associated with 58:6D:8F:AA:BB:CC (ESSID: meganetprime)
... time passes ...
^C
[+] Nothing done, nothing to save.
[+] Session saved.

Looks like success to me!

Likely a similar process will work for other vendors and APs and hopefully this will hold down the fort until official firmware updates start being released.

Aruba WAP OS Command Injection

2011-11-01T00:00:00+00:00

OS command injection in RAP web interface.

More Info

Aruba Advisory (AID-031912)

Exploiting USB Devices with Arduino

2011-08-04T00:00:00+00:00

During Black Hat USA 2011 in Las Vegas, I had the privilege to present my work in assessing and exploiting USB devices with low cost development hardware.

This step-by-step walkthrough of USB device assessment and exploitation from a application security professional’s point of view discusses USB analysis, protocol comprehension, and the creation of custom Arduino USB firmware to exploit architectural vulnerabilities of USB proximity sensor devices.

Abstract

Hardware devices are continually relied upon to maintain a bridge between physical and virtual security. From access cards to OTP tokens, hardware devices receive limited review by application security professionals. They are often considered vastly more complex and difficult to assess than common web- and network-based applications.

In this talk I will cover a lightweight methodology to use when approaching the assessment of USB-based hardware devices. This will include the identification of trust boundaries and threat modeling, use case analysis though protocol analysis, as well as crafting a hardware device to exploit identified vulnerabilities. Not only will this methodology be described, it will be detailed through the assessment and exploitation of a hardware-based proximity sensor. Hardware-based proximity sensors attempt to enforce desktop security and lock a user’s desktop when the device has been removed from the vicinity of the computer. I will describe my experience and process for assessing a USB-based proximity sensor device and its eventual exploitation using components of the Arduino hardware architecture. I will describe the entire process not from the view of an electrical engineer, but from that of an application security professional with limited knowledge of current and voltage and a hobbyist’s budget.

Artifacts

CSRF File Uploads in Firefox 4

2011-05-10T00:00:00+00:00

So apparently the ability to send multipart/form-data file uploads via CSRF is a “thing”. See http://blog.kotowicz.net/2011/04/how-to-upload-arbitrary-file-contents.html and http://kuza55.blogspot.com/2008/02/csrf-ing-file-upload-fields.html.

Last year I stumbled upon the same issue as kuza55, a rather ridiculous injection flaw in Firefox 3. An input field’s name is not properly escaped for quotes and could be used to inject a filename parameter into the Content-Disposition of a multipart/form-data POST.

I just revisited this in Firefox 4 and discovered that they now attempt to escape quotes. A quote now becomes \" in an input field’s name. However, they failed Escaping 101 and do not escape backslashes. It is possible to craft an input field’s name that still escapes the name parameter and injects a filename into the Content-Disposition.

A name value of:

\"; name=param_name; filename=filename.ext;

will create the Content-Disposition of:

Content-Disposition: form-data; name="\\"; name=param_name; filename=filename.ext;"

In a quick Sinatra test app this post is still parsed as a valid file upload with a parameter name of param_name and a filename of filename.ext. I am guessing successful parsing of this request may vary depending on the web / application server.

I posted a jQuery POC for this CSRF at: https://gist.github.com/5d5615e3ea6a26f257de

FYI, looks like WebKit browsers URL encode quotes, sensibly preventing this type of injection. IE 8 still appears to still be susceptible to the initial quote injection.

Stored XSS in Chrome Web Store

2010-11-12T00:00:00+00:00

Stored XSS in Chrome Web Store.

More Info

Google HoF

Web Application Scanners - Evaluating Past the Base Case

2010-10-10T00:00:00+00:00

Presented at Hacker Halted 2010 in Miami, this talk reviews automated web application scanners’ ability to identify common web application vulnerabilities and real-world deviations from base case vulnerabilities.

Artifacts

Slides

Scanning Reality - Limits of Automated Vulnerability Scanners

2010-06-11T00:00:00+00:00

This article published in Dark Reading details the commonly overlooked limitations of automated vulnerability scanners and the assumptions that could lead to security fail.

Abstract

Automated security scanning products are at the core of most vulnerability management programs. Many security teams, in fact, will use more than one scanner to validate what each finds and get the broadest possible coverage to expose weaknesses in their computing environments. However, although these scanners are important security tools, they have significant limitations, and organizations that rely exclusively on them will be exposed to potentially high levels of risk. In this report, we will present three key areas in which automated vulnerability scanners fall short and the steps you can take to address security issues that are not identified by these tools.

More Info

Download Report

Forensic Fail

2010-04-23T00:00:00+00:00

Presented at the first Thotcon conference in Chicago, this Mortal Kombat themed talk details modern forensic techniques and ways malware can defend itself. Topics include Linux rootkits, Linux kernel module packers, and 0-day in popular forensic tools.

Artifacts

Slides

So Long, and Thanks For All the Clock Cycles

2009-09-20T00:00:00+00:00

Presented at Hacker Halted 2009 in Miami, this talk revealed researh, development, and POC deployment of a distributed / crowd-sourced password cracker that gathers clock-cycles through XSS vulns. Utilizing a Java applet and Django backend, password cracking chunks are distributed to and processed by unsuspecting clients. Includes crowd-pleasing admin interface written in Flex.

Artifacts

Directory Traversal in Archives

2009-04-21T00:00:00+00:00

Originally posted on labs.neohapsis.com with Patrick Toomey

I’m sure on the top of everyone’s list of resolutions from the New Year is the ever forgotten “I will write more secure code” and it seems that each year this task gets harder. With more complex and abstracted frameworks and APIs, the ways security related bugs are being introduced to a code base has become equally complex and abstracted. Being a few months into 2009, hopefully we can help you catch up on your resolutions by presenting something else to look for when reviewing or writing secure code.

In recent engagements, we have run into a slew of issues focusing around the well-known vulnerability of directory path traversal. As a refresher, this typically involves injecting file path meta-characters into a filename string to reference arbitrary files and usually results in the modification or disclosure of files on the system. For example, a user supplies the filename /../../etc/passwd which is appended to the path /tmp/uploaded_pictures and ends up referencing the password file instead of a file under the intended directory.

We all know, or at least should know, what a typical directory traversal vulnerability and exploit looks like, however, we have recently seen these issues manifest themselves in the handling of user-provided archive files instead of file path strings. Typically, these user provided files are sent via HTTP uploads. Almost all of the common high-level application APIs provide a means, or a third-party library, to handle archive files. Additionally, almost all of these libraries do not check for potential directory path traversal when they perform the extraction of these files. This puts the liability on the developer to check for malicious archives. While file operation calls with a user controlled variable may be obvious, filenames within user-controlled archives may be the vulnerability that slips by. Developers should not only validate user supplied file paths for directory traversal, but also check file paths included in archive files. As a note, this type of vulnerability has been mentioned before and is not groundbreaking by any means, but we want to take a detailed look into what to be aware of as a developer and how to test for this during vulnerability assessments.

To get started lets take a look at an example provided by Sun themselves (!!!) in a technical article for the java.util.zip package. Code Sample 1 from the article provides their base example for extracting an archive and is shown below.

import java.io.*;
import java.util.zip.*; 

public class UnZip { 
  final int BUFFER = 2048;
  public static void main (String argv[]) {
    try { 
      BufferedOutputStream dest = null; 
      FileInputStream fis = new FileInputStream(argv[0]);
      ZipInputStream zis = 
        new ZipInputStream(new BufferedInputStream(fis));
      
      ZipEntry entry; 
      while((entry = zis.getNextEntry()) != null) { 
        System.out.println("Extracting: " +entry);
        int count;
        // write the files to the disk
        byte data[] = new byte[BUFFER];
        FileOutputStream fos = 
          new FileOutputStream(entry.getName());
        dest = new BufferedOutputStream(fos, BUFFER);
        while ((count = zis.read(data, 0, BUFFER)) != -1) {
          dest.write(data, 0, count);
        }
        dest.flush();
        dest.close(); 
      }
      zis.close(); 
    } catch(Exception e) { 
      e.printStackTrace();
    }
  }
}

We can see where the vulnerability manifests itself in processing each entry of the provided ZIP file: FileOutputStream fos = new FileOutputStream(entry.getName()); entry is the current ZIP entry being processed and getName() returns the filename stored in that entry. After retrieving this filename, the uncompressed data is written to its value. We can see that by using directory traversal in the filename a malicious user may be able to make arbitrary writes anywhere on the filesystem. Unfortunately, on most platforms, if an attacker can arbitrarily write files they can most likely also get arbitrary code executed on the affected server.

Similar issues exist with a number of ZIP library implementations across various languages. As one might expect, the equivalent Python code is far less verbose. While Python doesn’t provide any sample code, a simple, and vulnerable, ZIP extraction would look as follows:

from zipfile import ZipFile
import sys

zf = ZipFile(sys.argv[1])
zf.extractall()

The extractall method does what one would expect it to do, except that it does not check for directory traversal in the ZIP entries’ file paths. Python also provides equivalent objects for handling tar archives. Interestingly, the tar archive library documentation does make mention of the risk associated with path traversal within archive files. The documentation for the extractall method states:

Warning: Never extract archives from untrusted sources without prior inspection. It is possible that files are created outside of path, e.g. members that have absolute filenames starting with “/” or filenames with two dots “..”.

How about PHP, surely they provide a function to work with ZIP files (what don’t they have a function for). The PHP manual provides the following example code for extracting ZIP files.

<?php 
  $zip = new ZipArchive;
  $res = $zip->open('test.zip');
  if ($res === TRUE) { 
    echo 'ok'; 
    $zip->extractTo('test');
    $zip->close();
  } else { 
    echo 'failed, code:' . $res; 
  }
?>

Sure enough, this code is also vulnerable to file path manipulation within the archive.

What about everyone’s favorite language du jour, Ruby? Ruby itself does not have ZIP file extraction built in to the language’s core library. However, rubyzip is a popular third-party library and like the prior libraries, is also vulnerable to directory traversal. The example below was stated in a post by the library’s author as how to extract a ZIP file and all of its directories:

require 'rubygems'
require 'zip/zipfilesystem'
require 'fileutils'

OUTDIR = "out"

Zip::ZipFile::open("all.zip") { |zf| 
  zf.each { |e| 
    fpath = File.join(OUTDIR, e.name)
    zf.extract(e, fpath)
    FileUtils.mkdir_p(File.dirname(fpath))
  }
}

Finally, similar to Ruby, the .Net environment does not have ZIP archive handling built in to the core library. A quick googling for “.Net zip files” leads to an article on MSDN. In this article, the authors detail this gap in the .Net library and then go on to present a solution. The tools released include a signed DLL for use during development and a set of command-line utility programs that utilize the library. One of these command-line utilities is Unzip.exe. Sure enough, Unzip.exe is vulnerable to path traversal within an archive. No warning is presented and the archive is extracted without concern to the fully resolved path of the files within the archive.

How do mainstream, standalone, compression utility programs handle this vulnerability? We tested a large number of archive extraction programs (Winzip, Winrar, command line Info-Zip, unzip on Unix, etc) and noted that all of them either provide a warning when a ZIP file entry contains directory traversal, escape the meta-characters, or just ignore the traversed directory path all together.

When writing code that interacts with archives, the same precautions used by mainstream extraction utilities must be performed by the developer. As with any user-controlled input, the directory filenames should be validated before being processed by any file operation. The developer should verify that path traversal characters do not occur in any entries within the archive. Similarly, the developer may also leverage utility functions within their language to first determine the fully resolved path before extracting an entry (ex. os.path.normpath(path) in Python).

A more drastic mitigation, though perhaps the better long-term solution, would involve modifying these default libraries to work similarly to their standalone application counterparts by default. It is extremely rare to require path traversal characters in a legitimate archive. Perhaps, the libraries should be modified to secure the common case, requiring a developer to explicitly request the atypical case. For example, what if the Python ZipFile object changed its default behavior to throw an exception in the presence of file traversal characters? The extractall method signature could be modified as follows:

ZipFile.extractall([path[,members[,pwd[,allow_traverse]]]])

By default the allow_traverse is set to False, throwing zipfile.BadZipfile if path traversal characters are encountered. This would provide a secure by default configuration for the library while still allowing the existing behavior if necessary. This requires the developer to explicitly request support for path traversal, thus mitigating accidental and insecure usage. This is unlikely to impact existing code, as archives with path traversal characters are not easy to create and it is extremely unlikely a legitimate archive would accidentally include such characters.

During the course of this write-up we grew tired of hand-editing zip archives in a hex-editor to add directory traversal characters. So, we put together a Python script that can be used to generate ZIP archives with path traversal sequences automatically inserted. It can create directories in both Unix and Windows environments for ZIP files (including jar) and tar files with and without compression (gzip or bzip2). You can specify an arbitrary number of directories to traverse and an additional path to append (think var/www or Windows\System32).

The full usage follows:

Usage: evilarc <input file>

Create archive containing a file with directory traversal

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -f OUT, --output-file=OUT
                        File to output archive to.  Archive type is based off
                        of file extension.  Supported extensions are zip, jar,
                        tar, tar.bz2, tar.gz, and tgz.  Defaults to evil.zip.
  -d DEPTH, --depth=DEPTH
                        Number directories to traverse. Defaults to 8.
  -o PLATFORM, --os=PLATFORM
                        OS platform for archive (win|unix). Defaults to win.
  -p PATH, --path=PATH  Path to include in filename after traversal.  Ex:
                        WINDOWS\System32\

$ ./evilarc.py test.txt -p Windows\\System32\\ 
Creating evil.zip containing ..\..\..\..\..\..\..\..\Windows\System32\test.txt  
$ java javaunzip evil.zip
Extracting: ..\..\..\..\..\..\..\..\Windows\System32\test.txt
$ ls -al /cygdrive/c/Windows/System32/test.txt
-rwxr-x---+ 1 gose mkgroup-l-d 21 Feb 24 11:52 /cygdrive/c/Windows/System32/test.txt

This script available for download on GitHub.

phpMyAdmin Static Code Injection

2009-03-24T00:00:00+00:00

Originally posted on labs.neohapsis.com

During an evaluation of tools for internal use, we took a look at phpMyAdmin. During the assessment, we identified that the scripts/setup.php script is used to generate a configuration file to config/config.inc.php. Anytime PHP code is being generated, extremely careful filtering must be done to ensure that the intended output cannot be escaped and will not allow the injection of arbitrary code.

While the most obvious inputs, those set by the configuration fields, were escaped properly, other attacker accessible data was not. The script passes PHP serialized data back and forth through the configuration parameter. When a save action is performed, this data is then written as PHP variables to the configuration file. The data contains associative arrays with key and value pairs. On output, the values are properly escaped using add_slashes, however the keys that are also output are not filtered. By modifying the array keys in the serialized data passed to a save POST request, the key name can be escaped and arbitrary PHP code injected. If config/ is writable by the web server user, the config.inc.php file is written to it and can be executed directly out of the document root.

The issue was disclosed to the phpMyAdmin team and they did an amazing job responding to this disclosure with a patch out in less than 24 hours!

Lessons learned? Anytime you are programmatically generating code (be it HTML, JavaScript, PHP, etc.) ensure that your output is properly filtered and make sure all installation scripts and unneeded administration tools are removed.

More Info

SALIVATE Project

2006-01-01T00:00:00+00:00

SALIVATE: A Secure Architecture for Loading, Initializing, and Verifying A Trusted Environment is research completed at Purdue’s CERIAS detailing the architecture and development of a secure boot sequence to identify and restore a compromised system upon boot.

More Info

CiteSeerX Document

nullmethod

Jekyll Arbitrary File Write

More Info

GitHub Vulnerability Responsible Disclosure

More Info

PGP Universal Server Private Key Disclosure

More Info

Direct object reference in Punchd

More Info

Disabling WPS on Wireless APs via Firmware Modification

Download and install the Firmware Modification Kit

Download your router’s firmware image

Slice and dice the image and extract the rootfs

Remove WPS related binaries

Rebuild the firmware image

Flash the new firmware image

Results

Aruba WAP OS Command Injection

More Info

Exploiting USB Devices with Arduino

Abstract

Artifacts

CSRF File Uploads in Firefox 4

Stored XSS in Chrome Web Store

More Info

Web Application Scanners - Evaluating Past the Base Case

Artifacts

Scanning Reality - Limits of Automated Vulnerability Scanners

Abstract

More Info

Forensic Fail

Artifacts

So Long, and Thanks For All the Clock Cycles

Artifacts

Directory Traversal in Archives

phpMyAdmin Static Code Injection

More Info

SALIVATE Project

More Info