Posts

Blog On The Latest Exploited Security Vulnerabilities

Setting Up a Proxy to Protect Your Public IP (An Introduction to Proxies)

Image
I recently purchased a static IP address. While this is great for setting up VPNs, websites, and other major benefits it bothered me that I normally visit CTFs and sites that contain malicious code to accomplish these CTF challenges. There had to be a way I could better protect my public IP from direct exposure in the event I did something stupid while surfing the web. This is where a proxies come into play. A proxy is exactly the same thing meant in the English language; think if computer A who set up the proxy wants to talk to computer C. An intermediary could be introduced (Proxy Server B) so that when computer C talks to computer A it has to go through Proxy Server B. Thus Computer C thinks its talking to Proxy Server B and only sees that IP address; when in reality all traffic is getting forwarded to computer A and vise versa. This creates a layer of abstraction. There are many types of proxies such as reverse proxies which is used mainly for public facing web sites. We are strict

Cross-Site Scripting (XSS) Introduction

Image
  Cross-Site Scripting (XSS) Introduction Note** The following examples utilize Web for Penetration Testers which I do not own any rights to. These examples provide solutions to the live image of Web for Pentester 1 which can be downloaded at https://pentesterlab.com/exercises/web_for_pentester/course . Please attempt these exercises on your own before reviewing my solutions to gain maximum benefit.   Introduction XSS is an often-overlooked vulnerability. The generic “Hello World” example of XSS (e.g. <script>alert(“XSS”);</script>) is an overly benign example. Once an XSS vulnerability is discovered it becomes possible for attackers to modify the webpage to re-direct users to malicious site, steal a user’s session or cookie, or bypass a log in. Because XSS is such a huge topic, a series will be developed with exploitations to follow. For this blog article, XSS detection will be focused on. Eventually this series will cover JSON, XML, XPath, JQuery, and other typ

LDAP Vulnerabilities

Image
Note** The following examples utilize Web for Penetration Testers which I do not own any rights to. These examples provide solutions to the live image of Web for Pentester 1 which can be downloaded at https://pentesterlab.com/exercises/web_for_pentester/course . Please attempt these exercises on your own before reviewing my solutions to gain maximum benefit.   Web for Penetration Testers Example 1 Lightweight Directory Access Protocol (LDAP) can be thought of as a hierarchical directory structure. Using the live iso of Web for Pentester 1 lab we can find that Open LDAP service is running by running performing a nmap scan from our kali box (attacking machine): Figure 1 Using the ldapsearch command with the -b (base dn [top of hierarchy in this case]) -LLL (print responses in LDIF format without comments or version) and -x (simple authentication) flags (-h specifies the host) from our kali box (see Figure 2), we see that there are three common names (cn) entries: admin, admi

Covering Your Tracks - Anti-forensics for the Cloud - Introduction

Image
Before delving into cloud forensics there are some concepts that need to be explained. The cloud consisted of two entities, provider (companies that host cloud technologies) and tenants (companies that use cloud technologies from the providers). The cloud generally consists of three service models:  Infrastructure-as-a-Service (IaaS) where the provider provides the hardware and network. Platform-as-a-Service (PaaS) where the provider provides all the components to a tenant's application. Software-as-a-Service (SaaS) where the provider supplies the software and the components to run it and the tenant uses and at most configures the application. Chris Brenton gives a great overview of the cloud and the challenges it poses in the link below: https://www.sans.org/blog/pen-testing-in-the-cloud/ Surprisingly there is not a lot of coverage out on the web for cloud forensics and this makes sense. Cloud forensics analysts, especially for tenants, may be somewhat limited on acc

Covering Your Tracks - Anti-forensics for Memory

No matter what you do as a hacker, at some point you are going to traverse memory. Computers can almost be thought of as recording devices; anything a user does gets recorded somewhere and memory is a good place to start forensic investigations. This may sound like it is therefore impossible to completely avoid leaving a footprint of some kind on a computer and while that may be true to at least some extent, there are ways to avoid detection from memory acquisition tools. But before understanding these methods it is first necessary to understand how these memory acquisition tools work. Volatility is an open source framework written in python. It contains numerous plugins to analyze a memory dump. Memory dumps can be obtained from tools such as AccessData FTK Imager which is nothing more than loading the program and then choosing File >> Capture Memory and then choosing where to save the .mem file. Once the memory is acquisitioned it can be analyzed with volatility comma

Covering Your Tracks

The ability to remain stealth during a penetration exercise is what separates a sophisticated hacker from a script kitty. The phrase “The Quieter You Become, The More You Are Able to Hear” holds true, especially in the field of hacking. Being able to perform Ani-forensics and avoid detection is critical to the success of hacking and penetration testing and understanding these methods is beneficial, even for white hat hackers, as there will be times in a penetration where the system is already compromised. In such cases, understanding what the attacker is doing in order to cover their tracks can help determine the sophistication of the attack or bring prosecution to the attacker. All hacks begin with system enumeration and nmap is one of the best tools to use during this discovery phase. However, as I explained in Scanning With nmap blog, port scanning a bunch of IP Addresses or every port on a target system is noisy and can cause denial of service conditions (very bad if you are

Cloud Security

It should be no surprise that the cloud can be just as vulnerable as in-house servers; after all the cloud is just data centers with servers connected to the internet. Cloud data centers such as Amazon, Microsoft, and Google do have top notch security such as physical controls like concrete barriers and utilize the most recent and secure network protocols such as IPv6. However, this does not stop users of the cloud from poorly implementing security configurations or writing bad code for the sites a cloud may host. Even more interesting, it has been found that the cloud vendors themselves have vulnerabilities.  Let’s delve into some of these issues and how they may be addressed. 0day vulnerabilities in the cloud vendors themselves do exist. Azure, in example, did have a 0day Cross-Site Scripting (XSS) vulnerability. Chris Dale, a penetration tester, found a command injection flaw that allowed him to set environment variables of a process using an XSS payload. The command injection