Risks of Using HTTP For Your Web Application

For modern web applications, the average user will interact over a secure protocol for communication (i.e. HTTPS, or Hypertext Transfer Protocol Secure). However, it’s not uncommon to encounter a web application hosted in an internal corporate environment using the less secure HTTP (Hypertext Transfer Protocol) which communicates in cleartext. While it may not seem like a big deal since the application is not exposed publicly to the Internet, we will briefly examine the risks of using HTTP for your web application.

Overview of HTTP vs. HTTPS

As mentioned above, HTTP communicates over cleartext. This means that any data you send from your device (client) to the site (server) can be captured and viewed by anyone on the same network as you. Obviously, this is problematic. The graphic below shows the basic flow of a user logging into an application:

In the above image, we can see an Administrator user logging into a website with the username “Admin” and the password “SecurePassword123!”. We can see this because of the cleartext communication that HTTP allows. Fortunately, most sites publicly exposed to the Internet do not communicate over HTTP anymore. The graphic below is a rudimentary view if an application communicates over HTTPS:

Note how the previously viewed values of the username and password are now impossible to view. Additionally, the response from the server which contains a “PHPSESSID”, a common authorization value which we now cannot see. This means an attacker cannot leverage this session cookie value to issue requests from the context of a victim user. This is always the ideal scenario and is best practice for security. Let’s look at what this looks like from a practical standpoint. An attacker will realistically see the below images, HTTP vs. HTTPS:

“But wait, where is the password in the left image? I don’t see it…”. Great observation! The above left image displays an Authorization request header in the form of “Basic Authentication”. Basic Authentication (Basic Auth) over HTTP is encoded, not encrypted (that’s a whole different blog post). Basic Auth can be decoded as it is encoded in Base64. While there are many ways to decode Base64, I prefer to use a website called CyberChef:

The image on the right cannot be decoded, as it uses encryption. The distinction of encryption vs encoding is very important, but without diving into that completely just know that encryption is much more important for information security.

HTTPS Best Practices

Now that we the know risks of using HTTP for your web application, let’s briefly examine some security best practices for deploying HTTPS. HTTPS was created in 1994 by NetScape, and the TLS protocol was officially submitted as RFC 2246 in January 1999. As you can imagine, technology has changed drastically since then and so have the protocols to secure communications for your favorite websites. So where do we stand today?

As of the creation of this blog post, Lucid Security recommends avoiding using legacy protocols (SSLv2, SSLv3, TLSv1.0, and TLSv1.1) in favor of TLSv1.2 or higher with strong cipher suites to prevent downgrade attacks and other known cryptographic weaknesses. A common finding when Lucid Security conducts a web application penetration test are violations of the OWASP A2 Security Control – Cryptographic Failures. In most cases, it is a minor security hygiene weakness (i.e. using TLSv1.0 instead of TLSv.1.2). Lucid Security strongly encourages organizations to follow security best practice to obtain the most ideal clean bill of health possible.

Summary

Even if an application is internally hosted, the risks of using HTTP for your web application are too great. Cleartext HTTP traffic can be obtained by very basic users within a network. ‘Introduction to Networking’ classes are often now taught in high schools, which introduce tools such as Wireshark or tcpdump. Both of these tools are capable of capturing cleartext communication via HTTP. Further, advanced threat actors are patient and will sniff traffic and attempt to “stay under the radar”. Sniffing traffic is a passive technique that can help prevent an attacker from getting caught. As such, internally hosted web applications should always communicate over HTTPS to prevent credentials and sensitive information from being leaked.

How Lucid Security Can Help

Lucid Security consists of seasoned security professionals with decades of experience in security and penetration testing. Our unique and competent perspective enables us to enhance clients’ security environments. Please contact us today to learn more about our services and how we can make your organization more secure.

Disabling Machine Account Creation

Since Windows 2000, Microsoft has enabled the ability for all users to create up to 10 machine accounts by default. This is a “feature” implemented by Microsoft that inadvertently introduces potential vulnerabilities within an Active Directory environment. Secure deployment should ensure that Machine Account creation is limited to specific users or groups; Lucid Security strongly recommends making this quick change to bolster your Active Directory environment’s security. This article demonstrates how to set the MachineAccountQuota to 0 instead of the default 10.

Dangers of User Machine Account Creation

First off, let me briefly highlight why having a MAQ of anything over “0” for users is a bad idea. First, once an attacker has valid user credentials, a machine account is trivial to add. This opens up attack paths for a threat actor that often lead to domain compromise. These include:

• Resource Based Constrained Delegation Attacks.
• Possibility of elevating computer account to domain admin via relaying attacks.
• Active Directory Certificate Services (AD CS) attacks.
• Additional persistence for an attacker should a user or administrator change existing user credentials.

How to Disable User Machine Account Creation

First, this is what it looks like from an attacker viewing the Machine Account Quota (MAQ) remotely from an attacker controlled device:

Second, this is what it looks like for an attacker creating a machine account:

Log into your domain controller and perform the following:

1. Press Windows Key + R and type adsiedit.msc
2. Right click on the “DC=” drop down menu and select Properties
3. Scroll down until you see ‘ms-DS-MachineAccountQuota’ and select it and then click Edit
4. Modify the value to “0” and hit OK
5. Apply

