Category: Blog

This is not a discussion about detecting if a TorHS website has WordPress installed, but rather about tricking attackers that scan your website into moving along, nothing interesting here.

For starters, if you are running multiple onion websites on a single webserver (and my recommendation is that you do not do this, use one website per webserver), you will need to make sure that your server is not vulnerable to an attack where it is possible for an attacker to enumerate all the onion sites running on your server.

So don’t be lazy, set your Virtualhost containers ServerName correctly!

That said (and is the point of this little blog piece), even if you have correctly configure this, WordPress has recently added a function that adds an extra ‘dns-prefetch’ into the page code which is in of itself, not interesting other than it could cause your onion site to be short-listed for further attention by attackers scanning for virtualhost mis-configurations because this new addition to WordPress can trigger a false positive.

For example if an attacker were to trace:

$ curl -H "Host: abcdefghijklm.onion" --socks5-hostname 127.0.0.1:9050 -s --user-agent "Mozilla/5.0" abcdefghijklm.onion | sha1sum

(note: even though sha1sum is vulnerable to collision attacks, we use it here merely for illustration purposes – i.e its a short hash)

This returns:
5f18492f012c9e1d0df76c47d4a7b75c703ae6c3 -

Same trace instead using localhost as the hostname:
$ curl -H "Host: localhost" --socks5-hostname 127.0.0.1:9050 -s --user-agent "Mozilla/5.0" abcdefghijklm.onion | sha1sum

Returns:
4d0389cf2c7e362fa5b3d920c8c6c394f5d0d021 -

This is because WordPress adds an extra:

< link rel='dns-prefetch' href='//abcdefghijklm.onion /' >

…when the trace hostname is localhost.

To prevent this, go to:
wp-content/themes/[current-theme]_child/functions.php

add:
remove_action('wp_head', 'wp_resource_hints', 2);

Now trace:

$ curl -H "Host: localhost" --socks5-hostname 127.0.0.1:9050 -s --user-agent "Mozilla/5.0" abcdefghijklm.onion | sha1sum
5f18492f012c9e1d0df76c47d4a7b75c703ae6c3 -

And:

$ curl -H "Host: abcdefghijklm.onion" --socks5-hostname 127.0.0.1:9050 -s --user-agent "Mozilla/5.0" abcdefghijklm.onion | sha1sum
5f18492f012c9e1d0df76c47d4a7b75c703ae6c3 -

Hashes match! Your site is not interesting, attacker moves along…

Mauriora!

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hardware Security:

• Hard drives are encrypted with unique pass phrases
• Servers protected by pfSense hardware firewalls

Operating Systems:

• Client OS: TAILS
• TAILS USBs are destroyed regularly with a grinder and ‘soaked’

Communications Security:

