Jekyll2020-09-10T11:19:02+00:00/feed.xmlPedro FreitasMy thoughts and rants about Penetration Testing, Red Team Exercises, Phishing, Exploits and more. From technical guides and knowledge to a day-to-day life as a Security Consultant.Bug Bounty: my initial thoughts2020-02-08T20:06:00+00:002020-02-08T20:06:00+00:00/2020/02/08/bugbounty-synack<blockquote>
<p>Bear in mind that this is a blog post from someone trying Bug Bounty Platforms for the past 8 days only. This is no means a post based on a lot of experience in the area.</p>
</blockquote>
<p>I started on Synack Red Team on January 30, 2020 and by the time I’m writing this blog post I’ve submitted two (2) findings. One rejected for being a duplicate and the other rejected because another researcher sent a better report. But on the overall I think I did a somewhat good job within seven (7) days on the platform.</p>
<p>However, not everything is a bed of roses. Those two findings, one medium (API Key Leak) and the other critical (I could wipe out a whole US govt website), took me around 3 days of work. And since both findings were rejected, it was 3 days of work that I didn’t get paid at all.</p>
<p>Even though the paragraph above mentions the fact I didn’t get any money out of it <strong>I did learn a lot in the process</strong>. And also, money wasn’t my big incentive for doing it. I really want to step up my game as a Penetration Tester (and Red Teamer, but it doesn’t apply here) and Bug Bounty platforms will definitely push it to the next level. After all you’re competing with a lot of people out there and testing real world systems.</p>
<p>This is another downside of such platforms, the amount of people doing it right now. So you have two options mainly, you speed up your process of submitting valid vulnerabilities by potentially impacting the quality of your report, or you go ahead and submit the finding with the information you have already so you can be the first. Each have its downsides as well since you can submit a long and detailed report and have your submission flagged as duplicate, or you submit it as fast as possible and have it flagged as not applicable/sufficient/lack of details or even being accepted but with a small payout.</p>
<p><img src="https://pedrosfreitas.github.io/assets/images/flowgraphbugbounty.png" alt="Bug Bounty Flowchart" title="Bug Bounty Logic Flowchart" /></p>
<p>Now with Synack Red Team this is a bit different since some targets have a 24-hours policy where all submission will be put on hold and only the best reports will be flagged as accepted (what happened with my second submission). This is great because enables the Researcher to do a good job, take his/her time, and send a quality report. But, as far as I know there is no exact definition of what is a good report and you don’t have the visibility on what others sent (the same finding).</p>
<p>So with eight days of active bug bounty experience I have no idea what to do next. If I should stay, try harder (I hate this sentence), and see what I can get in the future. Or if I should simply ignore it at all and focus on the Red Team (Threat Emulation) side, which I definitely love. Maybe even both? By lowering time on Bug Bounty, doing once a week or so? Let’s see.</p>
<hr />
<p><em>Edit(s):</em></p>
<ul>
<li><em>2/10/2020: Fix typos and add clarification paragraph about Synack 24-hours policy.</em></li>
</ul>Bear in mind that this is a blog post from someone trying Bug Bounty Platforms for the past 8 days only. This is no means a post based on a lot of experience in the area.systemd-nspawn: my thoughts and its uses2019-08-03T18:41:00+00:002019-08-03T18:41:00+00:00/2019/08/03/systemd-nspawn<div>
<p><blockquote><strong>Note</strong>: <i>if you came here to get some quick references check the <a href="#engagement">TL;DR</a> section.</i></blockquote></p>
</div>
<p>Quoting from the man page, <code class="language-plaintext highlighter-rouge">systemd-nspawn</code> is “<em>in many ways similar to <a href="http://man7.org/linux/man-pages/man1/chroot.1.html" target="_blank_">
chroot(1)</a>, but more powerful since it fully virtualizes the file system hierarchy, as well as the process tree, the various IPC subsystems and the host
and domain name… It may be invoked on any directory tree containing an operating system tree</em>”.</p>
<p>Bottom line and as the <a href="https://wiki.archlinux.org/index.php/Systemd-nspawn" target="_blank">ArchWiki</a> says: “<em>is like the chroot command, but it
is a chroot on steroids</em>”. Not only that but based on the description from the manual page (extract above) <code class="language-plaintext highlighter-rouge">systemd-nspawn</code> can definitely be used as an
alternative to well-known operating system-level-virtualization… such as <a href="https://en.wikipedia.org/wiki/Docker_(software)" target="_blank">Docker</a>.</p>
<p>But why have another solution for os-level-virtualization (containers) if we already have <a href="https://en.wikipedia.org/wiki/LXC" target="_blank">LXC</a>,
<a href="https://www.docker.com/" target="_blank"> Docker</a>, <a href="https://en.wikipedia.org/wiki/Chroot" target="_blank">chroot</a> and
<a href=" https://en.wikipedia.org/wiki/OS-level_virtualisation#Implementations" target=" _blank"> others</a>? A follow up question to that could be: Why should I use
<code class="language-plaintext highlighter-rouge">systemd-nspawn</code> if I can easily use <code class="language-plaintext highlighter-rouge">Docker</code>? Without going into the <a href="https://www.reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc/" target="_blank">war that is among the community regarding systemd</a>, it’s a fact that a lot of distros out there adopted it you like or not! If that is the case for
the distro you’re using, then there is a high chance <code class="language-plaintext highlighter-rouge">systemd-nspawn</code> is already present in your machine. This means you have a way to virtualize another GNU/Linux
environment with just a couple of commands. <strong>You can spin up a container within seconds with tools already at your hands; without installing more packages!</strong></p>
<p>If you’re anything like me this is great news, specially since I’m constantly trying new softwares/application, playing around with AUR and also trying to
port packages to <a href="https://blackarch.org/" target="_blank">BlackArch</a>. Now I can use <code class="language-plaintext highlighter-rouge">systemd-nspawn</code> to spin up a vanilla Arch Linux environment and do
my tests without messing with my host installation, leaving it as clean as possible. And of course everything that you can do with Docker you can probably do with
<code class="language-plaintext highlighter-rouge">systemd-nspawn</code> too.</p>
<h3 id="network">Network</h3>
<p>By default the guest, i.e., container, running on <code class="language-plaintext highlighter-rouge">systemd-nspawn</code> will share the network with the host. This is not the default behavior with Docker, so could
cause some confusion. But you can tweak the configuration in order to create private network or a bridged one. I highly recommend checking the
<a href="http://man7.org/linux/man-pages/man1/systemd-nspawn.1.html" target="_blank">man page</a> for <code class="language-plaintext highlighter-rouge">systemd-nspawn</code> since it covers all configurations,
features and more.</p>
<p>But going back to the point that the guest shares the network with the host, this make testing applications way easier and out-of-the-box. For instance, I didn’t
know what to expect from Jekyll so I ran an vanilla Arch installation as guest using <code class="language-plaintext highlighter-rouge">systemd-nspawn</code>, installed all the necessary packages (ruby), gems and did
all the development using the container. In fact, I’m right now writing this blog post inside the container using <code class="language-plaintext highlighter-rouge">systemd-nspawn</code>. The good thing is that my base
installation is untouched and since the guest shares the network I test the blog by accessing the localhost:4000 on my browser. :)</p>
<p>This behavior can also make it a bit easier, or just out-of-the-box, to sandbox applications. You can spin up a small Linux base installation, install your browser
and use it from within the container. Of course you’ll need to configure X properly and for that just visit:
<a href="https://wiki.archlinux.org/index.php/Systemd-nspawn#Use_an_X_environment" target="_blank">ArchWiki - Systemd-nspawn: Using X</a> and follow the instructions.</p>
<h3 id="my-thoughts">My thoughts</h3>
<p><code class="language-plaintext highlighter-rouge">systemd-nspawn</code> can be a great alternative for os-level-virtualization and it’s probably already installed in your distro. Having the network shared with the host
by default create the easiest scenarios for testing and sandboxing applications.</p>
<p>However, it always comes down to your use case. You should use solutions that address your problems in an effective matter. For me, <code class="language-plaintext highlighter-rouge">systemd-nspawn</code> won my space
for containers since it is easy to use and already in my system (base installation).</p>
<div id="engagement">
<h3>TL;DR: Arch Linux using systemd-nspawn</h3><p></p>
</div>
<p>Running an Arch Linux on systemd-nspawn, considering you are on an Arch host:</p>
<div class="language-bash highlighter-rouge"><div class="highlight"><pre class="highlight"><code><span class="c"># Install arch scripts to get pacstrap</span>
<span class="nb">sudo </span>pacman <span class="nt">-S</span> arch-install-scripts <span class="nt">--needed</span>
<span class="c"># Create a folder to hold the environment files (system tree):</span>
<span class="nb">mkdir </span>arch-container
<span class="c"># Use pacstrap to create the base directory tree for Arch, we don't need the kernel</span>
pacstrap <span class="nt">-i</span> <span class="nt">-c</span> arch-container base base-devel <span class="nt">--ignore</span> linux
<span class="c"># Spin up the container</span>
<span class="nb">sudo </span>systemd-nspawn <span class="nt">-b</span> <span class="nt">-D</span> arch-container
</code></pre></div></div>
<p><code class="language-plaintext highlighter-rouge">-b</code> / <code class="language-plaintext highlighter-rouge">--boot</code>: automatically search for an init program and invoke it as PID 1, instead of a shell or a user supplied program.</p>
<p><code class="language-plaintext highlighter-rouge">-D</code> / <code class="language-plaintext highlighter-rouge">--directory=</code>: directory to use as file system root for the container.</p>
<p>You’ll be able to login as <code class="language-plaintext highlighter-rouge">root</code> without any password. After that you can tweak the environment as you see fit, the same way if it was a regular installation.</p>
<p>For full reference check:
<a href="https://wiki.archlinux.org/index.php/Systemd-nspawn#Create_and_boot_a_minimal_Arch_Linux_distribution_in_a_container" target="_blank">https://wiki.archlinux.org/index.php/Systemd-nspawn#Create_and_boot_a_minimal_Arch_Linux_distribution_in_a_container</a></p>Note: if you came here to get some quick references check the TL;DR section.