To perform a wireless penetration test, it is important to follow a defined methodology. Simply ring up the airbase or airodump command and hoping for the best will not satisfy the goals of a test. When working as a penetration tester, you must ensure that you adhere to the standards of the organization you're working for, and if they don't have any, then you should hold yourself to the highest standards. Broadly, we can break up a wireless penetration testing exercise into the following phases:
- Planning phase.
- Discovery phase.
- Attack phase.
- Reporting phase.
WLAN Penetration Testing Methodology | Wireless
Planning Phase
The penetration tester should work with the client to define a scope that is achievable and will also provide the greatest amount of insight into the security of a network. Typically, the following information is gathered:
- Location of the penetration test
- Total coverage area of the premises
- Approximate number of access points and wireless clients deployed
- Which wireless networks are included in the assessment?
- Is exploitation in scope?
- Are attacks against users in scope?
- Is denial of service in scope?
Estimate Based on the scope defined, the tester will then have to estimate how much me is required. Bear in mind that restoring may occur following this estimate, as organizations may have limited resources available in terms of both me and money.
Legality: Prior to performing a test, the client must give consent. This should explain the testing to be covered and clearly define the level of indemnity, insurance, and the limitations of the scope. If you are unsure, you will need to speak to a professional in these areas. Most organizations will have their own versions that will likely also incorporate an Non-Disclosure Agreement (NDA). Once all of the preceding requirements are in place.
Discovery Phase
In this phase, the aim is to identify and apply characteristics to the wireless devices and wireless networks within the scope. All the techniques to perform these have been laid out in the previous chapters but, in brief, the aim is to:
Enumerate visible and hidden wireless networks in the area
Enumerate devices in the area, along with those connected to the targeted networks
Map the range of the networks, where they are reachable from and whether there are places a malicious individual could operate from to perform an attack, for example, a cafe.
All of this information should be recorded. If the test is limited to the performance of reconnaissance only, the test will end here, and the tester will attempt to draw conclusions based on this information. Some statements that would be useful to a client are be
as follows:
- The number of devices that have associations with open networks and the corporate network
- The number of devices that have networks that can be linked to locations through
- solutions such as WiGLE
- The existence of weak encryption
- The networks set up are too strong
Attacking Phase
Once reconnaissance has been performed, exploitation must be performed for proof of concept. If the Attack is being performed as part of a red team or wider assessment, then exploitation should be performed to gain access to the network as surreptitiously as possible.
In our attacking phase, we will explore the following:
- Cracking the encryption
- Attacking the infrastructure
- Compromising clients
- Finding vulnerable clients
- Finding unauthorized clients
Cracking The Encryption
The first step is to retrieve the keys for any vulnerable networks identified. If networks with WEP exist, perform the WEP-cracking method. If WPA2-secured systems are present, you have two choices. If aiming to be stealthy, arrive on-site at mes when individuals are likely to be authenticating or re-authenticating. These times are likely to be:
- Start of the day
- Lunch me
- End of the day
If WPA-Enterprise is in place, bear in mind you will have to use the information gathered from the reconnaissance to target the correct network and set up your dummy Enterprise setup.
You can attempt to break all passphrase but bear in mind that some will be unbreakable. Following the performance of the test, check with the wireless administrator for the passphrase in use. Check to see whether it is a secure passphrase and that you, as a tester, did not experience a tool failure or were merely unlucky.
Attacking infrastructure
If network access is gained through cracking the encryption, perform a standard network penetration test if allowed in scope. The following should be performed as a minimum:
• A port scan
• Identifying which services are running
• Enumerating any open services, such as unauthenticated FTP, SMB, or HTTP
• Exploiting any vulnerable services identified
Composition infrastructure
After enumerating and testing all wireless systems, there are various types of engagements that would suit performing attacks against clients. If necessary, after establishing which clients are vulnerable to Karma attacks, create a Honeypot to force them to connect with the methods laid out in the Attacking PEAP. There are various useful pieces of information that can be gathered through this method, but ensure that the collected data serves a purpose and is stored, transmitted, and used in an ethical and safe manner.
Reporting Phase
Finally, at the end of testing, it is necessary to report your findings to the client. It's important to ensure that the report matches the quality of your testing. As the client will only see the report, you have to give it as much love and a en on as you do to your testing. The following is a guideline to the layout of the report:
- Management summary.
- Technical summary.
- Findings:
- Vulnerability description
- Severity
- Affected devices
- Vulnerability type—software/hardware/configuration
- Remediation
4- Appendices.
The technical summary should be a midpoint between the management summary and findings list. It should be aimed at a developer or a technical lead with a focus on how to x the issues and broad solutions that could be implemented.
The findings list should describe each vulnerability at a low level, explaining the methods to identify, and replicate, and vulnerabilities.
The findings list should describe each vulnerability at a low level, explaining the methods to identify, and replicate, and vulnerabilities.
Appendices should contain any extra information that would be too long to describe in a short description. This is where any screenshots, proof-of-concept code, or stolen data should be presented.
EmoticonEmoticon