The most common issues we see within IT-security

Most of the products you buy are aimed towards network and endpoint security. These will not be very effective against web application vulnerabilities. So, in this post, we shed light on the most common issues we see in our work, from weak network to user enumeration. Understanding these challenges is not only essential for IT professionals, but also for individuals and organizations striving to enhance their security posture in an increasingly interconnected world.

Bad Passwords

When using an application, one of the first things that you run into will be some sort of authentication. This is usually a username and password combination. And of course, the requirements differ greatly from site to site. It is quite common to see requirements for upper- and lower-case letters, plus maybe some numbers and special characters thrown in as well. Length is also a major factor. A good guideline to follow is to keep it long enough to prevent brute forcing and complex enough that it will not show up in a dictionary. A good, recommended length is a minimum of AT LEAST 10 characters. Preferably much more. 

We have come across numerous applications in which the only requirement was a length of six characters. So, a password such as “111111” would be perfectly acceptable. This would take even a low-end computer a short amount of time to crack a hash of this password. Not to mention, it is probably in a dictionary so brute forcing would be entirely possible as well. More on how passwords are cracked here.

Lack of strong SSL implementation 

A nifty tool to evaluate the current state of the SSL implementation, SSL Labs is quick, easy to use, and comprehensive. There is also the tool  SSL Checker , a more simplified version and easier for a non-technical to understand. It also offers the added caveat of checking SSL Security Headers. Now we will not go into all the details concerning the SSL/TLS implementation, that would require at least several more pages to this post. So, we will have to return with a separate post about it. If you really want to know more right now, then there is another nifty tool. They call it Google; we think it is starting to catch on! Or feel free to contact us and we will make sure that you get the correct information. 

 

User enumeration 

There are several common ways that applications will let you enumerate valid users. One of the most common and easy to do is through the login function. An Example: You go to log in to an application. If you were to type the correct name, but messed up on the password, and the response says, “the password is incorrect”. This is a clue that the user is a valid user. If you try a different username (that isn’t valid) and the response says, “Not a valid user”, you can now easily determine that the first user was in fact, a valid user. 

 For an attacker, this would be a good opportunity to try and brute force users of the application. Since the application will respond and inform you if the user is valid or not. 

 

XSS/HTML/SQL Injection 

The number one issue of 2017 and 2018 has been injections of various sorts. So, what can be injected? SQL Queries, OS commands, HTML content, whole pages of content and scripts. Where would someone inject this? Wherever a user input is required, or users can modify data, i.e., a text box, username/password field, search functions, feedback and comments fields, URLs, etc… 

 

Unrestricted file upload 

Uploaded files can introduce severe repercussions for the application as well as the file system. It is often seen that there are no filters on what types of file extensions that can be uploaded. If only one or two file types are needed, all others should be on the naughty list. 

Imagine, an application written in PHP, where the user can upload a profile picture. You would assume that this function would only allow for image files (JPG & PNG) to be uploaded. But other file formats are also allowed to be uploaded. In this case, since we are dealing with PHP (and PHP can interact with the OS directly), we upload some fun PHP code which will give us direct communication with the file system of the server itself. This pretty much can lead to more fantastic things happening such as compromise of information as well as possibly reaching further into the network. 

 

Broken Access Controls (Security by Obscurity) 

This happens when proper checks are not made for the entire site map. This will allow a user to access information that their user’s permissions should not allow (or completely unauthenticated). Imagine that you are browsing your time report application with your low privileged account, the only thing keeping you away from approving your own time report is basically cosmetics. The approval button is not viewable to your account, only for the administrators of the application. When in fact, if you knew the request data, you could approve the time report yourself. 

In this application, you and your company have stored some internal documents with what can be described as containing sensitive information. You access one of the pdf’s and download it, authenticated. If you were to log out from the application and then accessed that same URL for that document, and the file is accessible, then that would yet again be proof of Broken Access Controls.

 

Weak User/Group segmentation (Least Privilege Practice) 

Flat user/group permissions. It would be nice to live in a world where all are equal. But when it comes to IT this is an absolute no-go, but still a very common thing. All the accounts to an application or a network have equal privileges, with that comes chaos, especially if these credentials were to be compromised by an attacker. It is more or less giving the attacker the keys to the kingdom and is more commonly known as “a bad idea”. What needs to be asked here is, does Janice from accounting actually need access to the top-secret documents that are for Leann and Kurt? User roles should be assigned by least privilege practice, what you do not need to know, you simply should not know or have access to.  

 

Bad patch management / End of life management 

A great example of this issue is the WannaCry/EternalBlue outbreak on the 12th of May 2017. Infrastructure all around the world was affected by this vulnerability, companies of various sizes had their servers and computers infected with a cryptolocker. Total damage reported of over $8 billion across 150 countries, just from the WannaCry incident alone, according to IBM X-Force. I think this speaks for itself, if you maintain your own data and servers, you can control when and what to patch. With a third-party vendor, you do not have a clue to what they are doing. That is why this is a good question to any third-party vendor that you are considering using.  

 

Weak Network/Database segmentation 

We have had instances where we have been told that the network or database is segmented properly, at least according to the people that we have talked to. When we get back to them a while later, we have proven that such is not the case. Applications where the pre-production version and production version is stored on the same server as the “properly segmented” database. The actual segmentation of the database was in fact only that it was two separate branches in the same database. Which meant that the SQL-injection found in the pre-production application also led to a full compromise of the production database. This has also been seen for multi-tenant systems where several company’s data are all stored in the same database.  

If you want to know more about the most common attacks and how to bring security into the development process, be sure to join our webinar in September where we will delve into these key areas. Register below. 

ABOUT THE AUTHOR

Mattias-Recruiting

Mattias Döj is very easy-going guy and appreciates meeting and including new people. During his time in IT security, he has worked globally and traveled the world to perform a variety of penetration tests.

Webinar On-Demand

How to think and work with Application Security

Most of us understand that security is important but don’t really know how and where to start. In this webinar, we will talk about application security with a focus on bringing security into the development process, the common attacks, etc.

FAQ

Do you have a question about cybersecurity?

To avoid exposing your system to danger, you need to secure your applications, but you may not know how. We’re here to answer your most frequently asked questions on this subject.

Our recommandations