Forem: Kat Maddox

The Worst of Kat

Kat Maddox — Wed, 03 Jul 2019 22:30:59 +0000

I'm flat out of creativity today, so I'm just going to compile the content I've most successfully terrorized Twitter with. Hope you enjoy!

// Detect dark theme var iframe = document.getElementById('tweet-1134635023984807937-630'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1134635023984807937&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1137352808628273152-201'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1137352808628273152&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1139696176721096704-161'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1139696176721096704&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1140519226471407617-569'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1140519226471407617&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1141962739721465856-792'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1141962739721465856&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1142239420336103425-236'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1142239420336103425&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1142382806720339968-417'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1142382806720339968&theme=dark" }

// Detect dark theme var iframe = document.getElementById('tweet-1144919494952808448-97'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1144919494952808448&theme=dark" }

Staying Motivated When Working on Projects: A Paradigm Shift

Kat Maddox — Sat, 08 Jun 2019 14:31:03 +0000

Picking up projects, feverishly working on them, and then entirely forgetting about them weeks later has been an issue for me ever since I started my tech career. I frequently compare myself to the tech version of Sisyphus - just that I get much less exercise.

Recently, I started working on a project that I'm absolutely in love with. I can't think of many things that'd make me happier than finishing it.

The issue? It's going to take me at least half a year to complete. I'm lucky if I can focus on something for more than half a month.

I decided that I loved this project idea enough to finally do something real about my motivation issue. The usual self-help articles weren't going to cut it this time.

I booked an appointment with a therapist, fully expecting to come out of the session being 120% motivated. Motivation would drip from every pore of my body. All my coder friends would say "Yeah, that's Kat, she's the one with the motivation". With the help of a professional - who unlike me was a real adult, judging by his nice couch and the certificates on his wall - I'd unlock the secret to eternal, unwavering motivation.

Of course, I didn't. But I got a lot of other advice instead, and after taking it on board, I'm definitely seeing much better results in my dev habits.

In this post, I'm going to compile most of the advice I was given, so that you can get the benefits of therapy without having to spend the $100. You can thank me later.

So the first step is...

Embrace boredom

The problem wasn't just that I was losing motivation after the beginning of the project - it's that I was getting bored of the project after the initial challenge. And that my aversion to boredom was so strong that I didn't want to continue. I could power through it - I just really, really didn't want to.

Unfortunately, boredom is a timer that starts the moment you write down that first line of code. You can't stop it. You're a coder, and boredom is coming for you.

While I assert that being a coder isn't a personality type, we all do have one thing in common: we seek novelty. We love working with shiny new technologies. But the issue with shiny things is that they stop being shiny the moment you get your grubby hands on them. If you're anything like me, you'll stop working on something the moment it bores you.

But if you do this - and I know you do this - you're wiring your brain for failure. By avoiding boredom, you're not exercising your mind's ability to deal with it - which creates a feedback loop of you being even more afraid of boredom the next time you encounter it.

The only way past this is to embrace it. Next time something starts boring you, see it as a sign of progress instead of bouncing to a new project. It won't be easy the first time you try, but over time you'll learn to thrive despite boredom. And just as motivation left once, it'll come back eventually once you start seeing all the results of your hard work.

In the meantime, you can slow down the impending march of boredom by...

Changing direction

Unless your project is tiny - in which case, why aren't you done with it already? - then it probably has more than one component.

For example, I'm currently doing gamedev. When I've done too much coding, I'll switch to 3D modeling. Then I'll take a break to do worldbuilding, then writing, and then it's back to coding again.

Take some time to think about how your project can be split into different, but parallelizable components. Section them off and start on the one that excites you most right now, and come back to the others later.

The benefit of this is that working on components concurrently delays boredom long enough for you to get some results in. Once you do have results, looking back on them is going to be your #1 asset while you slowly crawl through the inevitable gloom. Be like a little coder squirrel, stashing away progress to prepare for the winter (the winter is boredom).

And since you've already split your project into different components, what you can do next is...

Replace components that don't excite you with ones that do

If there's a part of your project that you know you're dreading, see if you can rework it. Maybe you can use a fresher, more exciting framework for that part instead. Take some time to explore more interesting ways of doing things!

Once you work on your project for a while, you'll build up momentum. Momentum is amazing! It's an intoxicating feeling. So you'll probably hate me when I say -

Kill your momentum

Do you think I WANT to be writing this blog post? Hell no. I've got a game to make, god damn it. Stop bothering me.

Telling me to kill my momentum and take frequent breaks from my project was the most counter-intuitive, irritating advice I got. But my momentum was a crutch. I was so unsure of my ability to stay committed to a project that the second I got any traction, I did everything possible not to let go. I pulled late nights, shirked friends, and dropped other commitments.

Of course, we all know where that gets you. And while you can power through boredom, you can't power through burnout. When you find yourself getting too obsessed, pull away from your project to do other things.

I know I sound like a madwoman, because so far I've pretty much told you to work on your project when you don't want to, and to put your project aside when you DO want to work. I understand if you're upset, so feel free to direct all your hate mail to me at @kathyra_.

But the point of this is to make sure that your project is controlled by you, not your impulses. You shouldn't allow boredom to make you abandon your work, and you shouldn't invite burnout by working too feverishly either. Stay driven, but above all, stay sane.

But if you're REALLY having trouble pulling away from your work, here's a great project-adjacent way to take a break:

Take some time off to share your project with the community!

People say you should be your own cheerleader.

