Penetration testing is a popular topic within the security field. And being a penetration tester can be really fun since you get to act like an attacker without actually being bad. In this article, we want to give you a brief introduction of what penetration testing is, what to look for when starting out  and some tips on how you can learn more.




Why is basic penetration testing useful for you to know?

Penetration testing or security testing is an attempt to evaluate the security of an IT system by safely trying to exploit vulnerabilities. Usually, this kind of work is associated with penetration testers, whose job is to help organizations identify and resolve security vulnerabilities. 

But why is this also relevant for developers?

There is a principle called "hack yourself first", which refers to how developers should build up their own cyber skills. In that way, they can proactively seek out security vulnerabilities in their own web applications and fix them before they are exploited by someone with bad intentions. This kind of mindset makes us more aware of risks when we are writing code and able to create more secure and robust systems. 

Penetration testing can be split into two main categories: (web) application  testing and infrastructure testing. In this article, we will mainly provide som tips on how to get started with (web) application penetration testing.

What tools do I need?

First, it's worth to mention that it is necessary to have some understanding of information security, networks and IT systems to be able to perform even the most basic security testing. Thus, the tools that we present in this article will (unfortunately) not magically make you a penetration tester. However, to have some tools in your toolbox is very useful and also sometimes necessary to help you along. 

The good news is that you don't need access to advanced tools in order to perform basic penetration testing of your own application. The DevTools available in browsers have a lot of functionality that can help you get started, and we will show you some examples of how you can use it. 

However, if you want to take it up a notch, a proxy tool like Burp Suite or OWASP ZAP can be very useful to intercept requests between the browser and server, and also to modify and replay them. In addition, Offensive Security Ltd maintains a selection of Kali Linux distributions designed for penetration testing, which contains a wide range of various tools. Some examples of useful tools are Nikto, Nmap, Dirb, SQLmap, etc. 

What to look for?

So where do we start? A very good place to start is to familiarize yourself with the OWASP Top 10 Web Application Security Risks, which is a list of the most critical risks of web applications that should be minimized to increase the security. Then, you can start with the security testing. Here, we outline some of the basics on how to start. 

1. Gain an overview of your application

In order to be able to identify vulnerabilities in your application, it is necessary to gain an overview over the application's functionality and identify possible entrypoints.

By scanning through the application, you can identify sites or subdirectories that should be hidden for specific users, or possibly discover information in the GUI or in the source code that should not be available. You can manually map out an application by using DevTools, for example by looking into the source code or the items available in storage (Local Storage Session Storage, Cache Storage Cookies, Tokens etc). Additionally, you can take a first glance at which network calls are performed in the Network tab. 

Burp Suite and OWASP ZAP can also assist you with the mapping of the application, both with manual mapping or by providing you with tools to perform automatic spidering/crawling of your application or passive and active scans for known vulnerabilities.

Dirb is another useful tool for mapping out a web application. The tool is a Web Content Scanner and works by launching a dictionary based attack against a web server. By analyzing the responses we can identify available sites and files.

NB: Automatic functionality should be used with caution during testing. Be aware that spidering will request whatever is available and may requests links that can be dangerous. The same applies to automatic vulnerability scanning, as these tools manipulate request and inject parameters in order to simulate attacks to find known vulnerabilities. This can put the target application at risk.

2. Identify and test all input fields

The second step is to take a look at some of the functionality present in the application. Functionality where users can interact with the application are always interesting, for instance input fields. Are you able to trigger errors from the server by interacting with the input fields? These can be reflected either in the GUI or in the DevTools console and can leak information or even potential weaknesses in the application 

Injection vulnerabilities are typical vulnerabilties that can be present where an application accepts user input. Injection attacks happens when an attacker sends invalid data to a web application with the intention to make it do something other than what the application was programmed to do. 

Most likely, you have implemented some kind of validation and/or data sanitization in your application. If this is the case, it can be interesting to test whether it is possible to bypass this validation, either at the client side or the server side in order to perform injection attacks. 

Beneath is an example that illustrates how SQL injection attacks works. The example is fetched from the "OWASP Juice Shop - Insecure Web Application for Training" learning platform: 

By giving ' as input to the email field and any string for password, we provoke an error and by inspecting the network tab in DevTools we can see in the SQL statement that is used to log in a user. 

Now we know the SQL query related to logging in, and we can try to manipulate this to always return true in order to bypass authentication. We see that by using ' OR TRUE -- as email input and any string as a password, the resulting statement will be:

