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 vulnerability scan? How does it differ from a Contact us? What are the benefits of a vulnerability scan? How often should you conduct a vulnerability scan? This article answers all these questions!

What is a vulnerability scan?

A vulnerability scan is essentially an automated process to identify potential security risks associated with your external perimeter or internal network. The market offers various vulnerability scanners, both free and paid. However, the key is to either know how to use the vulnerability scanner properly or to ensure your security vendor uses a trusted scanning solution.

At Lucid Security, we provide a vulnerability assessment as a service. Typically, the aim of a vulnerability assessment is to pinpoint potential security risks. These include vulnerable or outdated software versions, potentially risky ports/services exposed to the Internet, and sensitive files, among others. A reputable security vendor always provides a custom report with the vulnerability scan. Too often, security vendors may only provide standard HTML, PDF, or CSV outputs from a vulnerability scanner. This practice is not ideal because one should always manually verify the outputs from a vulnerability scanner. Results can be false positives, merely informational findings with no real security impact, or the criticality may be inadequately categorized. For this reason, Lucid Security always reviews the results of a vulnerability scan and ensures the report clearly articulates the vulnerabilities and remediation measures, and excludes any false positives.

Lastly, a vulnerability assessment stops at the identification phase of a vulnerability. Whereas a penetration test continues to the actual exploitation of a vulnerability.

Why should you have a vulnerability scan?

The reasons for conducting a vulnerability assessment can vary among organizations. A significant driver for many companies is compliance or customer requirements. It is common for organizations to undergo vulnerability assessments for compliance purposes or because they are doing business with a customer who demands a vulnerability scan and its results. Another reason is simply best practice to identify any potential issues on their external perimeter or internal network. Both are valid reasons.

How often should you conduct a vulnerability scan?

Lucid Security generally recommends conducting quarterly vulnerability scans at a minimum. With the ever-changing security landscape, new security vulnerabilities often emerge from security researchers or hackers. Thus, software you installed on a webserver that was just updated might develop a new vulnerability the following month. A vulnerability scan helps you stay ahead of issues before they escalate. It is also common to perform vulnerability scans monthly or bi-annually.

Conclusion

Lucid Security advises companies to perform quarterly vulnerability assessment, especially those with a larger than average attack surface. A reputable security vendor should provide the results of a vulnerability scan. Lucid Security always delivers custom reports that highlight the most relevant information on how to remediate and fix the issues.

How Lucid Security Can Help

Lucid Security employs expert security engineers with decades of combined experience in system administration, network administration, and security engineering. Our team delivers quality reports to ensure your organization remains secure. Contact us today to learn more about our vulnerability scan services.

External penetration tests often require organizations to safeguard their external perimeter against threats, whether for compliance, banking, or client requirements. However, it can be a daunting task which may have you wondering, “What can go wrong during a penetration test?”. This blog post examines the risks and will empower you to address these issues before kicking off an assessment.

Account Lockouts

Clients often worry about account lockouts during external penetration tests, although such incidents are rare. A proficient security team and penetration tester will consider this risk before each assessment. Lucid Security employs custom methodologies to prevent employee lockouts during assessments. Organizations with unique account lockout policies should inform the security team during kickoff calls to ensure appropriate measures are in place to prevent such issues.

Disruptions and Downtime

Related to account lockouts, disruptions and downtime also pose concerns during penetration tests. These often pertain to system or web application stability. A reputable penetration testing firm will not test for denial of service (DoS) vulnerabilities, as such tests offer little value and can hinder the discovery of other vulnerabilities by rendering the application or host unresponsive. Lucid Security reports potential DoS vulnerabilities without actively testing them to prevent client downtime.

Fear of the Unknown

Undergoing a penetration test can be daunting, particularly when organizations have invested heavily in infrastructure and data security. Lucid Security ensures clients feel comfortable by informing them about testing activities and providing clear, transparent results, embodying the clarity and transparency that is a core value of Lucid Security.

Conclusion

While external penetration tests can present several issues, a skilled security provider will anticipate and address these concerns, working closely with clients to mitigate risks.

Lucid Security’s Assistance

Lucid Security routinely conducts external penetration tests and services for various client sizes. Contact us today to discuss how we can help secure your network.

Lucid Security Engineers regularly encounter HTTP headers during web application or network penetration testing that reveal potentially sensitive information such as application architecture, server versions, or information about the underlying host system. These types of information disclosure vulnerabilities can be utilized by attackers to quickly determine vulnerable server versions and perform more targeted attacks. As a developer, system administrator, or IT manager you probably find these types of findings frustrating! Here’s how to remediate “HTTP Response Header Information Disclosure”:

Nginx

To remove the “Server” or “X-Powered-By” headers for a Nginx server, implement the following:

• In the nginx.conf file, set:
  “server_tokens off”
• In the case of a load balancer, remove the “Server” header from responses
• To completely remove the “Server” header, compile Nginx with the Headers More module and add:
  “more_clear_headers ‘Server’;”

References

https://serverfault.com/questions/214242/can-i-hide-all-server-os-info

https://github.com/openresty/headers-more-nginx-module#readme

Apache

Like Nginx, you can either rewrite the “Server” header value or add an additional module to completely remove it:

