There are different types of methodologies and standards used in the IT world in order to create a baseline for secure operating practices. This not only involves IT infrastructure and software, but also the humans involved.
In our day to day work, we stumble upon tests where our clients lack secure routines in patch management, coding, testing and pure lack of understanding of the potential risks that are possible. It is our job to help them. To educate them where and when they need it. We, as security professionals, actually need to care about security ourselves, so they in turn will know that we care about theirs.
With the big shift to using other people machines (AKA, “The Cloud”) to support on-prem infrastructure, platforms, and services, new policies and procedures need to be considered. These “new” environments are often made to sound completely secure. While in and of themselves they might be, what you built on top of the foundation is a whole different story. You can build the strongest foundation, but if your structure sitting on top of it is falling apart… what’s the point?
This brings us to external third-party service providers. Most businesses are in need of multiple solutions for the day to day workflow. Not all of these needs can be met using internal resources or custom-made applications. Reasons can vary, but cost is usually a big factor in this decision. Either it is costing the company too much time with the current solution or designing something in house would be too expensive to build, develop, and maintain. If you can think of a problem, there is usually others that have that same problem. And more often than not, there will be a solution for that problem somewhere on any one of the various internets.
The big selling point is that it is a ready to use service, someone else is maintaining it. All you have to do is use it. This, of course, brings with it some potential issues on its own. You don’t have full control of what is happening. And why should you? You paid someone else to worry about that!
When you let someone else handle your data, you want to make sure it is being handled properly and securely. When approaching a company about their product, there are several things you should be aware of:
The Five N’s?
- Transparency
- Flexibility
- Encryption
- Security
Transparency
Many social media platforms which are “free” to use, and you have to simply accept their terms and conditions. If you are buying a product, you should have certain rights when it comes to what you are buying as well as a legitimate excuse to complain about it if something is not as it is advertised.
One of the first questions to ask the provider should be “What is your security policy? What are your security procedures? Do you have penetration testing done regularly, or at all? And can we see those reports?”. Yes, that is more than one. It’s not always so simple.
Our thoughts on this are… if they are not prepared for these answers, they are not putting security as a priority. If they are not willing to share their policy and procedures, they might not be putting security as a priority. If they don’t want to share any previous penetration testing results, they might be trying to hide something.
Flexibility
Even though you are buying an out-of-the-box product, there might be a need to customize it to fit your company’s specific needs. The actual needs and demands aren’t the crucial part in this. It is more about if they are receptive to your needs. Do they care about your questions? Do they seem willing to help you with the solution? Can compromises be made?
Some services just are not going to be able to be flexible with their implementations. But this could be an opportunity to see how the company handles its customers.
Encryption
The use of encryption to protect the transmission of data over the internets is now common practice. At the end of 2018 the percentage of traffic using HTTPS is over 72% and climbing. This is a huge increase from the previous year! And while this is a great thing, it does not guarantee in any way that it is implemented properly. Is the SSL/TLS implemented properly? With the latest standards applied? Do you have to “pay to play” to get the best service and encryption? Is your “safe” environment sitting on the same machine as the other customers that don’t want to pay for the top of the line security options? … Makes you feel a bit uncomfortable, right? Did they forget to tell you that? Oops! Guess your fancy encryption doesn’t really matter now…
Security
Finally, we come to the main point of why we are here and why we do what we do. We care about security. Not only for our customers, but our own as well, because in reality, it is all interconnected in some way.
As Penetration Testers, we see a lot of issues in our day to day work. The OWASP Top 10 is not some arbitrary list, these issues are very prevalent out there. The reasons we keep seeing these issues are endless and we can list them all day long. But it always seems to come back to one thing… “People… What a bunch of bastards…”. Yes, humans are flawed, they sometimes don’t learn from previous mistakes, they are stubborn and don’t want to change, they are ignorant and just haven’t been informed. The human element is often found to be the weakest link in the chain. It doesn’t matter what fancy security products and services you buy; they are all useless if they are not configured properly, turned on/plugged in, not patched regularly, or too difficult to manage.
Most of the products you buy are aimed towards network and endpoint security. These will not be very effective against web application vulnerabilities. The most common issues we see in our work are listed and described below for your reading pleasure.
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 really 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: Computephiles video on password cracking...
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 fairly comprehensive. Going into all the details concerning the SSL/TLS implementation 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 actually 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, in reality, other file formats are also allowed to be uploaded. In this case, since we are dealing with PHP (and PHP has the ability to 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 bad stuff 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 of 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? And why does Leann need access to internal documents that are only for “that Janice that stole Richard from me”? (You were never happy with Richard, why can’t you just realize that Leann!?)
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. That will probably help you sleep at night anyway, LEANN!!
Bad patch management / End of life management
There is no reason to explain this with any examples using characters, let’s leave Jaroslav the Internal IT guy alone. 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 actually 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 lead 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. Naughty naughty!
Final words
To finish this extensively long blog (we are sorry about that), just as you would properly vet a potential new employee, thorough background checks, references that are valid (not their mom, "he/she is such a great singer!"), technical understanding of the role you are hiring for, and the potential employee does not reek of alcohol and pizza sweat. The same process and methodology should be applied for when looking at a potential third-party application.
Have more than one plausible candidate, do not fall into the trap of costs. Just don’t exclude that option before you have asked these more in-depth questions regarding security.
From all the breaches that have happened lately, even of security companies, it is even more important for us in the IT Security world to keep the highest standards possible! Not only for our companies own interests, but how can we advise our customers on security issues when we are not even following our own advice...
You wouldn’t buy a product from a salesperson that they themselves didn’t care about.
Kategori:Säkerhet
If you're in the market for a third-party service to manage your employees' workflow, it's crucial to take multiple factors into account when assessing both the product and service provider. This checklist serves as a valuable questionnaire during the vetting process for third-party services you're contemplating using. To gauge the security maturity of a service provider's application, we've included a set of initial questions that we believe are particularly effective.