"SELECT * FROM Users WHERE email = '' OR TRUE -- AND password = '1aabac6d068eef6a7bad3fdf50a05cc8' AND deletedAt IS NULL"

This will always return true, since

the ' will close the email input field 

the OR TRUE returns the boolean value true

the -- comments out the rest of the SQL statement

We are now logged in and have bypassed the authentication. Additionally, since the statement logs in the first user in the database, we also have admin login. 

This is of course a very simplified example, but it demonstrates the principles that SQL injection attacks exploits. 

3. Manipulate requests or data

An application may also leak more information than intended. When fetching data from the backend, the response may contain further information than what is revealed in the user interface. One way to discover this is by inspecting the network tab in DevTools to see if you get access to more information either about the data structure or other information that can be used to brute force the endpoint. Additionally, by using tools such as Burp Suite, requests can easily be intercepted, modified (e.g change the id of the data object to be retrieved), and replayed to see if this alters the behavior of the application.

In the following example from OWASP Juice Shop we can intercept and modify a request with Burp Suite to view another users shopping basket. 

By intercepting and modifying the GET /rest/basket/1 with another number (in this case 4) in the path, we can now see the content of user number 4's basket. 

Again, this is a simple example, but there is a reason why broken access control and sensitive data exposure are mentioned on the top of OWASP's list of application security risks. By using available tools and similar techniques to modify requests for different resources in the web application you might be able to discover some security flaws that should be mitigated. 

Common known vulnerabilities

As developers, we often use third open source party packages or services in our applications. These can contain vulnerabilities we are not aware of.

Luckily there exists tools which scans and identifies common known vulnerabilities. As mentioned before, OWASP ZAP and Burp Suite are such tools, but there exist further commercial and open source alternatives covering applications and operative systems. OWASP has a list of examples of these here.

Resources

In this article, we have introduced basic penetration techniques and tools in order to test the security of a web application. As developers, we have gained some awareness of how flaws in our application can be exploited. 

Want to learn more? Below we have listed some useful resources you can use to challenge yourself and improve your skills in penetration testing. 

Training areas

There are tons of training arenas and cheat sheets out there! OWASP Juice Shop is a good example of an insecure web application where you can find examples of and exploit OWASP top 10 vulnerabilities. Other resources include Vulnhub where you can download vulnerable VMs and Hack the Box.

Guides and cheat sheets

OWASP Top 10

OWASP Testing Guide

SQL injection cheat sheet by Portswigger 

Kali Linux tools documentation

Disclaimer: You should only perform penetration testing on applications and systems that you have permission to do so on. Always ensure that you have read the guidelines and rules for images or bug bounties before starting to test. 

Penetration Testing 101

How did the container become so ubiquitous in application hosting? Most people know that they're used to run an application, but can't a virtual machine also do that? Why did we ever move away from hosting our applications on a physical server ourselves?

Let's explore how we have previously hosted our applications, and why we transcended into containerised software!

To figure out how we have arrived at almost exclusively using containers to host our applications, let's explore what we previously used to run our applications. What brought our applications from physical servers onto virtual machines, and from there further onto containers?

Back at the start of software development, companies that had applications that was crucial for their businesses needed somewhere to host and run them. They couldn't just sign up for an account at a cloud service provider like we do today, and spin up whatever instances with whatever specifications they needed. The businesses needed to procure actual physical servers.

The buyer of these physical servers had a few things to consider. They had to consider how scalable the server would be, how many users the server should be able to handle, and how much disk space it needed to possess and so on. 

Whichever server was obtained chances were that it would either end up with unspent potensial, or down the road having to be replaced by a more powerful one if the hosted application turned out to be more computing intensive than first thought. Substituting it with a new server could also mean downtime, and of course additional cost in the form of administering and installation of the newly bought machine.

Maintaining a server once you have it isn’t free either. There are a lot of operational costs associated with having a server of your own standing around. Moreover you will have to pay licences for the operating systems you are running.

Also, chances are your business would want to run more than the one application currently in production. There is a possibility that the two servers need different operating systems, dependencies, and might need to access the same resources, which again would mean that they will not be able to run together on the same server.

You end up with either having to buy different servers to serve each new application, or unique servers with a bunch of different apps running intricate dependency-management that is hard to maintain. With both options comes increased operating cost, complexity, and management of both the physical and the virtual.

Physical servers are obviously painful to both obtain, run, and maintain. So where do we go from here? Enter virtual machines (VMs)!

Virtual machines are in a simplified definition, an abstraction of the physical server. On the hardware of the physical server lives the operating system, and in the operating system lives the VMs. The OS runs something called a hypervisor, which can be described as a virtual machine monitor. This hypervisor could also be described as an emulator, and it virtualises the hardware of the physical server it runs on.