Assuming you’ve done everything correctly, this is what it will look like when a user checks the MAQ:

Lastly, when attempting to create a computer account, an attacker will be met with an error stating the relayed user machine quota is exceeded, or they do not have sufficient privileges:

Final Thoughts

Restricting the ability for users to create machine accounts is an important step in hardening an Active Directory environment and is often overlooked by IT administrators as it is an default value set by default by Microsoft. Lucid Security recommends having annual or bi-annual penetration testing to uncover settings such as this.

Contact us today at [email protected] or fill out our Contact Us form to speak with a qualified expert to determine the best solution for you!

What is a Web Application Penetration Test? The Open Web Application Security Project (OWASP) defines a web application security test as “…an active analysis of the application for any weaknesses, technical flaws, or vulnerabilities”. This is an excellent definition of a web application penetration test, but this article will dive a bit deeper in why you should have one performed for your organization.

Overview of a Web Application Penetration Test

A web application penetration test (“Web app pentest”), is a tactical assessment to uncover vulnerabilities and weaknesses within an application. It tests many aspects of course, but the important thing to understand is that this is a where a security vendor will actively act as a hacker (or attacker) and exploit potential vulnerabilities.

Benefits of a Web App Pentest

Lucid Security has experienced a large variety of applications and industries for it’s clients. Because of this, Lucid has a unique take on approaching an application. By and large, many security vendors focus on a single industry or niche area. While that can be absolutely beneficial, Lucid has the opportunity to view many different types of functionality, business logic, implementations, etc. This allows us to build out a robust custom methodology when testing applications. Lucid Security strives to uncover critical vulnerabilities such as injection-style vulnerabilities (i.e. cross-site scripting (XSS), SQL injection (SQLi), etc.), as well as business logic flaws where an attacker can take advantage of areas in the application to bypass intended functions.

Further, what are the practical implications or impact of a vulnerability? This is something that Lucid Security can specifically target, and is an objective that Lucid will actively seek when defined by a client during the kickoff call. It is not uncommon for a client to worry about risks such as authorization weaknesses where ‘Organization A’ could view ‘Organization B’s’ sensitive data/information. This is always a standard issue that Lucid Security attempts to identify during a web app pentest.

Lastly, Lucid Security offers at no additional cost a certification letter to attest that the client has received penetration testing in which they can disseminate this document to current and potential customers in order to receive further business. A common requirement for companies these days when assessing a vendor, is to require penetration testing and/or vulnerability assessments.

Risks of a Web App Pentest

With all of Lucid’s articles, we try to highlight the benefits, as well as the risks for any tactical assessment. The reason for this is there is always room for error and where things can go wrong, especially during an active penetration test. However, there are mitigating controls and things that can be done to prevent such issues from arising. First off, the client will always have the opportunity to call out specifically risky areas of the application which may cause an email to trigger, a process to be initiated, or a cost to be incurred. Further, vulnerabilities can arise that may cause disruptions/downtime. These vulnerabilities may not always be obvious, but is something that is made aware to the client before initiating testing. For this reason, Lucid recommends conducting testing in a QA or dev environment that mirrors a production build of the application.

Conclusion

A web app pentest is a important and necessary assessment to uncover potential vulnerabilities. In identifying these vulnerabilities, a organization can then remediate the issues and ensure that their clients data is secure. As previously mentioned, a certification letter attesting that an organization has received penetration testing can further strengthen organization/vendor relationships, as well as development new business.

How Lucid Security Can Help

Lucid Security consists of seasoned security professionals with decades of experience in security and penetration testing. Our unique and competent perspective enables us to enhance clients’ security environments. Please contact us today to learn more about our services and how we can make your organization more secure.

A common theme amongst clients when conducting penetration tests is a large attack surface. Generally, the biggest risk is amongst externally exposed assets. However, this can be related to internal penetration tests and web application penetration tests. This blog post will briefly examine the biggest risks associated with a large attack surface.

Unknown Assets

It is not uncommon for companies to have unknown assets exposed to their networks. Historically, Lucid Security has encountered client’s who have acquired other companies. As such, they assume control of the assets that the acquired company. This can lead to client’s having exposed assets that they are unaware of, or not inventoried. If this is the case, these assets may go unpatched/updated leading to further security vulnerabilities.

Test Content

It is important for organizations to continue to grow and evolve. Because of that, IT administrators may test out new software and services. While this is a great idea, unfortunately this test content may find itself exposed externally to the Internet. By testing out software and exposing it to the Internet, typical hardening procedures may have not been made.

Excessive Logging Solutions Exposed

Oftentimes for development reasons, logging software is included in dev/staging environments. However, organizations may forget to exclude them from their applications or external perimeter. This can lead to information disclosures such as database information or internal server architecture.

Conclusion

Between an everchanging security climate and regular development procedures, it is possible for organizations to expose more information/assets than necessary. For this reason, Lucid Security recommends conducting annual penetration testing and at a minimum quarterly external vulnerability assessments to stay on top of issues.

How Lucid Security Can Help

Lucid Security often conducts penetration testing and vulnerability assessments. Our services are catered to assist in identifying issues and help provide expert remediation advice. Contact us today to get started!