• All client contacts via encrypted and anomymous platforms ( see https://taipo.github.io/contact/ )

Information Security:

• Pass phrases are spread out over multiple e2e encrypted remotely stored password DB’s
• No sensitive information is stored on any inhouse devices
• Personal data is stored on an airgapped offline computer
• Hokioi Security Canary Statement

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJX+LBOAAoJEL7YCbL0gxCT5l0QAItbMw3iF11MWSms4VfsNm4k
UMuEtmIrNpxcx17czB3hYL0GEhM56L+BBUnZVkeowGbLqRdSqokkb3Hf/I7KhajZ
FVGLbgClriAjHeJfvNeCpsvJdRhHU+QIz3Mia0GtTOuVgUZnlcUylQSZKQICY4Th
yy2FfSVMnnxRt2a4WYxFM5RtEYj4+YnIerR6VNgwKAyouaaM7avW5+LeYIVda/Jb
QfRar/3050uIYxZMRBDkSBaCVvRLpEMQBFIkOU9LRr/ghvRkK+4YuwUXCn+Sk1wS
wsw2qCCjz36dgMBGN+co6q7UxhqfLqyrvcj81mPgV8rzZ70DVGiieKUO1s7ma/UU
2EFGxktJyG8ww/OtZHgYUzP6y2oxQL7XVqcBxbuMxjw55R9E2F8XpSxdlmPnYAEu
DwPDjQvYCXv4edINrGu/M6fuunLsTh33EBCg6qkC+YSXWxlLChViJhpGwiJbHX2k
QBZ1kE9De5XUGBa8H2gSsQUnDJL9N8PIFBChGLaikgGl7ZGkm9r/doK1pmSDS+Uv
sLJVQOL85Hu+DsaXbyXlJ5FJB5fNYXXw/L6etncrNPXGj6t6sTN2bn6mfXOU7u00
sUFE9lH5eANvwbrMZXEaHHQSwl4Pg1NERKsFj4aaeNPfurRFoY9qWggfdEPZNtsE
LIQ6pGoWl1ZezjT+Uixb
=mVpt
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

What is Jackhammer 1.2?

Jackhammer 1.2 ( sometimes called Jackhammer 2.0 ) was developed in 2003 by Mike Parniak ( Archon ) from TheBlackHand / Cafe Counterintelligence in response to CCISecurity script he released that blocked attacks from Jackhammer 1.0

Jackhammer is a MS Windows only, layer 7 attack application that also allows attackers to use multiple anonymous proxies to distribute the perceived point of origin of an attack across as many proxies as an attacker desires or is able to use, therefore masking the originating IP address of the attacker.

Attackers are able to choose from a number of attack strategies allowing them to tweak the exact type of attack that Jackhammer performs as well as optimising the overall data transfer, i.e 10,000 proxies x 0.1 ms = 1 request per 1000 seconds per proxy.

While Jackhammer is an old application, it’s attack method is still very relevant today as it was in 2003. With the advent of flood protection services such as Cloudflare, Jackhammer attacks are easily thwarted, but without employing such services, webservers are still quite vulnerable to the attacks that can be delivered via Jackhammer.

Jackhammer 1.2 Connection Strategies:

* Disconnect after Response Code: On this setting, Jackhammer only reads the first 12 bytes of the webserver’s response, in order to get it’s HTTP response code. This is mostly used in conjunction with the “Disable proxies on Bad Response Code” option. It lets Jackhammer detect if a proxy has been banned (403 code) or similar, and thus disable now-useless proxies during a flood.
* Disconnect on any data received: As soon as data is received from the proxy server, indicating a response to Jackhammer’s request, Jackhammer destroys the socket to avoid further data (minimizing received data, but ensuring that the proxy is responding).
* Hold connection until disconnected: This setting has Jackhammer sit on the socket and not disconnect it. Only if Jackhammer needs to create a new socket and is maxed out, or if the remote host disconnects it, will Jackhammer destroy a socket. This setting is often best used in conjunction with a slow speed to run a webserver out of connections.
* Disconnect after data sent: A low-bandwidth lifesaver. This option causes Jackhammer to disconnect immediately after successfully sending all the header data to the proxy. Tests have shown that the proxy will still deliver the request to the target server before disconnecting. This means it is a good option to use against scripts, but a poor option against large files.
* Incremental List Segments: If an attacker has a large list of proxies, and are worried that the website they are flooding may ban the proxies they use as they’re flooding… attackers can have it only use pieces of the proxy list at a time.
* Get and use initial cookies: One of the other powerful options on Jackhammer is the ability to get and store the cookies that websites return, and pass them along on future connections. If an attacker enables this option then the first time each proxy performs a request, Jackhammer waits for the full response header and records all the cookies. From this point on, it adds a cookie: line with those cookies to all requests from that proxy.
* Get, use, and keep cookies updated: This option only works if the attacker also has the above option enabled. Instead of just waiting for the first set of cookies, Jackhammer will always read the full header and update the cookies accordingly.

An attacker can use these combinations of attacks to simulate expected traffic but at such a scale as to cause a denial of service condition, and in some cases, with little bandwidth consumption.

Example Low Bandwidth GET Request Attack:
For example where a CMS creates and database stores guest cookie sessions in this manner:

$guesthash = sha1( $_SERVER[ 'HTTP_USER_AGENT' ] . $ip );

Attack Method: Disconnect after data sent

GET http://attackvictim.com/?%%ALPHANUM[4,10]%%=%%ALPHANUM[4,10]%% HTTP/1.1
Accept: */*
Host: %%HOST%%
User-Agent: Mozilla/4.0 %%ALPHANUM[4,10]%%
X-Forwarded-For: %%IP%%

Then the above attack request method would quickly fill a database with junk guest sessions and in many cases overwhelming the database with very little data sent due to the ability to customise the user-agent with every request.

Add to that the ridiculously shitty way for example in which vBulletin determines the real IP address of a visitor in its fetch_alt_ip() function ( includes/class_core.php ), it is even possible to spoof the IP address with every request as well.

Resource Intensive Request Attacks:

Because Jackhammer allows for custom HTTP header requests, an attacker will often look for the most CPU/memory intensive, and/or bandwidth intensive request as their choice of attack.

POST Requests: these are cpu intensive and the favourite of attackers. Unprotected forms are the usual target and a flood attack of even a few requests per second can overwhelm a webserver.

Especially forms that result in an email, or emails being sent, can also result in both a servers resources being overwhelmed as well as a bandwidth attack as mass amounts of emails are generated from each POST request.

However there are other POST requests that can overwhelm a server even without a waiting form.

For example versions of PHP earlier than 5.4 were very susceptible to blind post request attacks where the post data generates a large multidimensional array:

i[]=1&i[]=2&i[]=3&i[]=4....i[]=1000

GET Requests: often targeted at site features like search functions where a search request results in a database intensive request which repeated in quick succession can quickly overwhelm a database server resources.

Example GET request of a search function using wild cards:

GET http://attackvictim.com/?search=a*&%%ALPHANUM[4,10]%%=%%ALPHANUM[4,10]%% HTTP/1.1
Accept: */*
Host: %%HOST%%
User-Agent: Mozilla/5.0
Client-IP: %%IP%%

GET request attacks targeting large files can also result in a bandwidth attack sufficient enough to cause a denial of service request condition.

Mitigation:

How to mitigate Jackhammer type attacks ( in this example using PHP and optionally javascript ) without ceding to the likes of Cloudflare, or other captcha services/methods:

One approach to mitigate an attack from tools like Jackhammer is to enumerate the ways in which these tools fail to emulate a standard browser as a means of detecting them as the source of an HTTP request.

Most layer 7 HTTP request attack tools cannot interpret javascript so therefore it is possible then for a server to ask a complex javascript initiated question that a standard browser with javascript enabled would be able to answer.

For example you could write a piece of javascript to set a session which a standard web browser would have no trouble completing but an attack tool like Jackhammer could not.

Javascript though for some web admins is not preferable.

The usual method is to set a session based IP management to count requests per a period of time and restrict IP addresses that break these rules.

A Jackhammer attack is often mistaken as a botnet attack because Jackhammer allows an attacker to deploy multiple proxies.

An attacker with a very large proxy list can deliver a sizeable attack even against rate-limiting algorithms because of the time it would take for Jackhammer to toggle through a very large list.

The time between the first and second request from a specific proxy IP address of an attacker employing say 10,000 anonymous proxies could be 5 minutes.

Combined with javascript as noted above, will very likely prevent an attack from proceeding.

Lastly it is important to prevent direct access to large files on a server, and it is preferred to pipe a file via session based access which are subject to the same browser emulation requirements stated above.

Download Jackhammer 1.2 for testing purposes only: https://mega.nz/#!fII2BKpZ
Decryption key: !CEFrXPHEbzFD2XdxIbpRRdhJjCHd1AifiCc256LwB3I
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJX+K8+AAoJEL7YCbL0gxCTWL8P/3p3ElE9GWK+V2qQ5g0tr6Hf
aDqckNs2mKDcDJuBMnyfH//xeDSQJSAPmlwmV/1NINrvNSJsxb9kuIm8Z44arThB
wduEilbzeQZkbeVIoXT5n/XiT9PbVo5hsdaMmjCYtOtDQZ2xXcwiYUXVdhdjSxOa
GQdt9d9s/BwJem8T4QXAY594PxGMynGi2zpFWqEkxsaM5c9RN3loFpNpsQkoPHha
uAEIYfN7zoAafPzRZ6qdI1oXoaJWFpyQbEZjXBRvWyonJMzuWCs3zWA+3sQXNz9o
XbJTqmYmq2wqmdZK1ruGEJaourUatMTz1zOx+bkxzvLITeVJ/0xftLcIX5H2YDx9
poavS7cS7neFXTBrc1X0aisK5chA/glz9zQZ4qsHJmQirfCOJqN0UgilKNi34Ntu
Nts6e90JglKN40+6qqcp0/vDXkBsc3KqG1Rl42Fw9XOpciBJHmbNKg/dRvR+01dp
YqO+l6TEH2IVHBZfAjvxagjOSZhbP5ctu6kj2R1BYvLmdo4NHGyQwFKWjj9D8rOX
RGCkkoBOctpRx2FblyrPvqeG2MEzvbHJZ+mMnbl4aKAhzRuVDyXxbv8p8lP0UzSz
PepGmLXW5kV02uo6Jzw73kYr7IPo3AErr3kpcsmhcFHJPqU9NZqCqqoXfkE+h48g
2T+GwXOKAu98Z8u+AZ1T
=0wyT
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

If you are a journalist organisation with a central office situated in a country that respects the role of journalists, then you may quite comfortably run a SecureDrop or Globaleaks server within the offices of your organisation and depend on journalistic privilege preventing governments from entering your offices and walking out with your secure dead drop servers, or forcing you to hand over ( in the case of SecureDrop where encrypting with a journalists GPG key is left up to the source ) the applications GPG key, or placing gag orders on you.

Be careful though, many states will selectively respect the rights of journalists depending on the size and power of the news network. For example even in Aotearoa New Zealand, the police have little qualms raiding the houses of independent journalists such was the case with investigative journalist Nicky Hager in 2014.

If your threat model means that keeping the location of your dead drop secret is also critical, then you should consider taking additional steps to protect your tor hidden service IP and therefore location from being discovered.

Hosting a secure dead drop:
Never run your SecureDrop or Globaleaks server on a VPS or any other form of remote hosting. There have been too many instances of virtual server vulnerabilities as well as malicious VPS providers. The most secure option is dedicated hardware in a secure premises.

Also avoid single point of failure services like load balancing methods which attempt to cloud host SecureDrop or Globaleaks servers. That also goes for applications that remote host the private keys. Avoid these.

Prevent guard node attacks:
There are a few types of attacks that target the relays which your SecureDrop or Globaleaks servers connects to. Their purpose is to deanonymise your server, and can also be used to attempt to identify who is connecting to your service.

To mitigate this attack you will have to consider running your own anonymous relays as dedicated entry nodes for your SecureDrop or Globaleaks server.

When these are safely configured, your SecureDrop or Globaleaks servers can then be set to now select its entry guard node only from those stipulated in the torrc file, and if these relays come under attack, your dead drop will just become unavailable rather than shift to relays that could potentially be under the control of an attacker.

Do not draw attention to your Tor Hidden Service:
Make sure the IP address of a Tor Hidden Service does not act in a way dissimilar to a standard user of Tor, the attacker will not be able to easily determine that there is a Tor Hidden Service running ( i.e do not run any other service on the IP of your Tor Hidden Service as these may draw attention to your specific IP address ).

It is also good practice however to run your SecureDrop or Globaleaks server on a separate internet connection than your organisations own corporate network connection.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJX+K43AAoJEL7YCbL0gxCT6EgP/jbMphGL1ExxNFRlx8ZZvBzm
XK290/zrbMAlgK2oI5yPlXyhra1k4rKiDfLlBmU2hSkoaXUXjLGEV9nONkwJUh+m
ElIvu6kHS4OlL2yk2pilee7aUa0kYHw4QBRPgsMXmOnQ3jdddYbSnAN0ipu7Icys
gAwYJ7QDVvbjqiI5y1OTvex2QHZLM6ngvkXjDhUwDXCESzMeffLtSMKkX/oCcOma
1XcChkEOxA4lvHDlux3WZN43zlCOUFoKbeIf03QXlfq23urcjj3Nc8bykCWU1aD2
iBAi8NGKhapmpUE90A5A4Rb3AAtkLxCm3E2C+0EZvm0D69NY2ATDT/fP+z7weywy
nPNLB1EWrM+g98OauN72lSK5HvPjFRaVSJNIyXcgkApor+uxMmb6zc83Jmy9UCSx
nPr2b9dPjcxVMWV7lD6Y2hEe5rhIYgkh3SU0+eUQUsIaVlcuT8PA4/kdzzAJNwY7
0WuJ3BfIyU5GpyIyIN51iaj7S+CIlFkMvhIIVQEMn4BMDBgwqt0gTIsVMsD2AeGs
R+AlNk94jUEnMVUrCx/Ifn5xQ2dGHNVcu/eDZ1PYJLmYP0hn9BiF0Lc4t7XQ8Uib
LXWNZfr0xs+b8I/v6hoC8ZZRFrHaTCRB2nOyUcAWHvwEbXHjZi8QK4+y9OmTBYBH
klvq+A3G5ex/FbGDlafk
=k0ZQ
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

To begin, first read @yawnbox’s excellent piece on this.

Choosing which secure source submission platform is right for you. I want to add some additional thoughts on the differences ( while hopefully not regurgitating too much of what has already been covered by @yawnbox )

SecureDrop

SecureDrop in my opinion is designed and best suited with medium to large sized news media organisations in mind. If you are an established news media organisation and are seeking the most secure anonymous platform to manage newsroom sources, then you should look at deploying a SecureDrop platform.

SecureDrop requires the greater investment in equipment to meet its minimum requirements, and experienced Linux administrators to maintain and operate.

With SecureDrop, the administrator must be in-house.

SecureDrop does not require the source to have a javascript enabled TorBrowser in order to interact with the server and upload documents.

SecureDrop does offer the source the option to manually pre-encrypt files with the journalists PGP keys before uploading, without this though, a file is still encrypted with the applications own dedicated PGP key. This means person/persons with the pass phrase of the application’s PGP key can decrypt uploaded files.

SecureDrop’s technical strength is it’s NSA level hardened threat model reducing the threat surface to the bare minimum. The security practices stipulated in the SecureDrop Wiki documentation should be used by all journalists when handling secure information.

However at a certain level it also depends on a country’s ruling government to respect the right of journalists. For example a government who does not respect these rights could force the administrators to hand over the application’s PGP keys thus being able to decrypt any files still resident on the SecureDrop or future submissions if the organisation is forced to continue running the SecureDrop under duress.

Globaleaks

Globaleaks was designed to scale from a single journalist/receiver through to as many journalists/receivers as your server can handle, using the least amount of equipment -> a single webserver ( and an optional additional hardware firewall – my professional recommendation ).

Globaleaks requires the source to have a javascript enabled TorBrowser.

A Globaleaks administrator does not have to be in-house in order to configure administrative settings.

A Globaleaks source files are first temporarily pre-encrypted with a symmetric AES key before being encrypted with the journalists own PGP key ( recommended deployment method ). Therefore at no time are the files stored on the server in unencrypted form. This also means only *that* specified journalist can decrypt files sent to them.

An encrypted email notification can be configured to be sent to the corresponding journalist/receiver when a submission is made.

Globaleaks server can be more securely deployed in a country/region that has no respect for journalist privilege, or used for non-journalist related deployments using standard compartmentalisation methods. If the server location is compromised, a state actor cannot get access to encrypted files. Getting access to source content files is only possible if they de-anonymise the journalists/receivers, AND get access to their PGP private key pass phrase, in which case only the files of the individual journalists/receivers that are still resident on the server will be compromised, rather than all files.

Common to Both

Both platforms deploy on the Tor network to provide a layer of anonymity and end to end encryption as well as some protection of the location of the secure dead drop systems.

Both allow for multiple receivers/journalists.

Like any webserver system, they need an administrator to keep the physical equipment’s OS and applications up to date.

Both Globaleaks and SecureDrop can be deployed into an already compromised network, as is the case with many established news organisations, this is due to the use of the SecureDrop recommended pFSense hardware firewall being used with either choice.

Drawbacks

Many journalists still struggle with basic encryption issues. Using TAILS correctly and with persistence configured correctly, takes time to learn, and get used to if you do not use it regularly. PGP crypto is difficult to get right and clunky to use.

SecureDrop

So as is the case with some deployments of SecureDrop, often the administrators or an onsite security specialist is employed to take on the role of “file decrypter” rather than the journalists doing this function. Once decrypted, files are analysed then encrypted by this person with the PGP keys of the nominated journalist before forwarding to them.

Globaleaks

Globaleaks documented security requirements for journalists/receivers is low. Therefore I encourage journalists/receivers to use the same standards required by SecureDrop journalists/receivers. In security best practices they would only ever access the Globaleaks journalists/receivers login area via a dedicated TAILS laptop and decrypt files via a dedicated airgapped ( never used on the internet or networked ) TAILS laptop.

Globaleaks also demands sources enable javascript in their TorBrowser’s. This can be off-putting for the more security minded sources. Also some browsers like Orfox do not have the ability to enable javascript so are therefore blocked from interacting with a Globaleaks server.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJX+K10AAoJEL7YCbL0gxCTtLoQAMWlWO7ZFhjwxIBxryvXS+A9
0W9EkOReT8kyT+3FP566so/3E9fGM/jZDH78XQH6sYaGeJzONGnTVKMxcJtu4y3D
efZK2Jna4Fau9MorHQPmWxT11SrC9pSoeUlakhD3r71A54j+NtTU8F/2U/6ZQDKd
4qvhK3RHS/rfMn5wtWfhgdLD5THiEoGe5Qqu7uJh70J4Dc4UAjqVtbZGDf4ZylAD
ufRztLZ7YKfBj34E0cuySn9jxUBq2Lp7qIqQbrhGS0c/Atp5NHwjJl8XOm/6ZBSC
ErvGwcies6/7MFAr9PPX0UCNgbIjKgzhPzc8LxpzAR0j7MhkVWFQLCHOunKQ/b0Y
hKdJtc6Yje0fPQgKD7yiOlrp3YFePC37qPtC+EUEniAPf/qBPcWi1tnKPA8xnyHI
rIZvntqd0UY7YfhZmsJxaNk1AWbI1feNrarO9vSHfWwL9EVv6HYXbX8j/ZHuophy
m2tq81w7UUQxpbCwx4aEaSPHK1qVTkFXouzDWZ7UPBmVtt1lBbg5LBW7h4mG8z/y
ck5aGrCUjlmyevgeLk97mMeU7jwBjsii6Ai+VE2R/ZwQBv5gnkFq0DVAv91YB0Sq
HasCh4Ty0TRfcyZVtW9ux6DWSxQ7V2p0zZE6GnZpIMT1ZGJGQxz0rLo3UVGhXcZO
8JY9c3UqwcEf6eDls0Jl
=bXa6
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

What I want to discuss here is the attack on the WhaleOil communications network which resulted in a large cache of emails and attachments becoming the centrepiece of Nicky Hager’s book Dirty Politics.

I hope that you the readers, bloggers and users of online services will learn from the mistakes Cameron Slater made, and harden your web applications to minimise the chances of this happening to you.

I will also try to keep this as non-techie and non-geeky as possible …

[ full story on Putatara.net ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJX+Ku5AAoJEL7YCbL0gxCTIuEP/1CwfifqBNjua0rzu7fvcri/
ExdKCkxZeFR2KzaliMH6zxWEfwGzkXynU/CkHcOk6ly1K07qho5YHiTkYG8D6kJe
Kh82m6QwyLAJuui20zpVdBP0xIqTDNDm0V10rpndE9ZDguhfJyedD5SAsYqAmasv
K0LGo1ffudQqP8cmU6vjL2zsCAcRUplIb+3TXOCbZgO5g2ZBlB93eexr1utiKBRM
tMBsl/yeEI/4n9gI7ZSN1dR5FAYqbVOhebrPYm1VDF7qN0x2PuxI6r5Els0tAqI2
XMWGtTTWBbWhvoSYOoZKKbH/9syIAc78cQVLE99XmLGU0FEyydcqH48epvvaNYaT
MfTG86S6jKVkU1kfwUGU2ZEL6JKWMQPLJaV8T8RtKXrxe6DlEYTH8ULZKSk/8FI8
ADaO2nZyJdV5dCQqvCiO8Ky8OUvRVWX4Zl7K5moDyCfSklTBM3hS9rdrFrZ+sX+1
8lYnR8V2VZno5oD1wn6925158bPv+UVjnP89IdfLceKxQGbbo83nJtr7fhysCTGs
Hd0mWkw9ArMfrb0dkElrVdeMkPs/+HzoJBv5aiBLOjcbjUPG98dvXxkbWHhVy1B/
VKps8NA0HKcWNM+QNG5gene0sJpbkqwL0f8hE8fEUnNbk5gSjCe0z1MIsubVqNxt
6hFxVTtNf2Hcs/lBJX8p
=AKRy
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Your number one priority in sharing truth is to preserve your anonymity. Highly secure platforms for secure disclosure of information like SecureDrop and GlobaLeaks go as far as technically possible to protect your identity and to protect the transfer and dissemination of your information to the world.

However you need to take the right countermeasures to protect yourself long before you arrive at the point of sending information.

These mandatory considerations can be grouped in three categories: Social Risks, Social Responsibilities, Technological Risks

Social Risks

After a piece information has been liberated, and when the news about the facts related to the info you submitted reaches public media attention, yo uneed to understand the process that will take place around you. You need to have a clear understanding of how submitted information can be a risk to you even if your identity is protected.

• Who else knows you has access to, or knows you have access to this information
• Are ready to cope with all the “stress” of an internal or external investigation?

Social Responsibilities

After a piece information has been liberated, pressure will come on all who could have potentially disclosed the confidential information.

• Will your anonymous disclosing bring undue persecution on others who will fall under heavy scrutiny along with yourself?
• Will your anonymous disclosing cause further persecution on victims that would rather remain anonymous?

You should consider submitting to a SecureDrop or GlobaLeaks platform only after a full understanding these points.

Technological Risks

You must be aware of the fact that while using a computer and the internet to exchange information, most of the actions you do leave traces (computer logs) that could lead an investigator to identify where you are and who you are.

You may leave computer traces while:

• Researching the information to be submitted
• Acquiring the information to be submitted
• Reading even this web page
• Submitting the information to us
• Exchanging data with receivers of your submission

All these actions may leave traces that compromise your security, but with a few technological protection steps, you can minimise the risks.

Social Protection

• Don’t ever tell your intention to anyone before you make a submission
• Don’t ever tell your intention to anyone after you make a submission
• Don’t ever tell your intention to anyone after the news about the submission gets out to public media
• Be sure that there’s no surveillance systems ( cameras or other ) in the place where you acquire and submit the information
• Don’t look around on search engines or news media website for the information you submitted ( this would reveal that you knew about it earlier )

Technological Protection

To achieve a 100% guarantee of security from technical perspective, you need to be computer-proficient enough to fully understand all the risks.

However, by strictly following the procedures and tips reported below, you should be safe enough:

• Submit information using Anonymous Web Browsing software Tor Browser Bundle
• Don’t submit information from the personal computer provided to you by your employer
• Keep the Submission’s Receipt ( GlobaLeaks ) or Diceware Phrase ( SecureDrop ) safe, and destroy this information after you don’t need it anymore
• Don’t keep a copy of the information you submitted!
• While acquiring the information to be submitted, be sure that there’s no traces being left leading back to your identity ( eg: store files using Veracrypt within your USB key, and when the submission process is completed, grind the USB key down to powder using a file or hand grinder )
• Be aware of the fact that “meta data information” may be present in some of the data you are submitting.
• Consider cleaning up the Metadata by using tools such as ExifTool, Exiv2, Exif Jpeg header manipulation tool, and/or MAT bundled with the TAILS linux live CD.
• Consider converting all the data that you are sending us into standard PDF format.

By applying the above described procedures, you will be safe enough.

Safe enough doesn’t means 100% safe.

To overall improve your digital security you should undergo reading of the Security-in-a-Box project, which explains most of the risks and related countermeasures.

Security of the Hokioi Security Secure Submission Platform

Hokioi Security Secure Submission Platform is implemented using the GlobaLeaks Software, and anonymity for the confidential source is provided thanks to Tor software.

Tor is the state-of-the-art when it comes to digitally protect anonymity and has received a lot of attention from both the academic research community and experts in the IT security field.

GlobaLeaks is the first opensource, secure and anonymous confidential source platform designed by the Hermes Center for Transparency and Digital Human Rights.

Tor is already integrated in GlobaLeaks; that way, the Site Owner does not obtain any kind of traces or information about the Confidential Source’s identity or location.

Complete security can never be guaranteed; however, we have designed this technology taking into account scenarios where a confidential source’s life and liberty may be at stake.

Having read all that, the Tor accessible website address of the Hokioi Security Secure Submission Platform is:

https://aotearoaleaks.org/

Other Secure Submission Platforms of note:

• https://www.newyorker.com/svc/module/strongbox ( http://strngbxhwyuu37a3.onion )
• https://www.safesource.org.nz/ ( http://vtjkwwcq5osuo6uq.onion ) Offline!
• https://specialprojectsdesk.com/secure-drop ( http://gmg7jl25ony5g7ws.onion )
• https://www.theguardian.com/securedrop/ ( http://33y6fjyhs3phzfjj.onion )
• https://firstlook.org/theintercept/securedrop/ ( http://intrcept32ncblef.onion )
• https://www.washingtonpost.com/securedrop/ ( https://jcw5q6uyjioupxcc.onion )
• https://www.securileaks.org
• https://wildleaks.org ( http://ppdz5djzpo3w5k2z.onion )

~~~~~~~~~~~~~~~~~~~~~//~~~~~~~~~~~~~~~~~~~~~~~~~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJX+KrEAAoJEL7YCbL0gxCTjmsP/j3HSL0CWa4l7VK5pExKSWEq
5H+O39dUUjcrLIDsdYlA1RcBhZlDU05tebx61ibh2yAF0PfF7ulW/16KhlCPBPAb
pytdQYZz6/wwkWC6OWtDGu0HpWjWj/vOv6oU2jUmoTjwI073sAsGeJasOTT7mFGK
dXciW4LVzmhFm0t6RFAHpnnQmb0SO2i0ZBADejgcuoApwj70/W2SO9yIoj1ZHf4E
a4mLRJszHvwOl0V25ho5odJXd0h7BFWJO6uN/0WXaEZWffJ14QRM0z4qArHu3RrR
7WH0YKUb6rC2ltvD/HjNQfHziRGQm1nMiIkfAPo1Tfjh+7Zs3K3RRW/TjlJ7fLWF
6cn0CkDK8ZGyyx50L5NPOLluBUJpRjDPPqBlLLGuDpfoS8y1mHUABd3+hpuZPVxJ
L72xcNHACIVt7/KNi91AL/b3cUTuKZxFF5LxEdDppsjcag3llKGPhf5zNPYSyQ+Y
gydrwTmkCUg42VfhLQVGL6sLxY7egHp8LUdPFyYjtTjC340/pCfImg+5PaEhowhH
e4C7/Arb2JVeW5+ugvVCbz/BTGnCmij0rMovmdR0K81lfUCPTB//xPecYjvXGysk
Lrm9wx5M/oOmj1u7kF8MKpdHf+GiAb7mtfR5p/tHRYA7ZIx6eTLO/n0IYyVM5ase
uL0lcy0bYIIQOnbfnuYH
=SRok
-----END PGP SIGNATURE-----