When running a VM on the server, you're no longer constricted to one application per physical server, or maybe the equally painful alternative—many applications in one very confusingly configured and complex system. The virtual machines on their respective virtualised servers are running their own OS, referred to as a guest OS, in contrast to the host OS which is that of the physical server. Running an OS of their own enables them to function as an actual server, and you can perfectly fine run different guest operating systems on the same host machine.

Even though virtual machines come in very handy, they are not without problems. By running an OS of their own, the VMs offer a lot of overhead computations and processing power just to keep the VMs alive, without even running the application that they were set up for.

What the hypervisor basically is doing is splitting up the resources of the server. As a consequence, the VMs can't really share any resources if one of them receive very little traffic. The resources of the server are pre-distributed and can't be dynamically allocated between themselves on a requirement basis.

From the VM's perspective, they are running on their very own server. They all need their own respective operating system, which causes the hosted application to take up much more resources than the application itself. It needs a dedicated amount of CPU and memory, and if the application uses way less memory than expected, it just idles.

So VMs are a huge improvement to just the servers as they operate by themselves, but still poses some issues. Enter containers!

We've gone from unaugmented physical servers which only have the ability to run one application at a time, to moving onto virtual machines which is encapsulated in their hosts' OS and conceptually are their own machines. VMs still contains some complexity in the form of increased use of resources.

So back to containers! What are they?

Like a VM, the container is also a virtualisation. Not a virtualisation of the hardware on the server it runs on like the VM, but of the actual OS that the server is running. As VMs share the physical hardware of the server, containers can share the OS on the host machine. Also like the VM the container thinks it is running on its own dedicated hardware and operating system.



A container runs on top of a container engine which offers an API, thus making the enclosing system able to communicate with the engine to orchestrate the containers within.

Containers can be described as self-contained packages, and the applications running inside the container and its dependencies are packaged together. This makes moving around such a package very easy.

Since a container virtualisation does not need its own operating system, we can immediately see the resources saved by using this as opposed to VMs. While a VM takes up disk usage space in the gigabyte class, a container uses megabytes.

In addition to a decrease in the use of resources it will also be much faster to set up as we won't have to install a dedicated OS in every container. So no matter how many containers that lives on our server, only one OS will have to be administered.

Containers also thankfully works, in a different way than VMs when it comes to sharing of resources. When a container is resting and no longer in use, its resources can be allocated and utilised consecutively and dynamically by other containers in the same system.

Of course there are drawbacks for containers as well, but as long as we’re aware of them we can make the correct choice of when to choose what. A quite intuitive drawback to mention on containers is that persistent storage on disk can be quite tricky. As VMs are in control of their own OSs and conceptually are their own servers, persistent disk storage is a much lesser feat in the case of a VM.

We've climbed the evolutionary ladder of application hosting from self-managed physical on-premise servers, to VMs that can be run either on-premise, or in the cloud. Containers are lightweight, efficient, portable and neatly packaged so that they contain an application together with all of its dependencies, making it a finished piece of software package.

We've certainly come a far way from running applications on our own on bare metal!

The evolution of how we host our applications

When was the last time you evaluated how your mood, a given day, affected your fellow team members? When was the last time you started doubting yourself because someone on your team had a sloppy, yet negative comment about you?



Regardless of how competent and skilled your team members are, there is still a chance that only a single person could destroy the productivity of the group - or "spoil the barrel".











This article is about some types of people you might work with, that drive the entire group nuts, and the power of individuals to destroy the team dynamics.

A podcast well worth listening to is This American Life. I like this podcast because it tells real stories from the States, and in these stories we meet interesting people. In addition to podcasts, I also do some reading. Recently I have read No Rules Rules – the Netflix biography –  and to my excitement one of the citations in the book was from episode 370 of This American Life. So I just had to listen to it!



In this episode we meet Will Felps, who is an assistant professor of management. In 2008, when the episode was published, he had just conducted some research on group dynamics where he investigated the question





could one person ruin a workplace?





Briefly explained, the study was conducted on college students in groups of four. Three of the members were college students, but the last member was an actor who would, across the different groups, play the role as a member with one of the following “bad apple” behaviors in a group:



Being a jerk – a person who attacks or insults others,



Being a slacker – who does less than they can,



Being a depressive pessimist – a person who is mentally broken down.



The groups were handed exercises to make some basic management decisions. They would be scored, and there would be a prize of $100 per person for the group that did the best.