• Utilize the URL Rewrite module and configure an outbound rule to change the “Server” header value. This can also be set to a blank value.
• To completely remove the “Server” header, utilize the StripHeaders module to rewrite all HTTP response headers.

References

http://httpd.apache.org/docs/current/mod/mod_headers.html

IIS

Microsoft IIS makes removing HTTP headers pretty easy, with the notable exception of the “Server” header. Luckily we dug around and found a way to do this on Windows Server 2016, 2019 and newer.

• Open the web.config file in the root directory of the site, after <system.web> add:
  <httpRuntime enableVersionHeader="false" />
• To remove the “Server” header (Windows Server 2016/2019), configure requestFiltering in the web.config system.webServer node:

References

https://techcommunity.microsoft.com/t5/iis-support-blog/remove-unwanted-http-response-headers/ba-p/369710

https://www.ibm.com/support/pages/disabling-iis-web-banner-and-other-iis-headers

Conclusion

Fixing information disclosure issues can be painful, but we’re here to help. Hopefully this short post on how to remediate HTTP response header information disclosures was helpful. For up to 90 days after a penetration test, Lucid Security offers free retesting of discovered vulnerabilities. Reach out to us and schedule a security assessment today!

In the digital age, where cyber threats loom larger and more sophisticated than ever, organizations must fortify their defenses to protect sensitive data and maintain trust. The Center for Internet Security (CIS) Critical Security Controls, commonly referred to as the CIS Top 18, provides a strategic framework for mitigating the most prevalent cyber risks. However, to truly validate the effectiveness of these controls, integrating penetration testing into the CIS Top 18 review process is indispensable. This blog post delves into strengthening cyber defenses the synergy between technical professionals conducting a CIS Top 18 review and the critical role of penetration testing in validating and strengthening cybersecurity measures.

---

Understanding the CIS Top 18 and Penetration Testing

The CIS Top 18 is a prioritized set of best practices designed to provide organizations with a roadmap for effective cybersecurity defense. These controls cover a range of actions from basic cyber hygiene to advanced security measures, addressing both preventive and detective mechanisms.

Penetration testing, on the other hand, is a simulated cyber attack against your computer system to check for exploitable vulnerabilities. It’s an essential tool in the cybersecurity arsenal, offering real-world assessment of your defenses.

The Role of Technical Professionals in the CIS Review

Technical professionals, including cybersecurity experts, network engineers, and system administrators, are pivotal in conducting a thorough CIS Top 18 review. Their deep understanding of the organization’s IT infrastructure enables them to assess, implement, and monitor the effectiveness of the security controls. Moreover, their insights are crucial for identifying which areas require penetration testing to validate the security measures’ effectiveness.

Conducting a CIS Top 18 Review with Penetration Testing: A Step-by-Step Approach

Step 1: Assemble Your Team

Gather a multidisciplinary team of technical professionals with expertise across different areas of your IT infrastructure. Ensure the team understands both the CIS Top 18 controls and the fundamentals of penetration testing.

Step 2: Perform a Gap Analysis

Conduct an initial review of your current security posture against the CIS Top 18 controls. Identify gaps and areas of non-compliance that could potentially be exploited in a cyber attack.

Step 3: Prioritize and Plan Penetration Testing

Based on the gap analysis, prioritize the areas where penetration testing will be most beneficial. This prioritization should focus on high-risk areas, critical systems, and where controls are newly implemented or significantly changed.

Step 4: Conduct Penetration Testing

Carry out penetration testing exercises targeting the identified areas. These tests should mimic real-world attack scenarios to validate the effectiveness of the implemented CIS controls. Engage external experts if necessary to ensure an unbiased assessment.

Step 5: Analyze Test Results and Refine Controls

Review the outcomes of the penetration tests to identify vulnerabilities and control weaknesses. This analysis will highlight which CIS controls are working as intended and where adjustments are needed.

Step 6: Implement Improvements

Based on the findings from the penetration testing, implement necessary improvements to the CIS controls. This may involve configuring security settings, patching vulnerabilities, or enhancing monitoring and detection capabilities.

Step 7: Foster Continuous Improvement

Cybersecurity is an ongoing battle. Regularly review and update your CIS control implementations and penetration testing strategies to adapt to new threats and technologies.

Step 8: Documentation and Communication

Maintain detailed documentation of your CIS review process, penetration testing results, and subsequent actions taken. Communicate these findings and their implications to relevant stakeholders, fostering a culture of transparency and continuous improvement in cybersecurity practices.

Conclusion

Integrating penetration testing into your CIS Top 18 review process is a powerful strategy to validate and further strengthening your organization’s cyber defenses. By combining the expertise of technical professionals with rigorous testing, you can identify vulnerabilities before attackers do, ensuring your cybersecurity measures are not just theoretical but truly effective in the real world. Remember, the goal is not just to comply with a set of controls but to build a resilient infrastructure capable of withstanding the evolving cyber threats of the digital age.

Let Lucid Security Help

Strengthening cyber defenses of your organization can be a large feat. Lucid Security is well versed in conducting both CIS Top 18 reviews, as well as penetration testing and can help you get on the right path! Please reach out to us today and let’s talk about taking the next step in your security assessment. Contact us today!

5 default M365 settings to change immediately.