To hell with that. Have you ever seen a cheerleader score a goal? Or a field player waving pompoms? Those are two different jobs, and doing both at the same time is just... not easy. There's going to be times during your project when you'll be feeling tired and unmotivated, and continuing while having a smile on your face won't be possible.

That's why the developer community is here to help! We're here to be your cheerleaders. When you've stopped feeling excited about your project, let us be excited for you.

Consider sharing the progress of your project with the Twitter developer community and writing posts about it on dev.to. As well as getting you ongoing support from the developer community, this also helps you build a following for your project so that more people see it once it's released!

And of course...

Accept the death of motivation

Motivation gets you started on a project, but it won't see you through to the end. Asking "how do I stay motivated?" is the same as asking "how do I be happy?". It's something that comes and goes, and you should appreciate it when it's there but also learn to make the most of things when it's not.

To summarise:

Embrace boredom as a sign of progress
Split your project into parallelizable components and switch between them to keep things novel
Find fun alternatives to the boring bits
Don't rely on momentum
Share your progress with the community

Keep in touch!

Like my posts? Check out my Twitter! I make bad jokes, reduce important social issues to juvenile satire, and occasionally rant about tech.

Want just the tech? Subscribe to my email list to get notified of when new posts are released!

This post was originally published on explainhownow.com

Scan Your Network for Vulnerabilities With Nmap

Kat Maddox — Sun, 14 Apr 2019 04:29:30 +0000

Nmap is a free, open source tool for running scans on networks and discovering potential vulnerabilities. If you're a pentester, Nmap is a crucial part of your reconnaissance for understanding the landscape of what you're working with. As a developer or sysadmin, you should absolutely learn how to use Nmap to scan your networks! It gives you a "black box" view of what's going on in your network and allows you to view it the way hackers do. So if you can spot any issues - chances are, someone malicious already has!

Note: if you're a web developer hosting your website on a third-party service, you might not have permission to do networks scans. AWS allows customers to carry out penetration tests, but other hosters might not. Make sure you check first!

Target audience:

Developers
Sysadmins
Penetration testers

Installing Nmap

Nmap is pretty easy to install on Windows and MacOS - check out the official download page. I recommend using Zenmap, the GUI that comes with the Windows and MacOS download. Zenmap looks like this:

If you're on Ubuntu or similar, you can instead run something like this:

sudo apt-get install nmap

Scanning for Ports With Nmap

Nmap is a powerfully versatile tool with many options. So many that the people behind Nmap managed to write a 468-page long book on it.

I'll go over the basic usage of Nmap first, and then we can get into some of the fancier options. I'll use Yahoo.com at my target host since they've got an active bug bounty program and won't arrest me.

Here's a basic scan:

nmap -sS yahoo.com

The -sS flag performs a SYN scan, scanning many ports without ever completing a TCP connection. This is a great option if you don't want to be too noisy. This shows us there are two open ports, 80 and 443 (for HTTP and HTTPS). Pretty much what we'd expect!

Let's add another flag to this, -O.

nmap -sS -O yahoo.com

This time, we see the ports and also some guesses of what OS the server might be running. Knowing what OS is running on a server is an important part of reconnaissance since some vulnerabilities are OS-specific. For example, OpenSSH 5.3 is ancient and has exploits publicly available, and if you see it on a server, chances are it's vulnerable. The most notable exception to this is if the server runs Redhat OS, since Redhat has patched around OpenSSH 5.3's issues.

Side note: the -O flag is slow, so drop it from your scan if you don't need it.

Let's check out another flag, -sV.

nmap -sS -O -sV yahoo.com

Results:

PORT    STATE  SERVICE        VERSION
80/tcp  open   http-proxy     Apache Traffic Server
113/tcp closed ident
443/tcp open   ssl/http-proxy Apache Traffic Server

This time, we see the version of what software is running on the ports! This is crucial for discovering vulnerabilities since older software tends to have more exploits available. Try also throwing in the -v flag, which gives you more verbose information about the output.

Next, let's try specifying what ports we want to check for instead of just doing a general scan.

nmap -sS -sV -v -p 22 yahoo.com

Results:

PORT   STATE    SERVICE VERSION
22/tcp filtered ssh

We can see that port 22 is filtered on Yahoo, which means we'd probably have a hard time attacking it. You can specify a range of ports by replacing -p 22 with something like -p 1-165535. The flag that I usually use is --top-ports 1000, which as the name implies, scans the most common 1000 ports.

Putting it all together, this is what I'll usually run to get an overall look of the host:

nmap -sS -sV -O -v --top-ports 1000 yahoo.com

Here, we're doing a sneaky scan (sS), version detection (sV), operating system detection (O), verbose output (v), and scanning the top 1000 ports.

Now you know the basics of port scanning with Nmap!

Going Further

Scanning IP Ranges

Scanning IP ranges instead of a single host is useful if you're testing on your own servers. I don't recommend doing this on servers you don't own, since you might miss and scan someone who's not your target.

Nmap uses CIDR notation, so you can just run something like this:

nmap -sV --top-ports 1000 192.168.1.0/24

Timing

Nmap has five timing options, officially named: paranoid, sneaky, polite, normal, aggressive, insane. You can specify this with the T flag, e.g. -T0 for paranoid and -T5 for insane. By default, Nmap runs on "normal" mode, so -T3 does nothing. I'll usually run my scans on -T4 if I know it won't upset the client.

File Output

If you want to save Nmap's results to a file for later, add the -oN filename flag. -oX filename outputs results in XML format, which is useful if you've got scripts that process Nmap output.

Scripts

Nmap comes with some scripts you can enable! I don't normally use them since I prefer other tools, but here's a good guide explaining them.

The Fun Part: Exploitation