While acting a jerk, the actor would burst out comments like “Are you kidding me?” or “Have you ever taken a business class before” - to kill the other group member’s spirit. While acting as a slacker, the actor would put his feet up on the table, use his cellphone or starting to eat a sandwich. Finally, to act like a depressive pessimist, the actor would put his head down on the table and radiate negativity and hopelessness.



And the results for the unfortunate groups with a bad apple showed 30 %  to 40 % drop in performance compared to groups without the bad apple. The members with a bad apple would argue, fight and not share constructive and relevant information to solve the assignment they were given. In one of the groups who had a slacker as a member, the response to the slacker’s behavior was that someone would eventually say “Let’s just get over with it”. They would just mark down anything on the assignment and then give up.



A highly interesting finding from the experiment was that fellow group members to the jerk would start to take on the jerk’s characteristics. When the actor was acting a jerk, the other group members would become jerks too. And sadly the bad behavior wasn’t only directed back to the actor, but also out to each other. This does not sound like a fun group to be a part of…



But luckily, there was a happy story from the experiment!



There was one group where the actor didn’t spoil the barrel, and which performed well. In this group there was one person who was a particularly good leader. This person would engage all team members and defuse conflicts. By respectful inquiry, asking open questions and being a good listener, this person would contribute to the group’s result in a positive way. 



This positive story has become my personal key takeaway from the experiment. Being an inclusive team member who engages all team members could eventually have a positive effect on the performance and collaboration inside the group.



In addition to the research on groups performed by Will Felps, the podcast episode also have an interesting part on people refusing vaccination - it's worth a listen!



I hope this post gave some useful perspectives of how you can avoid being a jerk, how to become a better team member, leader or just being a better person - or just a tip on a great podcast you can listen to. Have a Merry Christmas!

Are you the bad apple?

Drypp er en lavterskel podcast fra Bekk.

En liten gjeng samlet inn heftige påstander og inviterte til Drypp-innspillingskveld på Trondheimskontoret - med julebrus, godis og god stemning. Resultatet ble seks episoder med brannfakler. God lytt.

Brannfakkel - Er utviklere ikke kreative? (Del 2 av 6)

Another meeting where everyone feels like this is a waste of their time. Why could we not just have done this over email? Do we have to get everyone into a room (or even worse, a zoom room) to figure out whether or not to start on this task next week?

Photo by Rodeo Project Management Software on Unsplash

Well, I think the answer is more often than not "yes". It didn't have to be this way, but we made it like this, and now we reap what we sowed. There is a way out, but to get there we must understand why we sit through so many of these "pointless" meetings.

Why all the meetings?

So, your calendar is full of meetings, half of which you have no clue why you have been called in for, and the other half probably make you long for the sweet relief of Friday afternoon. This is your life now, unless you can find some way to make the rest of the company see the light. But why aren't they? The truth is, they know as well, but we have made a series of bad decisions along the way, making these meetings necessary.

Our emails are too long (or too short)

If this meeting could have been an email, how would that email have looked? Probably a mile long! With references, links to external and internal sources, 15 people on CC, and a dozen questions that needs answers. Just imagining it is enough to raise my blood pressure! That email was a pain to write, and now, 15 people have to take the time to read it and comprehend it. Taking into account the varying time available for this in everyone's schedule, it will take a lot of time for some to read it.

In the meantime, several answers just as long as the original email has arrived in your inbox, and we are off to the races. While you type up your 5000-word answer, someone else answers, and you have to spend an hour revising your answer to incorporate the new information and arguments. This can go on forever, and at some point, someone will email the group saying: "Can we schedule a meeting to clear this up?". And just like that, we are back to meetings, but not before having wasted a week with back and forth emails the length of Ulysses.

But this is not solved just by shaving down your emails to three lines. We end up with the same problem, in reverse. People need more information to be able to make a decision. And you will end up with a mountain of incorrect assumptions to fill the gaps in your explanation.

Writing a concise summary of an issue, that does not leave out any details needed for the decision, is an art mastered by few. In the world of politics it is a skill more often seen, as career politicians can't be bothered to read more than absolutely necessary, but also must have all relevant information available. Their advisors are highly trained (and paid) for this exact reason. We must adopt this skill if we are to have any hope of moving decisions from meetings to email.

Emails asking for a decision to be made are ignored

Having received the aforementioned wall-of-text email, knowing full well that John from accounting will have a lengthy reply with at least 10 new issues that are linked to this and must be resolved as well, I do what most people do: I wait. And why shouldn't I? There are no rewards for answering first, no incentive for me to start writing my thoughts on the subject, maybe not even a reason for me to start reading the email until a couple of days later.

