Case Study on Penetration Testing of a Authentication Engine: 4 Categorized Process and Remediation

case-study-on-penetration-testing
We break your system before the bad guys can.

Case Study on Penetration Testing- Client Summary

This case study on Penetration Testing is about one of our client who had an authentication engine. This provided authentication based on various inbuilt as well as third party libraries, SOAP, and RESTFUL web services. Due to the seriousness of this engine and multiple APIs being used, we had to carry out module based penetration testing.

Penetration testing helps to evaluate security flaws in systems, infrastructures, and applications which can open doorways to malicious users or hackers. Irrespective of business domain and requirement, every organization should secure their systems by doing regressive penetration testing.

Tools & Technology

  • Nessus
  • Maltego
  • Skipfish
  • BurpSuite
  • John the Ripper
  • Cain & Abel tool
  • Restful and SOAP web service
  • Kali Linux

Solution

Before starting the actual penetration testing we identified the system core components and designed a test plan along with the number of test scenarios we would be able to produce. This included network, infrastructural evaluation, and application-level penetration testing. We used multiple tools to complete the evaluation.

Some of the tools we used were – Nessus to test on Linux Machines; it is extremely useful in packet sniffing and injecting. Our network engineers, along with security experts, worked together to incorporate this testing. For testing web-based applications and SOAP web services, we used Maltego, Skipfish, and BurpSuite. This is a very sophisticated testing suite that allows intercepting proxy, modifying web requests, crawling content, application scanning, etc. These tests were mainly used for application-level testing and to check how the application would respond if a malicious user intercepts an HTTP request.

We evaluated if each authentication mechanism in the authentication engine had at least two-factor authentication. This included features such as captcha, security questions, and/or Site key with strong and updated encryption algorithms like AES256, with used keys that change at regular intervals.

In the case of hashing, we recommended using SHA256 instead of MD5, since MD5 can be exposed to vulnerabilities. For SSL, we ensured certificates are signed only by trusted certificate authorities. To test the password encryptions in Windows-based systems, we used the Cain & Abel tool. This tool allows the cracking of encrypted passwords using various techniques such as network sniffing, brute force, dictionary, cryptanalysis, routing protocol analysis, cache uncovering, etc. For Linux-based systems, we used John the Ripper.

Our penetration testing consisted of a detailed report of infrastructural and application-level changes with the categorization of critical, high, medium, and low-level risks. Some of the issues found were:

  • Insecure Http methods enabled
  • Password changes did not require the current password
  • Weak password policy
  • Weak TLS configuration
  • Secure Cookie Attribute not set

Result

Based on our comprehensive testing, the client made the required changes to their infrastructure and applications. We guided them throughout the process to implement these solutions and ensured there was no impact on existing functionalities.

Our security experts exposed various scenarios and completed a detailed penetration testing of each module and functionality. We helped the client undergo re-penetration testing to ensure their systems were secure, and the tests were passed successfully.

Conclusion

Any business, no matter how large or small, should undertake penetration testing if the business deals with sensitive or valuable customer information. In fact, recent statistics have shown that smaller companies are increasingly becoming targets for cyber criminals simply because their IT security tends to be weaker.

Building and maintaining cybersecurity is not a one-time thing but a continuous process. Frameworks should be ceaselessly observed through surveillance technologies to discover any security loopholes. Risk assessments and incident response plans should be consistently updated by continuous risk and vulnerability assessments. IT infrastructure and related software or applications should be updated and upgraded regularly as updated versions frequently address the weaknesses present in the existing applications. Check more case studies to know more.

One comment

  1. Very good written article. It will be useful to everyone who utilizes it, as well as myself. Keep doing what you are doing – i will definitely read more posts.

Comments are closed.