Now that we know what's running on a host, we want to exploit it.

Attacking networks is an entire topic of its own, but I'll cover some of the basics here!

Port 22: SSH

If the network has port 22 open and ssh running on it, that's a good starting point. If you can successfully manage to log in through SSH, well... that's a bad sign for the server.

First off, check the version of SSH that's running (recall that you can do this with the -sV flag). Google that version and chuck in the keyword "exploit". If it's an older version of SSH, you have good chances of finding publicly available exploits that you can just copy and run.

If that doesn't work, you still have a chance of getting a login. Go back to your terminal and run something like this:

ssh remote_username@remote_host

"remote_username" can be any number of things, but the common names I'd check for are admin and root. Try some common passwords, and also try some company-specific things (does the network admin have a dog? kids? try their names). You can also try to run a bruteforce scan, but that's out of the scope of this post.

Everything Else

SSH is a special case because of the severity of compromise possible if you get a login, but other services can be equally vulnerable.

Once you've run an Nmap scan with version detection enabled, see if anything other than just port 80 and 443 shows up. Google the name of any services you find and figure out what they do, and if any exploits are publicly available. You know how developers joke about ripping all their work off StackOverflow? Pentesters pretty much do the same but with CVE (Common Vulnerabilities and Exposures) databases.

Once you've run out of services to Google public exploits for, you can double back and check if any of the services have login portals. For example, if the service is webmail, you can try logging in to it with netcat by trying out default usernames and passwords for that service.

How do I fix my vulnerable server?

That's not my department.

Check out these posts though:

Keep in touch!

Like my posts? Check out my Twitter! I make bad jokes, reduce important social issues to juvenile satire, and occasionally rant about tech.

Want just the tech? Subscribe to my email list to get notified of when new posts are released!

This post was originally published on explainhownow.com

Protect Yourself from Social Engineering

Kat Maddox — Sat, 06 Apr 2019 11:58:33 +0000

As developers, we're a prime target for social engineering scams. Hacking people is much easier than hacking infrastructures, and developers have access to things that are especially appealing to attackers.

While this article isn't strictly about coding - or even computers at all! - every dev should know how to avoid social engineering scams to keep themselves and their projects safe.

Target audience:

Developers
Everyone else, too

Be Careful With Sharing on Social Media

Does something about this tweet look concerning?

If you guessed "answering this question pretty much gives a hacker everything they need to reset your password" - then yep. Correct.