This contributes to lengthening the response time, causing the sender of the questions to doubt if email was the right forum for this decision. You can guess what happens next: Meeting time!

We ask for decisions just in time

Email is an asynchronous medium. This means that the participants don't have to be active and present at the same time. This is great to ensure that we don't bother people when they need to focus. But it also means that we need to allow for enough time between sending a question, and needing an answer.

I for one don't get a lot of emails where 1) an important decision is to be made, and 2) there is an ample amount of time to make said decision. It is usually a question of how fast can we have this answer, we needed to report this to the board yesterday. This happens because there is too little slack in people's workdays. In order to maximise performance and efficiency, most people are given way more tasks than they could possibly complete, to ensure that there is no "wasted time" in their days. But this also leaves no room for deep thinking or reflection when an important decision has to be made. Instead, it is easier for everyone if a meeting is called, as it is naturally time boxed, and if anyone questions your time spent in the meeting, you can usually blame the person who asked you to be there.

Some things are difficult to convey in writing

If there is one thing I think we have all felt during the pandemic, it is that some things have been objectively more difficult while working from home. Sometimes it has been difficult to put our finger on exactly what, but I think it has to do with how we as humans communicate. A lot of our communication is nonverbal. When we see each other on camera in two dimensions, in low resolution, and with an infuriating latency, a lot of information is lost. It is the same when making decisions over email.

How certain is Pete that the solution he has proposed is actually going to work? If we sat in the room with him, we might see a flicker of doubt in the eyes, or shifting in the chair. It might be easier to admit that we are uncertain when we can see an gauge the reaction of our peers, instead of having to send that "I don't know" into the void, and wait for hours or days for a reply. And some processes are so complex that explaining them all in writing is just not worth it, and we need to have a conversation where the participants can ask the questions they need clarified in order to understand, while we can skip everything that is common knowledge.

Writing so that we are understood in the same way as when we speak face to face is difficult. It requires us to know the person (or people) we are writing to, and we need to be thorough in our choice of words. This, in addition to my earlier point on writing with the correct level of detail, increases the difficulty of writing an email that can actually replace a meeting. If The Boss is the one who needs an answer, and her calendar is already pressured, the efficient decision from her point of view is to call a meeting! Instead of spending hours formulating that perfect email, twenty minutes of explaining usually delivers the same results.

Leaders have the power to call meetings

With the above in mind, there is no wonder people would rather call a meeting. But there is one more factor that makes this happen. When your boss sends you an invite to a meeting, attendance is not optional. When was the last time you hit decline on a meeting invitation just because you didn't think the meeting would be worth your time? Probably never.

We have a culture where the person calling a meeting is usually a superior. Either your team lead, or the person in the team with the most experience. Most companies also don't have any guidelines regarding meeting invitations, and whether they can be declined, negotiated, or must be accepted. Fearful of the consequences, the easiest think is to accept.

To make matters even worse, meeting organizers usually "asks" for the attendance of all the people they think are necessary to resolve an issue, or that might be needed, should a tangent arise that needs answering. This is of course understandable from their perspective: Organise one single meeting where the issue at hand is presented and resolved. Unfortunately, this ensures that most people in the meeting have nothing to contribute and gather no new or useful information.

What to do then?

Well, first of all I think we should be careful to dismiss meetings as generally useless, as I feel some might be prone to. Second, we must adjust several things about how we work, and how we write:

There must be enough slack in peoples workdays to enable both good writing, high quality thinking, and generally space for new ideas. Without this, there is no hope of replacing a meeting with an email.

In addition, we must all become better writers. Whatever your actual job, you must write with the intention and eye for details of a political speech writer. Weighing your words, ensuring they are appropriate for your audience, and bringing out the essence of the issue takes practice, feedback, and time.

When these things are in place, we must also create a culture where declining meetings (with a polite notice of why) is not only acceptable, but expected when someone feels they have nothing to contribute to the meeting. The person calling a meeting must be able to convey why each person in the invitation needs to be present. Without a clear reason to be present, the default should be to spend our time elsewhere.

These are not overnight fixes. It will require leadership, buy in from everyone in the organisation, as well as a good portion of hard work. But if we do it right, we can reclaim our time from meetings, and actually make some real decisions by email!

8-Dec

Today's posts

Penetration Testing 101

The evolution of how we host our applications

Are you the bad apple?

Brannfakkel - Er utviklere ikke kreative? (Del 2 av 6)

No, this meeting couldn't have been an email – and we're all to blame