Jekyll2021-01-09T20:35:34+00:00https://www.ticarpi.com/feed.xmlticarpiHacking, pentesting, research and code...ticarpiJWT Tool Attack Methods2017-07-05T00:00:00+00:002017-07-05T00:00:00+00:00https://www.ticarpi.com/jwt-tool-attack-methods<p>So, having introduced my JWT auditing tool (<a href="https://github.com/ticarpi/jwt_tool">https://github.com/ticarpi/jwt_tool</a>) in the <a href="https://www.ticarpi.com/introducing-jwt-tool/">last post</a> I thought it would be good to provide a quick run-down of the various attack methods you should try as a pentester when faced with JWT auth on an engagement. </p>
<h2 id="token-generation">Token Generation</h2>
<p>As with any web app pentest you should check the authentication process in place - as an injection here or bit of parameter tampering there could get you a privileged account without the need to mess with the tokens.</p>
<h2 id="token-transmission">Token Transmission</h2>
<p>Once the token is generated on the server it will be transferred to the client. This may be via a set-cookie Header, or in the response body.<br />
Either way, make sure that this token is sent securely, using TLS encryption.</p>
<p>Bear in mind that in many cases a JWT is all that is needed to authenticate back to the server, so should be treated with all the same security considerations as a SESS_ID token.</p>
<p>If this is being sent as a cookie then make sure it is set to <strong><em>Secure</em></strong> and <strong><em>HTTP-Only</em></strong>.</p>
<h2 id="token-vulnerabilities">Token Vulnerabilities</h2>
<p>A number of vulnerabilities can befall a JSON Web Token, so check these methodically.</p>
<h3 id="test-for-the-algnone-vulnerability">Test for the <em>alg:None</em> vulnerability</h3>
<p>This issue in unpatched JWT libraries will allow the algorithm in the JWT header to be changed from the current encryption scheme (<em>HS256</em>, <em>RS512</em> etc.) to using no signature.</p>
<p>If vulnerable an attacker can simply tweak the header, and then change anything they wish to in the Claims section, and the server will accept it.<br />
(This is the attack seen in <a href="https://pentesterlab.com/exercises/jwt">Pentesterlab’s JWT exercise</a>)</p>
<h3 id="test-for-the-rshs256-public-key-mismatch-vulnerability">Test for the RS/HS256 Public Key Mismatch vulnerability</h3>
<p>This vulnerability in tokens signed with an RSA Private Key occurs when the server does not enforce the specified algorithm, and allows the token to specify this.</p>
<p>If vulnerable the attacker can change the algorithm in the Header to HS256, and sign the token using the RSA Public Key (assuming they can locate it) via the HMAC-SHA256 algorithm. They can tweak anything in the Claims section before signing and the server will happily accept it as authentic.<br />
(This is the attack seen in <a href="https://pentesterlab.com/exercises/jwt_ii">Pentesterlab’s JWT_II exercise</a>)</p>
<h3 id="test-for-weak-passwords">Test for weak passwords</h3>
<p>Developers may forget to change the default password in a bolt-on encryption module, or may set an easy password for testing purposes, and forget to change it when going live.<br />
<em>Or</em>… they may just have rubbish passwords like the rest of the world.</p>
<p>Test the token for common weak passwords by specifying a wordlist/dictionary.<br />
Some good lists include the <code class="language-plaintext highlighter-rouge">RockYou</code> dumped password list, or any of the lists built into cracking programs like <code class="language-plaintext highlighter-rouge">John the Ripper</code>, or <code class="language-plaintext highlighter-rouge">SQLMap</code>.</p>
<p>If you’re using Kali Linux then you’ll find a bunch of these in the <code class="language-plaintext highlighter-rouge">/usr/share/wordlists</code> directory.</p>
<h2 id="forging-and-replaying-tokens">Forging and Replaying Tokens</h2>
<p>Once you’ve found a weakness you can forge a new token…</p>
<p><img src="/assets/images/jwt_privesc_alg_none.gif" alt="Installing JWT_Tool.py and forging a vulnerable token" /></p>
<p><code class="language-plaintext highlighter-rouge">JWT_Tool.py</code> has the tools to find these weaknesses, and then you can select the <strong><em>Forging</em></strong> option and tweak the Claims section of the token to your liking before signing:</p>
<ul>
<li>with the key</li>
<li>specifying the <em>None</em> ‘algorithm’</li>
<li>or using the Public Key to sign the vulnerable RSA-signed token</li>
</ul>
<p>To replay your forged token just fire up <code class="language-plaintext highlighter-rouge">Burp Suite</code>, or your favourite <em>intercepting proxy</em> to edit the data in transit, or set the new cookie in your browser via the console, or a cookie manager plugin.</p>
<p>Hope you enjoy smashing those tokens!<br />
<em>ticarpi</em></p>ticarpiSo, having introduced my JWT auditing tool (https://github.com/ticarpi/jwt_tool) in the last post I thought it would be good to provide a quick run-down of the various attack methods you should try as a pentester when faced with JWT auth on an engagement. Introducing JWT Tool2017-07-03T00:00:00+00:002017-07-03T00:00:00+00:00https://www.ticarpi.com/introducing-jwt-tool<blockquote>
<p>This post is to introduce you to a python project I’ve just published, having found a void and deciding to be the one to fill it…</p>
</blockquote>
<p>The <strong>JWT Toolkit</strong> (<a href="https://github.com/ticarpi/jwt_tool">https://github.com/ticarpi/jwt_tool</a>) is an auditing tool for <strong><em>JSON Web Tokens</em></strong> - which serve an <strong>Authentication</strong> and <strong>Authorisation</strong> function on countless websites across the interwebs.</p>
<p>When properly implemented JWTs are a good, strong option to provide this function.<br />
However they do have some inherent weaknesses, which if misunderstood can lead to a false sense of security.</p>
<p>This toolkit is intended to be used by <strong>pentesters</strong> looking to easily test the tokens they come across in an engagement; and also by <strong>developers</strong> looking to better understand, and more effectively secure their JWT-protected web applications.</p>
<h2 id="a-brief-jwt-primer">A brief JWT Primer</h2>
<p>JWTs are comprised of three parts:</p>
<ul>
<li>Header</li>
<li>Content/Claims</li>
<li>Signature</li>
</ul>
<p>The first two parts are JSON lists, which are Base64-encoded and squidged together with a dot in between.
To round it all out these parts are signed server-side using a secret or key - which is added with a dot onto the end.</p>
<p>The result is a token which can be sent as a cookie, as an HTTP Authentication Header, or stored in Session- or Local- storage and passed as a GET/POST parameter.</p>
<blockquote>
<p>eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJsb2dpbiI6InRpY2FycGkifQ.aqNCvShlNT9jBFTPBpHDbt2gBB1MyHiisSDdp8SQvgw</p>
</blockquote>
<p>Someone new to these tokens may assume they offered some privacy, however the decoding of the first two parts is just a simple Base64 decode:</p>
<blockquote>
<p>{“typ”:”JWT”,”alg”:”HS256”}.{“login”:”ticarpi”}.[signature]</p>
</blockquote>
<p>So, there’s your first tip - don’t store anything private in the token.<br />
<em>Yes, people have been known to store plaintext passwords in there(!)</em></p>
<p>As you will find by reading Tim McLean’s <a href="https://auth0.com/blog/critical-vulnerabilities-in-json-web-token-libraries/">great research on JWT weaknesses</a>, there are a number of weaknesses found across the various JWT libraries in use on production webservers across the internet.</p>
<p>These weaknesses revolve mainly around the failure to enforce the algorithm in use when checking the signature.<br />
This means that in some cases the user can reforge the token to specify either to <em>ignore the signature altogether</em>, or to force the use of the server’s <strong><em>Public Key</em></strong> as the secret in use in the HMAC-SHA algorithms!</p>
<p>Aside from these, there are the <em>normal</em> weaknesses that developers introduce by themselves: such as insecure passwords, and poorly-constructed token generation code.</p>
<p>All together that gives us a chance to play at a high-stakes table. Which is where this tool comes in.</p>
<h2 id="the-toolkit">The Toolkit</h2>
<p>I wrote this toolkit to enable pentesters to easily download this one tool and run it with the JWT as the only argument.</p>
<p>It provides a helpful menu for:</p>
<ul>
<li>forging new tokens to test the various vulnerabilities</li>
<li>editing the content of the <em>claims</em> section</li>
<li>testing possible keys - either individually, or via a wordlist.</li>
</ul>
<p>I chose to include a Dictionary Attack mode, as it was nice to keep everything in one place - even though the latest versions of <code class="language-plaintext highlighter-rouge">John The Ripper</code> do have a JWT mode.<br />
Hopefully you’ll find the speed acceptable - in my tests on an Intel i5 laptop I can test over 1 Million passwords/second. <em>YMMV</em><br />
I consider this reasonable.</p>
<h2 id="bit-of-back-story">Bit of Back-Story</h2>
<p><em>Please excuse this little bit of indulgence…</em></p>
<blockquote>
<p>I have a bit of a <em>relationship</em> with JWTs.</p>
</blockquote>
<p>I had never met them before my <strong><em>first</em></strong> web app pentest engagement - and was intrigued when I spotted them in use and started reading up on them.<br />
The tantalising text in the token which was restricting my privileges on the system was too much to ignore, and <strong>I knew I had to find a way</strong> to use them for privesc.</p>
<p>Half an hour later I suddenly hit upon a way to force an <em>overly-chatty</em> error message in the login function and there lay the key used to sign the token - right before my eyes.</p>
<p>A guess at the syntax, and a bunch of Base64-juggling in the Terminal, and I was ready to sign the forged token with the key. I used <a href="http://jwt.io">JWT.io</a> to create this new token, and injected it into my web traffic.</p>
<p>{“Privileges”,”<strong>ReadOnly</strong>”} became {“Privileges”,”<strong>Administrator</strong>”}, and I had full access to all the data, settings and access control.</p>
<p>All in all it was a fine first meeting, but I still had a strong desire to test the other possible weaknesses in JWTs on any other system I came across them.<br />
This was doable through manual processes, but when you start tweaking the available JWT libraries to accept malformed input it became quite clear that a proper JWT hacking and forging toolkit was what was called for.</p>
<p><em>Call it a vanity project if you will</em>, but I wanted something to practice my limited Python skills on, and so I decided to shun any of the existing (excellent) JWT libraries, and build one myself from scratch.</p>
<p>So here it is - native Python code, no libraries to download, and a full-featured JWT attack platform.</p>
<p><code class="language-plaintext highlighter-rouge">JWT_Tool.py</code> incorporates all the known vulnerabilities and weaknesses you are likely to meet in an engagement, and should allow you to forge and reforge tokens on a whim.</p>
<p>I hope you enjoy it!<br />
<em>ticarpi</em></p>ticarpiThis post is to introduce you to a python project I’ve just published, having found a void and deciding to be the one to fill it…Hacking Android - My First CVEs! (CVE-2016-2457, CVE-2016-3760)2016-08-25T00:00:00+00:002016-08-25T00:00:00+00:00https://www.ticarpi.com/hacking-android-my-first-cves<p><em>This blog post is a central point for the reports and blogs about the Android Guest Mode vulnerabilities I reported to Google in February 2016 - CVE-2016-2457 and CVE-2016-3760<br />
To read more about the vulnerabilities and how they are exploited read <a href="https://www.e2e-assure.com/Hacking_Android_Guest_Mode">the blog on the e2e-assure website</a>.<br />
The story of how they came to be follows below…</em></p>
<p>Well this was a bit of a WIN for me.<br />
Just a month into my new career in infosec I was messing around with Android and I suddenly have a thought: <em>I wonder…</em></p>
<p>In my experience this is what I do best - thinking outside the box; imagining scenarios that break the pattern, that do something unexpected.</p>
<h5 id="testing-some-stuff">Testing some stuff</h5>
<p>Ever since Guest Mode was announced in Android 5.0 (Lollipop) - back in late 2014 - I had been curious about how allowing someone physical access to a device could be a <em>good idea</em>.
It is generally considered in security circles that:</p>
<blockquote>
<p>physical access == device pwned</p>
</blockquote>
<p>This is a good principle that certainly holds true for Windows machines, but has truth on most platforms/OSes.</p>
<p>With this is mind I had long intended to <em>get to know</em> the workings of Android, and to understand the disconnect in between the <strong><em>Owner Account</em></strong> and the <strong><em>Guest Account</em></strong>.
Finally in the New Year of 2016 I got around to doing this.</p>
<p>I tested the UIDs for the accounts, file paths; attempted directory traversal, tried to exploit running services, play with <em>intents</em>, and a bunch of other interesting angles - all to no avail. This is a properly separated account, and everything has a disconnect, a divide to keep it secure.</p>
<p>Then one day I was preparing for some unrelated testing on my smartphone and started setting up an <em>intercepting proxy</em> (via the excellent <a href="http://www.telerik.com/fiddler">Fiddler</a>) to capture the web traffic from an app. Suddenly I had a thought about lack of separation in account settings.
I had a good feeling about this, so I set up a few tests on my Nexus 4, switching between accounts, playing with settings - seeing what stuck.
All the main <em>dangerous</em> settings were inaccessible in Guest Mode, other settings were limited. However there were a number of the Quick Settings that were not blocked…</p>
<blockquote>
<p>Indeed, the very one I was most interested to test was accessible.</p>
</blockquote>
<p>So, I tweaked the setting and checked that the traffic from Guest Mode was being sent through my remote device. It was - as expected.
Then came the real test - <em>would the settings persist in the Owner Account?</em></p>
<p>I switched user, then opened the Advanced Wi-Fi settings… The proxy settings were still there!
I opened the browser to double-check. Sure enough, my traffic started popping up in Fiddler.
I tested again to be certain. Then I cleared the settings and tried once more - all successful.</p>
<p>This was the kicker though - <strong><em>this is not just Privilege Escalation</em></strong>.<br />
Once launched for the first time by the owner, Guest Mode persists on the Android device. It is accessible from the lock-screen.</p>
<blockquote>
<p>I had found a way for setting up invisible remote monitoring of all device traffic from a locked Android device!</p>
</blockquote>
<h4 id="more-fun">More fun?</h4>
<p>After getting myself a little bit excited about the implications of this, I tested out some more settings - most were innocuous.<br />
However, I did managed to find one more that could do some damage - Bluetooth.</p>
<p>I found that authenticating a new Bluetooth device was possible in Guest Mode, and that it also persisted into the main user account.
You couldn’t set up SmartLock on it, and you couldn’t pre-authorise it to download content from the main account, however you could do a whole load of <em>naughty things</em> without the owner knowing that you had set it up.</p>
<blockquote>
<p>My main avenue of attack was HID attacks</p>
</blockquote>
<p>This attack involves sending a fast burst of programmed keystrokes from a virtual keyboard. As the owner may not realise my new Bluetooth device was connected (s)he wouldn’t know what was going on, and would be unlikely to be quick enough to prevent the changing of settings, the download and installation of malicious APKs, or a bunch of other creative attack vectors.</p>
<p>In addition we could pre-authorise a Bluetooth headset to listen to calls, using this to intercept 2-Factor authorisations and the like.</p>
<h5 id="reporting-and-bug-bounties">Reporting and Bug Bounties</h5>
<p>With two exploits in the bag I reported these via Google’s Android <a href="https://code.google.com/p/android/issues/entry?template=Security%20bug%20report">Security bug report tracker</a> and waited for a response.</p>
<p>Within a day or two I had confirmations of receipt; with further acknowledgements of eligibility for a bug bounty, as well as updates on bug fixing progress over the following weeks. The issues are now both fixed in Android, and third party vendors are pushing these fixes out to their devices <em>in their own sweet time…</em></p>
<p>I was very pleased with the process and feedback, and was grateful to receive a payment for my time and efforts.
However, what really made my day/week/year was my permanent inclusion on the <a href="http://source.android.com/security/overview/acknowledgements.html">Android Security Acknowledgements</a> page, and the CVEs registered for my reported vulns (CVE-2016-2457, CVE-2016-3760).</p>
<p>As an aside - I had the chance to meet the Android and Google security/VRP teams at <strong><em>BountyCraft 2016</em></strong> a few weeks ago, and they are great folks. I really hope that my ongoing research will give me more excuses to pester them about Android, and allow me to keep working to help keep our mobile devices secure.</p>ticarpiThe story of my first successful security research - FIXED - and a bug bounty from Google.Picking ‘unpickable’ locks - security vs obscurity2016-06-27T00:00:00+00:002016-06-27T00:00:00+00:00https://www.ticarpi.com/picking-unpickable-locks-security-vs-obscurity<p>This morning a parcel arrived: a padlock I’d ordered from Amazon to practice lockpicking with.</p>
<div class="language-plaintext highlighter-rouge"><div class="highlight"><pre class="highlight"><code>For those of you who might be concerned I'm turning to a life of crime - lockpicking is a time-honoured hobby practiced ethically for centuries by tinkerers and polymaths. It's a type of three-dimensional puzzle and a great way to improve spatial-awareness, patience, and dexterity - as well as being lots of fun.
</code></pre></div></div>
<p>As I unpackaged the lock I marvelled at its solid un-cuttable construction, shim-proof ball-bearing mechanism, and hefty weight. Then I took it to my workroom, set a timer and started to pick it.
<em>2 minutes and 32 seconds later</em> I felt the swing of the tension tool turning the zero-disc and the clank of the large shackle dropping open. Success!</p>
<p>But allow me to let you into a secret, good readers. This wasn’t any old lock. Indeed, no. This was <strong><em>an unpickable lock</em></strong>!</p>
<p>Or so I had been led to believe by customer J.A. Stewart’s 5-star review of this padlock on Amazon…</p>
<blockquote>
<p><em>“The keys are of a high security design and I would imagine that this lock cannot be picked easily if at all.”</em></p>
</blockquote>
<p>lol.</p>
<p><img src="/content/images/2016/06/unpickable.jpg" alt="unpickable disc detainer" /></p>
<p>Of course I mean no disrespect to this reviewer, and I’m glad he took the time to write a detailed review for this item and help others who are considering future lock purchases. However his assumption that an unusual lock style (a <a href="http://www.lockwiki.com/index.php/Disc_detainer">disc detainer</a> in case you’re interested) correlates with good security is very common.</p>
<p>This illustrates the point I wish to make quite effectively.</p>
<blockquote>
<p><strong>Obscurity is not the same thing as security.</strong></p>
</blockquote>
<p>As I see on a daily basis while monitoring client interactions with the internet, emails, and mobile apps - people assume that something being complicated or ‘behind-the-scenes’ is the same as something being secure.</p>
<p>Case in point: mobile apps often ask users for details - sign into this, type in your personal details here, pay for that.
These interactions happen, the data is sent somewhere, and an answer provided - or payment accepted.
<em>But how are these communications sent?</em></p>
<p>More and more on the internet, people are understanding the need for the <strong><em>https</em></strong> bit in the web address when entering banking details, or that <em>padlock symbol</em> next to the web address.
People are coming to realise (<em>finally!</em>) that we need a secure connection before sending personal details or passwords.
But on mobile apps we don’t have an address bar.</p>
<blockquote>
<p>we have to make the <strong><em>assumption</em></strong> that this standard minimum level of secure transaction is what is happening.</p>
</blockquote>
<p>As I’ve delved deeper into mobile app security testing I have seen time and time again that app developers <strong>don’t</strong> prioritise security at all.</p>
<ul>
<li>I have seen highly personal data being sent from apps to insecure webpages where it can be looked up by anyone (even though the app <em>promised</em> a high level of security)</li>
<li>I’ve seen ad traffic in apps redirecting people to download malware without their knowledge</li>
<li>I’ve seen apps built <em>so badly</em> that someone can click a couple of buttons to <strong><em>entirely skip the login process</em></strong> and enter the account in the app without a password!</li>
</ul>
<p>This month Apple announced their commitment to improving security of iOS apps by (soon) forcing developers <a href="http://www.techrepublic.com/article/wwdc-2016-apple-to-require-https-encryption-on-all-ios-apps-by-2017/">to use https</a> communications in their apps.
While this only covers one small aspect of app security as a whole it <em>is</em> an important step - and one I hope that Android follows suit on ASAP.</p>
<p>So a quick reminder:</p>
<ul>
<li>watch out for reports of insecure apps</li>
<li>don’t install apps from ‘alternative’ app stores</li>
<li>and make sure you’re happy with the reviews and permissions before installing <strong>anything</strong> on your mobile devices.</li>
</ul>
<p>Stay safe out there!</p>ticarpiA mini-tale about lock-picking, assumptions, and an infosec metaphorChromebooks FTW!2016-06-22T00:00:00+00:002016-06-22T00:00:00+00:00https://www.ticarpi.com/chromebooks-ftw<p>I’ve been playing with Chromebooks for a while now.
I got my first one (an Acer C720) a few years ago, and have done a load of stuff with it - using it for a while, then leaving it for a bit, then picking it up again.</p>
<p>All in all it is fair to say that it is a divisive sort of machine. The naysayers says it’s an underpowered half-computer that only works online. While the other camp (the <em>yaysayers</em>??) says they do everything that most people need.</p>
<p>You want to know the truth? I’m not <em>normal</em>.
I don’t really fit into the simple categories of who may or may not deal well with a Chromebook.
So I just had to try them.</p>
<p>And I love it. I really do. And for a bunch of reasons.</p>
<h5 id="firstly-i-use-mine-for-malware-analysis">Firstly, I use mine for malware analysis:</h5>
<p>One of the great things about Chromebooks is that the operating system is seriously secure.</p>
<p>The OS is updated automatically; it checks itself for corruption/infection every time it boots; it encrypts the user partitions; and it allows anonymous logon via Guest mode.</p>
<p>So, by using Guest mode I use my Chromebook for visiting potentially infected websites. I can safely view the sites, analyse them through Chrome’s built-in Dev Tools, download and debug any scripts on the sites, and check numerous other aspects of site security.</p>
<p>And once I’ve done all that I just reboot into my normal account and all is well. Whoop</p>
<h5 id="secondly-i-use-it-for-coding">Secondly, I use it for coding</h5>
<p>I have found a marvellous use for my latest Chromebook - an Acer R11 (a convertible, flippy, touchscreen thing).</p>
<blockquote>
<p>I had to get another one - my wife keeps on borrowing my C720</p>
</blockquote>
<p>You see, some epic fellows have found that by switching a Chromebook to Developer mode you can install a chroot (fancy name for running multiple Linux-based operating systems at the same time.
So… I have installed a command-line version of Ubuntu via <a href="https://github.com/dnschneid/crouton">crouton</a>, which I run from the Chrome terminal (crosh), while editing code on useful Chrome apps (like <a href="https://chrome.google.com/webstore/detail/text/mmfbcljfglbokpmkimbfghdkjmjhdgbg">the Text app</a>) and using git for version control and sharing.</p>
<h5 id="thirdly-android-apps-are-coming">Thirdly, Android apps are coming!!</h5>
<p>Yep, Android apps (and <a href="https://chrome.googleblog.com/2016/05/the-google-play-store-coming-to.html">the whole Google Play Store</a>) are coming to Chromebooks by the end of this year - or thereabouts.
My R11 should be getting the update any day now, and the reports for those already testing the update are largely very favourable.</p>
<p>Android apps on Chromebooks will be a <strong><em>total game-changer</em></strong>, with Chromebooks being cheaper than good quality tablets, while being better for typing and multi-tasking.
They are more secure than Windows and Mac OS, faster to boot, slick for website stuffs, and can do most things offline nowadays - which Android will improve upon.</p>
<p>I will also be expanding my Android security testing my analysing the Play Store integration as soon as my R11 gets the go-ahead.
I will also be using it as another platform for testing Android apps on for other security purposes.</p>
<p><em>Lots of fun to look forward to!!</em></p>ticarpiCoding, hacking and cmdline-fu on a ChromebookThought Experiment #1 - Basic Exfil2016-05-09T00:00:00+00:002016-05-09T00:00:00+00:00https://www.ticarpi.com/thought-experiment-1-basic-exfil<p>I hope you’re ready for this!
This post is to introduce a theme I plan to use occasionally on this blog - <em>Thought Experiments</em>.</p>
<p>In short: These are the kind of thoughts that pop into my head while I’m doing something at work, and I wonder whether something is possible if you tweak one of the normal features. Or perhaps, if I am looking at something that someone has already done, I wonder if I could do it more efficiently, or in a new way.</p>
<p>This particular thoughtexp occurred to me when needing to get some data off a remote box. I used an approved encrypted method, but it did make me wonder…</p>
<blockquote>
<p><strong>ThoughtExperiment#1:</strong><br />
If you were on a linux machine with no tools and limited access - how would you exfil a file by a text-only protocol while limiting the chances that someone capturing traffic would be able to easily read it?</p>
</blockquote>
<p>I suppose the scenario could be blackhat - a hacker with a limited-level exploit; or whitehat - needing to get a sensitive file off a friendly box.</p>
<p><em>Disclaimer: If you’re copying any client files ALWAYS do so securely. This hacky thoughtexp is just a game for keeping the mind supple.</em></p>
<h2 id="the-thinking">The thinking:</h2>
<p>OK, so what do we have?<br />
[+] Basic tools. Commandline stuff<br />
[+] Ingenuity (it’s pep talk time)</p>
<p>What don’t we have?<br />
[+] Time (this is a challenge dagnabbit)<br />
[+] Anything for basic encryption<br />
[+] Interfaces for transferring files - this will be text-only</p>
<p><strong>What can we use then?</strong><br />
OK, well nobody installed <em>openssl</em>, and with nothing else encryptish in sight we can’t get this data password-protected. Great…
If this is text-only we can’t send it in a block file format. (In my mind I’m going to be streaming it out with <em>netcat</em> or something similar.)</p>
<p><strong><em>So, let’s obfuscate it into a total (yet reversible) mess!</em></strong><br />
Base64 is somewhat overused, but very useful, and installed by default on all *nix systems I know.
But base64-encoding a string really isn’t going to cut it. Those strings are easy to recognise and simple (or automatic) to decrypt.
Hmm, so how to make the base64 string harder to recognise or read. Those hanging equals signs are a bit of a giveaway - so let’s strip those off. When we receive the file we can add any in to pad the string to a multiple of 4.</p>
<p>Still, if the string is already a multiple of 4 there are no equals signs to drop, and the string can be read easily.
Right, let’s reverse it then!</p>
<p>The <em>rev</em> tool will reverse all text on a line:</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nv">$ </span><span class="nb">echo</span> <span class="s2">"Hello World."</span> | rev
.dlroW olleH
</code></pre></div></div>
<p>That’s grand, that is.
Oh, hang on - multiple-line text files still are in line-order:</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nv">$ </span><span class="nb">cat </span>multi.txt | rev
1# enil si sihT
2# enil si sihT
</code></pre></div></div>
<p>OK, well did you know about <em>tac</em>?
Yep, that’s <em>cat</em> backwards…</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nv">$ </span><span class="nb">tac </span>multi.txt | rev
2# enil si sihT
1# enil si sihT
</code></pre></div></div>
<p>Ha. #winning</p>
<p>OK, so that’s going to be pretty obfuscated.
I’m going to reverse the text, then reverse the base64 string too (<em>and why not??</em>).
Let’s grab some <em>sed</em> and then see how that looks as a one-liner:</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nv">$ </span><span class="nb">tac </span>exfilme.txt | rev | <span class="nb">base64</span> <span class="nt">-w</span> 0 | rev | <span class="nb">sed</span> <span class="s1">'s/=//g'</span>
oASlJXZgk2cgEGIzRnclFWbg8mZgQWY0FmLgkEdgoyYvVHbkpCIiVGIj9mbmlGZl5GdpFGbuoQS0BSaz52J05CIUhWazBSazBia1NHdgEGI0V2c05iCIVmclBSazBSYuBCcpNGd1JXZ6oAZo42XuliY
</code></pre></div></div>
<p>Right, that’s pretty cool.
Recognising the string as possible base64 isn’t going to do you any good. So even if you pad it out the string is just junk now:</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nv">$ </span><span class="nb">echo </span><span class="nv">oASlJXZgk2cgEGIzRnclFWbg8mZgQWY0FmLgkEdgoyYvVHbkpCIiVGIj9mbmlGZl5GdpFGbuoQS0BSaz52J05CIUhWazBSazBia1NHdgEGI0V2c05iCIVmclBSazBSYuBCcpNGd1JXZ6oAZo42XuliY</span><span class="o">=</span> | <span class="nb">base64</span> <span class="nt">-d</span>
��%v�g b3Fw%f��fAf4b�G�&/Tv�--Tb%�f�fe�g&��bt��f&�&�4wb4Wg4� �V&�&.<span class="o">)</span>4gu%vz�h�e
</code></pre></div></div>
<p>Fancy one more safety precaution?
Let’s just hide the string a bit more by putting some padding at the beginning. Then you have to strip that off before reversing.
(Hacked-together way of grabbing only ASCII values from the random-char generator FTW!)</p>
<p>So, the final code goes like this:</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="nv">$ </span><span class="nb">cat</span> /dev/urandom | <span class="nb">tr</span> <span class="nt">-dc</span> <span class="s1">'a-zA-Z0-9'</span> | <span class="nb">head</span> <span class="nt">-c</span> 4 <span class="o">&&</span> <span class="nb">echo</span> <span class="si">$(</span><span class="nb">tac </span>exfilme.txt | rev | <span class="nb">base64</span> <span class="nt">-w</span> 0 | rev | <span class="nb">sed</span> <span class="s1">'s/=//g'</span><span class="si">)</span>
</code></pre></div></div>
<p>So when you receive the string you can strip off the known quantity from the <em>head</em> portion of the command above - 4 here, but could be anything. Then you can reverse the whole thing and you’re all good to go.</p>
<p>[end braindump]</p>ticarpiExperimental! A quick blog on thinking a way out of a problem.New Beginnings2016-05-07T00:00:00+00:002016-05-07T00:00:00+00:00https://www.ticarpi.com/new-beginnings<p>What better way to start this new blog than to set the scene with how I found myself here in this cybersecurity industry.</p>
<p>The long story goes back several years, and spans a good few anecdotes. Shall we save that for another day? Yes, good plan.
The short(er) version goes back 12 months, to when I was studying security principles in my own time, and making a 5-year plan to get out of my Local Government job, and into my dream job: keeping people safe, finding security vulns and writing exciting code.</p>
<p>Having done well on a test online to assess my cyber skills I was invited to apply for a scholarship at the first <a href="https://www.sans.org/ukcyberacademy">SANS Cyber Academy</a> - a process culminating in an interview in London in July.
I won a place, quit my job(!) and attended in September-October, along with 30 other cyber security enthusiasts.</p>
<p>SANS really pulled out all the stops, and 8 weeks later I emerged with 3 GIAC certs, a new bunch of friends, a head pulsing with new knowledge, skills and possibilities - and no job.</p>
<p>But 2 months later I landed my first infosec job - and here I am, living the dream, doing the stuff.
I now work as a Cyber Security Analyst at <a href="https://www.e2e-assure.com/">e2e-assure</a>, where I monitor bad stuff, analyse threats and attacks, research vulnerabilities, blog about security, and generally do exciting stuff that I really care about.</p>
<p>This blog is an outlet for my enthusiasm for infosec, ethical hacking, encryption and decryption, coding, vuln research, and plenty more related things.</p>
<p>I hope you will enjoy sharing in some of my challenges and experiences.</p>ticarpiWhat better way to start this new blog than to set the scene with how I found myself here in this cybersecurity industry.