Gone are the days when tech-savvy people avoided having any online identity. Now, your Twitter name is your full name, and your workplace is in your bio (because what kind of dev doesn't love showing off?). With your name and workplace, attackers can guess your work email. If you start throwing in personal info like answers to security questions - it's over.

Even if your workplace doesn't have security questions, chances are your passwords are based on your personal info such as pet names anyway. 79% of users admit to having personal info in their passwords... and that's just the ones who admit to it.

Check out CUPP. CUPP is a tool where you can input someone's name, pet name, child name, DOB, etc. and generate a list of potential passwords. It works. Quite well.

In short: be careful with the info your share online!

Enable 2FA and Integrate it Into Your Projects

Wherever possible, enable 2FA on services you use, such as your Google account, bank accounts, Slack, etc. While 2FA isn't perfect, it's pretty close.

If you're working on a project that requires personal login and deals with any sensitive information, please consider coding a 2FA option into your app. Here are some resources:

Don't Get Phished

Phishing is still the most popular form of social engineering. 92% of malware is delivered via email, and 95% of attacks on enterprise networks are the result of successful spear phishing.

Many developers are still operating on the archaic belief that phishing emails are poorly written, have terrible grammar and are obviously fake. Unfortunately, phishing emails have evolved significantly in the past few years. Nowadays, many phishing emails will be excellently written and almost indistinguishable from a legitimate email.

Here are some of the most common phishing scams lately:

Spear Phishing

Spear phishing involves selectively targetting employees, and developers are especially vulnerable. Spear phishers will discover information about you, and then selectively use it against you.

One of the most classic examples of spear phishing is sending fake invoices to people in finance teams. Lately, however, attackers have been expanding their reach by farming employee's social media accounts and sending them tailored email scams.

Here's a fun story.

So, I had to take a day off from work to take my dog to the vet. The team was short-staffed already, so I was feeling a little guilty.

I posted a pic of my dog on Instagram with the caption "Taking Lucy to the vet today. Feeling guilty about missing work though!"

About an hour later, I got this email from my boss:

"Hi [my name],

Hope Lucy is okay! But if you miss another day of work I might have to fire you. LOL.

Please send $15,000 to this client before COB today.
[client details]

Regards,

[boss' name]"

I was planning on transferring the amount, but it completely slipped my mind before the end of the day. I called my boss in panic apologizing for not paying the client in time.

He asked me what on Earth I was talking about.

Terrifying, right?

Spear phishing takes many forms and is becoming progressively more sophisticated with the rise of social media.

To protect yourself from spear phishing, consider the following:

Was I expecting this email from this person? Have we discussed the matter through other channels previously?
Does the email convey a sense of urgency?
Does the email demand action from me?
Can I confirm the authenticity of this email through other channels?

Also, check the sender's email address for any potential typos - e.g., replacing an "i" with an "l", or an "m" with "rn". Even if the email address is perfect, remember that spoofing addresses is simple and that there's no guarantee the email came from the shown source.

Impersonating Services

This is the most well-known form of phishing. It involves posing as a business, often styling emails to look like what that business would typically send. Here's an example with Dropbox:

Source: https://www.mailguard.com.au/blog/dropbox-phishing-180302

Fun fact: this form of phishing is how hackers got into John Podesta's email account!

To protect yourself from this type of phishing, consider the following:

Does the email convey a sense of urgency, or demand action from me?
Does anything look off about the sender?
When I hover over links in the email, does the popup box show that they point to a strange location?

Smishing

Source: https://www.welivesecurity.com/2016/11/10/apple-id-smishing-evolves-lure-victims/

Smishing (SMS phishing) is similar to standard phishing emails, but over SMS instead. Smishing texts will usually impersonate companies and encourage you to click on a link or give away your personal info.

Smishing attacks are difficult to detect, which is why the general advice is never to follow links you receive over text.

Vishing

Vishing ("voice" and "phishing") involves phishing through phone calls. Of course, this isn't a big deal to us, because what kind of developer seriously answers the phone nowadays? Just send me a text, FFS.

Most vishing relies on spoofing the caller ID to appear as a legitimate source. In a recent scam, attackers have been spoofing Apple. Phone calls coming from these scammers appear entirely legitimate, featuring "Apple Inc" as the caller name, and even showing Apple's logo. Victims would be prompted to share their personal information, and potentially make credit card purchases.

To avoid vishing, consider:

Was I expecting this phone call?
Does the call convey a sense of urgency, or demand action from me?
Is the caller asking for my personal information?

Socialshing

Okay, I made that word up. But social media phishing is beginning to become a big deal. Here are some of the tactics to watch out for:

LinkedIn Contact Compromise:
In this attack, a hacker has already compromised one of your contacts. Through the contact, they leverage the trust you have and send you a message asking you to follow a link.

The Infamy Video:
A compromised contact, usually on Facebook, will send you a message with a link. They'll claim the link is a video of you doing something embarrassing, with a very high view count. If you click on the link, it'll redirect you to a fake Facebook login page.

Twitter Baiting:
An attacker will find a Twitter comment thread where a legitimate company is interacting with some users. The attacker will set the same display name and profile picture as the company, then insert themselves into the thread, usually encouraging users to click on a malicious link.

Automate, Automate, Automate

... the security of software applications should not be entrusted completely to developers. Instead, as Podjarny said, companies should introduce automation into security controls, implement automatic malware-detection scans, multi-factor authentication, and auto-expiring access tokens to ensure attackers are not able to gain access to or to inject malware into sensitive software programmes.

Where possible, try to integrate automation into your security practices. Humans can only be so aware, and there's a lot of awesome apps out there that help fill the gaps. Enable 2FA, install a password manager if you haven't already, and scan your networks regularly.

Stay Safe!

The world is a scary place, and everyone is out to get you. Try to stay up to date on the latest phishing scams, as attackers are continually learning and are never too far behind us.

Happy hacking!

This post was originally published on explainhownow.com

What Security Through Obscurity Is, and Why It's Evil

Kat Maddox — Sun, 31 Mar 2019 07:17:08 +0000

This article is an explanation of what security through obscurity is, why it's terrible if it's your only defense, and some ways in which you might be using it in your webapps. If you do pentesting, this will give you some tips on where to look in webapps to find examples of poor security you can exploit.

Target audience:

Webapp developer, or
Beginner pentester

What is Security Through Obscurity?

Security through obscurity is the reliance on secrecy and confusing attackers instead of building proper controls to keep them out.

Let's take a real-world example.

Say you're a teenager again, and you've got a particular folder of files that you'd rather your parents don't find. You know the kind.

You probably hid this folder behind a whole bunch of other folders and named it something boring. And you might have felt very confident knowing that there's no reason your parents would ever look in the "homework" directory.

This would be security through obscurity. It might work for a while, but the moment anyone checks the "Frequent Files" section of Windows Explorer, your secret's out. A much better bet would have been to password protect your files.

In computing, security through obscurity is used more commonly than you'd expect. Here are some of the most harmful examples of security through obscurity I've seen.

Reliance on Robots.txt

Robots.txt is a file located at the root of your domain, e.g., mywebsite.com/robots.txt. Robots.txt is used to tell search engines such as Google not to crawl certain sections of your website. A robots.txt might look something like this:

User-agent: *
Disallow: /super-secret-passwords/
Disallow: /secret-admin-access-panel/

All this does is prevent Google from crawling those pages! It doesn't ward away hackers. Checking for a robots.txt file is one of the first things a malicious person might do - and where do you think they're going next when they see you've told Google not to crawl "super-secret-passwords/"?

Instead, if you want a page to not show up in results, add a noindex metatag to the page. Better yet, if anyone other than you shouldn't see a page, make sure it's behind a secure login page. Also consider IP-restricting it if you don't move around too much.

Hiding Common Wordpress Files

Some Wordpress websites try to conceal the fact that they're running Wordpress. Common ways of doing this include removing Wordpress' readme.html file and renaming folders such as wp-admin.

While these might deter a novice attacker, any hacker worth their internet connection will be able to figure out that you're running Wordpress by checking your CSS.

The alternative? Honestly, don't bother too much. Hiding the fact that you're using Wordpress isn't as important as just keeping your Wordpress and plugins updated. If you have a Wordpress website, try running wpscan on it to see if there are any glaring vulnerabilities you should fix.

Hiding Insecure Code in Subdomains

Say there's a part of your website that you want to hide - maybe some insecure code that you still need to test, or some admin controls. One of the ways you might do this is stowing it away in a subdomain.

This is fine, as long as it isn't your only method of security. If the subdomain requires a secure login and is IP-restricted, you're a-okay. But just putting your insecure code behind a random subdomain with no other controls is a terrible idea. I explain why in this post.

Rolling Your Own Crypto

Surely, given how long all those other hashing algorithms have been around for, they must be insecure by now, right? Maybe it's better to make your own.

No.

No, no no no.

No no no.

Unless you SERIOUSLY know what you're doing, don't try to make your own encryption or hashing algorithm. The current popular algorithms have been properly vetted by the security community and are much more secure than anything you could make on your own. If you make your own algorithm, it's likely to contain serious mistakes that you might be overlooking. Please, just don't.

Relying on Obscure Database Names

Sure, maybe renaming your "User" SQL database column to something more esoteric will make it a little bit harder for attackers to perform SQLi. But if SQLi is possible on your site, fixing the vulnerability should be your main concern.

If you're not sure whether or not your site is vulnerable to SQLi, check out sqlmap.

Secret Parameters

This is one of my favorites because of how often CTFs use it, but it also occurs in the real world.

Say you've got http://mywebsite.com/normalpage, but when you navigate to http://mywebsite.com/normalpage?admin=true, admin access is enabled.

An average user might not try to add the admin parameter, but any half-decent hacker with a fuzzing tool will find it in minutes. Using secret parameters to control access to hidden content is a bad idea.

Of course, "admin" isn't such a secret word. What if the control parameter was instead something like http://mywebsite.com/normalpage?230j7x9832nnc=true?

Now it's pretty much the same as having a password, right? Nope. The main issue you're facing now is that if your page links to anywhere else, your secret parameter has a chance of showing up as a Referer heading, which wouldn't have been an issue if you had just implemented a standard login panel.

If you must do this, for whatever reason, maybe instead consider moving the parameter to be in the body of a POST request instead.

An Aside

Of course, obscurity certainly has its place in webapp design. It's perfectly reasonable to put sensitive code on a subdomain or remove references to your backend. The key consideration is that this should not be your only line of defense.

You can ensure you're using obscurity appropriately by also implementing standard access controls, and just generally following best security practices. Remember: if the only thing between you and the hacker is obscurity, then the only thing between the hacker and you is time.

If you're interested in upping your security skills, check out my other post on how to get into penetration testing.

Happy hacking!

This post was originally published on explainhownow.com

How to Find Subdomains on a Website (And Why You Should)

Kat Maddox — Mon, 25 Mar 2019 04:51:35 +0000

This is a guide to discovering website subdomains. I'll be going over the basics of what subdomains are, why you should be searching for them, and how to actually find them.

Assumed knowledge:

Basic Linux/Unix commands

What are Subdomains?

On the surface, a subdomain is just an additional, prepended part to a domain name. In the example "dev.mytotallysecurewebsite.com", "mytotallysecurewebsite.com" is the root domain and "dev" is the subdomain.

As a developer, creating subdomains allows you to make a totally independent site, but still use your root domain. For example, it's common to create a subdomain where you test new features that aren't ready to be deployed on the official website yet.

Development subdomains are often used to "hide" new and untested features. By just visiting mytotallysecurewebsite.com, an average user has no way of knowing that something like dev.mytotallysecurewebsite.com exists.

Why Should I Find Subdomains?

Usually, a development/testing subdomain is the developer's dirty little secret. Many companies will put a lot of money and effort into making sure their root domain is as secure as possible, but then totally neglect their subdomains under the assumption that they'll never be discovered.

But without proper controls such as firewalls, subdomains will eventually be found. You can't hide anything from Google - or a particularly curious hacker.

If you're a developer with "hidden" subdomains, it's good practice to run your site against some subdomain enumerators. Because if you can find it, someone else probably already has.

As a pentester, subdomain enumeration is going to be a critical part of your reconnaissance. Subdomains are likely to contain A LOT more vulnerabilities than the root domain. Searching for subdomains is one of the first things I do when deciding how I'll be testing a website.

Find Subdomains Using Google

I don't know why you'd do this instead of just using an automated tool. But here's how.

Using Google's "site:" filter, we can see some of the subdomains Google has discovered for a site.

We can then add the "-inurl:" filter to exclude the subdomains we've already found, allowing us to see more.

You can keep iterating like this until you run out of subdomains, or get bored and just use an automatic tool instead. There are hundreds of decent subdomain enumeration tools, so instead of just dumping a bunch of them on you, I'll list only the ones I regularly use. Please don't yell at me if I missed your favorite!

Disclaimer: some of these tools are brute force and will trigger alarms. Alarms can be fine in some cases, but unideal in others.

Censys.io

Censys.io is a pretty awesome tool that gives you a lot of information about a website. It can be used to potentially find subdomains with the following search string: https://censys.io/certificates?q=.examplesite.com

There's also a decent tool on Github for automatically finding subdomains with Censys.io certificates.

Pentest-Tools

Pentest-Tools is another web app that finds subdomains. It's pretty easy to use - just type in the root domain and hit scan.

Aquatone

Aquatone-discover is one of my favorite subdomain tools. It takes a bit of time to run, but it's generally pretty robust and will yield a lot of results. Usually, I'll run Aquatone-discover first, and then get the other tools going while I wait for Aquatone to finish.

Sublist3r

Sublist3r is seriously amazing. Sublist3r uses open-source intelligence to find subdomains and will usually give you results within minutes. It's great for when you're itching to get started. By the time my other tools are done running, I've usually already taken a quick look at all the domains Sublist3r has given me.

Scavenging

Face it - you're probably not the best hacker out there. Anything you're doing, someone else might have already done better.

One of the things I like to try is Googling "site:github.com hosts example.com", or just "site:github.com" with one or two subdomains that I've already discovered. If you're lucky, someone has probably already made a dump of subdomains for the site you're testing (or unlucky, if this is a site you own).

Apart from searching in Github, Pastebin can have results too. This is a great way to save yourself a bit of effort if you're doing bug bounties where many pentesters have already checked out the site.

Putting it All Together

If you're a web developer and have subdomains, runnings scans on your website is a great way to check how exposed you are. Don't assume that no one will find your subdomains just because you've configured your robots.txt.

If you're a pentester, this is a vital step to understanding the attack surface of your target. If you're doing bug bounties with wide scopes, sometimes it's worthwhile to even ignore the official domain altogether and only focus your efforts on the subdomains.

Happy hacking!

This post was originally published on explainhownow.com

How to Learn Penetration Testing: A Beginners Tutorial

Kat Maddox — Fri, 15 Mar 2019 11:57:02 +0000

Disclaimer: Hacking is a difficult skill to learn. You will not become a good pentester by just doing a few online courses. You will not become a good pentester by just installing Kali Linux and learning how to use the tools. This is a challenging path, wrought with endless frustrations, and you will not learn how to travel it well within a day - a month - or even a year. However, if you're determined, you'll find pentesting to be an incredibly rewarding field and you might never want to leave.

In this tutorial, I'll specifically cover the web application hacking side of penetration testing. This is a guide for ethical hacking. If you're doing the unethical sort, I'd really rather you not. Or at least give me part of your profits, please.

Assumed knowledge:

Basic technical background (Unix commands, some software development skills)
Intense desire to break things

0 - The Background Knowledge

Some CS101 knowledge is a must. Trying to learn how to hack without even being comfortable with Unix commands wouldn't just be like trying to run before you can walk. It'd be like flying an A380 without knowing which direction up is.

If you try to jump into pentesting without the necessary prior knowledge and "fill the gaps" as you go along, you'll struggle needlessly. Here's what you'll need to know:

How to Linux: The main power of Linux/Unix for coding and pentesting comes from the terminal and the sheer number of tools available. You can try to do everything you need in Windows, but it's not going to be easy - and if you're getting into pentesting, you'll need to know some Linux eventually. Trust me: if you get a job in security and your coworkers find out you've never used Linux, they'll laugh at you forever.

You have three main options here:

Get an install of a Linux distribution (such as Ubuntu). Your best option for this is to download a virtual machine software where you can contain your Linux install (links down below).
Keep using macOS, if you have it. You can make do with this since the terminal and tools on Macs are pretty much the same as Linux.
Use Ubuntu on Windows 10. I'd consider this the worst option for a beginner because it can be pretty unreliable when it comes to installing tools, and getting the GUI to work can sometimes be a nightmare.
VirtualBox: Free virtual machine software
Ubuntu: Decent Linux starting distro
Install Ubuntu in VirtualBox
Unix commands for Beginners

How to Code: Now that you have your environment set up, we can get to the fun bit! Learning some basic coding skills is essential to pentesting. If you want to learn how to break it, first learn how to make it. For web application pentesting, you'll want to learn some full stack stuff such as HTML, CSS, Javascript, and Python. Python has the added benefit of being a great language for scripting and will allow you to write your own pentesting tools (exciting!).

1 - Set up Your Environment

If you're a dev, you probably have your perfect setup already. Gratz! The way to go here is usually Linux or Mac. Personally, I use Ubuntu on Windows 10 (sue me) but only because I know all my favorite tools work on it.

Many beginners start with Kali, but I recommend against this. Part of becoming a confident pentester is building your library of tools. Kali hands you a bunch of tools, none of which you'll really understand and appreciate.

But whatever you're doing, it's absolutely crucial that you have a comfortable setup. Take some time now to fix any issues you might have in your setup (like bootloaders, window managers, GUI, etc). Pentesting can get messy when you have countless windows and complicated tools open, and the last thing you need is your own environment working against you.

2 - Learn the Theory

No way around this one. Even in just web application hacking, there's a whole breadth of knowledge you need to know. I'd split web hacking knowledge into two categories: The Basics, and the Nifty Tricks. The Basics are what you should learn first from books, videos, online tutorials, etc.

Unfortunately, given how quickly the world of hacking moves, most competent websites are already secure against The Basics (but you still need to know them!). The Nifty Tricks are the real moneymakers. You'll learn these later through browsing experienced pentesters blogs, joining ethical hacking communities, and obscure Youtube videos. If you're the first to discover a Nifty Trick, you get a place in The Hall of Fame and maybe lots of money.

Here are some great resources for The Basics:

The Web Application Hacker's Handbook: This is a great starting point. This covers almost all the basics you need. But don't bother with the "lab" that comes with the book.
OWASP's Testing Guide: OWASP is a key player in web application hacking, and this guide is immense. It has a lot of what you'd need to know.
LiveOverflow on Youtube: This guy is great - he covers a lot of The Basics and also plenty of Nifty Tricks.
Hacksplaining: Lots of info on different vulnerabilities.
SecHub: A compilation of a bunch of different exploits, with writeups too! Super cool.
Learn the HTTP TCP/IP Model, basic networking, and packets. You'll need this, trust me.

Once you've learned and practiced The Basics (more on how to practice in the next section), you can move on to learning some Nifty Tricks. Some resources:

DEF CON videos are great.
Vulnerability writeups: There's a lot of places to find them, and Medium can be a good one. Check out r/Netsec too. Also Google the vulnerability you want to learn more about with the word "writeup" or "POC" appended, e.g. "XSS writeup". You'll find posts from very clever people about new ways they've found to exploit stuff.
Look for pentesting communities and join them. Hacking, surprisingly, is a very social field, and a lot of cool tricks can be learned just by talking to other pentesters.

3 - Practice with CTFs and Wargames

This is the fun bit. Once you have some theory down, you can start practicing by doing hacking challenges. These are vulnerable web applications with hidden "flags" that you find by exploiting the application.

CTF (Capture the Flag) competitions are live events with scoreboards and teams, while wargames are less competitive and are more like playgrounds to practice your skills on.

Check out CTFtime for current and upcoming CTFs, although most of these will be too difficult for a beginner. Good wargames are OWASP's WebGoat and OverTheWire. Also check out OWASP's Juice Shop, Hacker101 CTF, Hack The Box, and Google's XSS game.

While fun and a great way to learn, note that the skills you need for wargames/CTFs are somewhat different from the skills you need for real-life applications such as bug bounties. It's possible to be a top scorer in CTFs, but be utterly incapable of doing bug bounties (this was me for a while) and vice versa.

Wargames are to bug bounties what Civ5 is to running an actual country. Wargames teach you some excellent strategy and puzzle solving skills, but real life is a different landscape - more on this in Section 5.

4 - Get Good at Scripting

This will make your life much, much easier. Python is amazing as a scripting language, especially for hacking. A lot of CTFs and bug bounties will require brute force actions such as sending many packets and hashing, all of which can be done easily by writing your own Python scripts.

Check out pwntools, a Python CTF framework. It simplifies exploit writing! Here's how you send packets.

I recommend making a folder where you keep your own Python scripts and build on them over time. I really can't understate how much time this will save you.

5 - The Real World and Bug Bounties

At some point, you'll get the flag for your first moderately difficult CTF challenge without having to Google the solution. And you'll feel amazing. Likely, you'd have spent hours and hours on it, and finally figuring out the answer on your own will be a feeling that'll get you hooked on pentesting forever.

You're a hunter now. Fierce. Unstoppable.

You might even think that you're ready to start making money now. But once you check bug bounty sites, you'll realize you have no idea what you're doing. There are no clues telling you where vulnerabilities are. There's such a wide attack surface that you don't even know where to start. And thousands of better hackers have already wiped the site clean.

As disheartening as it might be, this is the point where the fun really starts. You're out of the playground and ready to play with the big kids now. A good starting point is watching this DEF CON video I linked earlier and digging into finding good tools and more Nifty Tricks.

Now is the time to start learning web reconnaissance. It's covered well in the DEF CON video, and you'll learn more about it as you build your library of recon tools.

6 - Know thy Tools

Tools don't make a hacker. But you're probably not going to get too far without them.

I recommend starting off with just downloading a couple of the "mandatory" tools like Nmap and Burp Suite. Nmap is a discovery tool that finds hosts and open ports on domains, generally giving you a good feel for what the network looks like. And Burp Suite is your new best friend. Seriously. It's the #1 multitool of web hacking. Its main use is capturing and editing packets, but it does so much more. I really can't give it justice in this blog post - just google it and watch some tutorial videos.

After those two, it's up to you to find (or make) the tools that suit you best. Here are some of my favorites:

Sublist3r: I'm absolutely in love with this subdomain enumerator. It's crazy quick and finds a bunch of stuff.
Aquatone: Similar to Sublist3r but much more robust. Trades speed for power; I usually run Sublist3r first and then keep Aquatone in the background.
dirsearch: Directory bruteforcer.
LinkFinder: Discovers endpoints in Javascript files.
recon-ng: An entire framework for web reconnaissance that does pretty much everything. Will probably walk your dog and cook dinner for you if you find the right setting.
SecLists: Not a tool per se, but a collection of lists for bruteforcing. Pretty much a staple of web pentesting - I'd almost put it in the mandatory section.
Spotify hacking mixtapes for feeling cool

7 - Keep Hacking

I told you it'd be difficult, didn't I?

Pentesting is challenging, confusing, and overall just frustrating. But if this is something you really want to do, you'll find ways to overcome all of that.

Try to join communities, such as the ones on Twitter and Bugcrowd, since the journey is always more fun with others.

And remember: this is a field that really matters. It's rewarding, and you'll be doing legitimate good for the world. Blackhat hackers are learning every day too, and the ethical hacking community needs all the help it can get. Good luck, and godspeed!

This post was originally published on explainhownow.com

Quick Tips for Coding Interviews

Kat Maddox — Wed, 13 Mar 2019 21:31:48 +0000

Coding interviews suck. I've gone through plenty, including some with Microsoft, and I can confidently say: I hate them and I think they're a terrible idea. Unfortunately, they're not going away anytime soon, and if you're here you've probably got one coming up soon. Here's how to survive it!

1 - Be Prepared

Make sure you refresh all your first-year compsci knowledge. Many coding interviews, particularly with Microsoft in my experience, will want to see you demonstrate knowledge about sorting algorithms, operations on binary trees, recursion, linked lists, etc. You know - all that boring stuff you covered years ago and then forgot.

Get on HackerRank and start doing some challenges, and make sure you pick one language to focus on so you're not messing up your syntax during the interview. I use Python since it's easy to write and most interviewers should accept it.

Other than that, read up on the theoretical concepts such as Big O Complexity, since it's not uncommon for interviewers to ask questions on this.

2 - Don't be Overprepared

Yes - it's possible, and it's just as bad as being under-prepared. I define this as spending any more than 40 hours in a week studying, but YMMV. There are three key reasons why you shouldn't overprepare for coding interviews.

Reason 1: Studying too hard for long stretches of time is inefficient. Research shows that your brain needs rest to encourage memory retention. There's a certain point where studying just doesn't help you anymore, and it looks a little something like this:

Instead of cramming for your coding interview (if it's not too late already!) just practice for a few hours a day, about a week or so in advance. You'll learn better, and it'll be much less of a chore.

Reason 2: You risk confusing yourself or panicking mid-question. If you fill your head with too much information, you'll find it hard to pull out the stuff that really matters when you most need it. Even worse, the more you prepare, the more you build up the expectation in your mind that this will be difficult. You'll stress yourself out, and if you're anything like me you'll be more likely to panic during the interview.

Reason 3: You'll look fake, and you'll feel fake. Managers can tell when you're overprepared for an interview. If your answers are too rehearsed, they'll know that you've memorized solutions, and they'll be less likely to trust you. Similarly, you'll feel like a fake yourself. You'll siphon the fun out of coding (remember why you're doing this in the first place!) and you'll lose confidence in yourself and your abilities. Coding interviews suck - don't make them suck even more by torturing yourself too much while preparing.

3 - People Skills Are Still Important!

You can't escape it. Even in a coding interview, managers will want to see that you have decent communication skills and that you'll be competent at working in a team. You can be the best coder in the world, but if the thought of interacting with another human makes you recoil back into your Vim set-up - you won't do well in the interview.

Unfortunately, improving this just comes with experience. Going to networking events and interviewing with companies often will put you on the right track. Check out places like Meetup.com for networking events where you can practice communicating in a professional environment.

4 - Remember That You Have Value

This is an important, but often neglected tip. Remember that not only is the company interviewing you, you are interviewing them. Starting from now, every day until the interview - tell yourself that you are interviewing them. Remember it during the interview whenever you're getting anxious.

You'll have a more casual, confident attitude that'll make you stand out from the other candidates. This takes some time, but it's the main thing that took me from desperately begging companies for jobs, to getting multiple offers and choosing who I want to work with. It takes practice and might feel weird at first, but try it and watch as it pays off!

This was originally published on explainhownow.com

Quick and Easy Guide To Making a Blog with Jekyll And Namecheap

Kat Maddox — Sun, 10 Mar 2019 03:05:25 +0000

Install Ruby if you don't have it yet.

sudo apt update
sudo apt install ruby-full

Now install Jekyll.

sudo gem install jekyll

Create a new Jekyll project.

jekyll new blogname

(note: if you want to use a template, instead of using the above command, just git clone the template you want)

Now, just cd into the folder Jekyll just made and check out the _config.yml file. Change all the applicable stuff, like name, email, and whatever else if you're using a template. url can be changed later once you've bought your domain.

To make a post, create a markdown file in the _posts directory, in the naming convention of yyyy-mm-dd-name-of-post.md, for example 2019-03-10-how-to-jekyll.md. The format of the file should look like this:

---
layout: post
title: Welcome to Jekyll!
categories: jekyll
---
Post content goes here.

If you're using a template, check the sample posts to see what other parameters you should add in the top section.

You may need to run the following to make sure you have all the required dependencies:

bundle install

After all this, you run this to see your website in action:

bundle exec jekyll serve

Now your website should be online at http://127.0.0.1:4000/. Make a repo for it in Github, so that we can set it up with Github Pages later. Push the project to your new repo.

git add .
git commit -m "hello world"
git remote add origin [repo_url]
git push origin master

Next, we want to vomit this onto the internet. I'll be using Namecheap in this guide, but any other domain provider should work.

Once you buy the domain, you'll need to change the DNS settings so that it can be reached. In Namecheap, you can go to the Dashboard, select "Manage" next to the domain name, then "Advanced DNS", and add the following records, changing my Github username to yours.

A Record    @   185.199.108.153
A Record    @   185.199.109.153
A Record    @   185.199.110.153
A Record    @   185.199.111.153
CNAME Record    www     you.github.io.      30 min

Now go to the settings page of your blog repo, which should be https://github.com/[yourgitname]/[yourblogname]/settings.

Under the "Github Pages" headline, add your custom domain (should be in a form similar to www.blogname.com) and hit save. Don't forget to change url in _config.yml to your domain in the form https://www.blogname.com. It could take an hour or so for the DNS to resolve, but eventually, you should be able to see your site at the domain name you bought. Yay! Great job. Note: actual blog content sold separately.

Additional Tips

Templates

The above should work, but you're cool so you want a cool blog. Like mentioned above, the steps for getting your blog to work on a custom template should be exactly the same, but instead of jekyll new blogname you just git clone the template and cd into it, doing everything else from there. You can find a wide variety of Jekyll templates from these sites:

SSL

Next, you'll want your blog to have SSL, to save your readers the embarrassment of anyone potentially finding out they're on your site. And from content defacement as well, I guess. Fortunately, Github Pages does this easily for you - under your git repo settings, just tick the "Enforce HTTPS" box under "Github Pages". Don't buy Namecheap's SSL certificate, you don't need it.

Images

In your root project folder, create a folder named assets, and within assets, make an images. Put images there. Then, in your post content, add something like this:

![alt_text]({{static.static_files}}/assets/images/image.png)

Automatic Sitemap

You can make Jekyll automatically generate a sitemap for you! Add the Jekyll Sitemap Plugin to your project (instructions are in the readme).

If you're using bundle exec jekyll serve to build your site, you may encounter an issue with your sitemap listing your urls in localhost terms instead of using your domain name. Instead, try building your site files with bundle exec jekyll build. If you find that this still doesn't work, enter the following command: JEKYLL_ENV=prod jekyll serve

This post was originally published on explainhownow.com