Red Team: How We Compromised A Banks’ Network

Posted by on September 22, 2018 0 Comment

A Red Team activity helps an organization assess it’s security posture, and it’s ability to safeguard assets against a persistent and motivated attack. The purpose of conducting a Red Team activity is to demonstrate how real-world hackers can combine seemingly unrelated exploits to achieve their goal.

“If you want to stop an attacker, you have to think like an attacker.”

Their goal is to act like the adversary and figure out different ways to break into a company so it can strengthen its defences. A red team considers the full ecosystem. Unlike penetration tests where we solely try to breach a component, red teamers use a plethora of multiple attack vectors. Ranging from social engineering, weak points in physical locations, external attacks.
This blog post addresses our recent Red Team where we comprised a bank’s network. Our Client (the bank) wanted a scenario as realistic as possible, where a dedicated adversary would be trying to break-in.

Methodology & Approach:

1. Defining the Target
2. Information Gathering
3. Vulnerability Analysis
4. Exploitation
5. Social Engineering
6. Physical Security Analysis
7. Post‐Exploitation or Maintaining Access

The Red Team Assessment commences with defining the target where we considered IP addresses, Applications, Organization’s physical security implementation, wireless network and employees for social engineering.

During the information gathering phase, the red team analyzed the banks’ ecosystem trying to leverage the maximum information. Typically, we gather information from various resources. OSINT plays a crucial role. We found IP addresses, applications, employee’s data, weak points in physical security implementation to name a few.

Information Gathering Phase Red Team

External Phase – Technical Analysis:

Once we had enough data on our target environment, the team began scanning their external network and public facing applications. Simultaneously we performed manual penetration testing on the applications. We correlated the information to find vulnerabilities that would allow us to execute commands on their remote server and help us to reach the primary target with pivoting.

Critical Vulnerabilities Discovered:
SQLi, Local File Download, LFI, Amazon S3 Buckets, Admin Panel, Hardcoded credentials, SQL server access, Command execution, Apache Tomcat running with default credentials.

Red Team Critical Vulnerabilities

 

The Red Team compiled sensitive data and internal files from the banks’ server and tried executing the command on their server. The banks’ security was resilient. The team tried accessing the Apache Tomcat with default credentials and got access to their tomcat admin panel. Having gained access we saw war deployment option and tried to upload our shell (It works!), we deployed our shell and executed the command on their server. Red teamers don’t stop here. The team tried pivoting to get access to further systems.

Up until now, we’d only tested the bank externally. The team gathered substantial sensitive data and access to sensitive resource of the organisation.

Social Engineering:

We conducted several successful interviews, promotional calls, and phishing attempts. With the help of social engineering attacks, we gathered sensitive details. Such as  AD credentials, personal information, internal proxy, physical security implementation, various security checkpoints, centralized server etc they were using.

Physical Security Analysis:

camera-cctv-equipment

After the social engineering phase, we decided to have an anonymous visit to the bank. We had planned multiple scenarios to get inside: scheduling a job interview, RFID bypass, third-party meetings in the bank, promotional visits. However, we were successful in our first attempt but we also tried different methods to check the physical security postures. We used tailgating on various checkpoints where we also were able to take Red Team toolkit where they were unable to detect us. We also scheduled a meeting to get inside the organisation as a guest and were successfully able to enter in their premises.

Once the Red Team was on-site: We created a wireless network within the organisation using a LAN cable and our router which is usually the best way to be a part of their network. It was enough for us to be in their network. We also connected to their guest WiFi for network access but due to multi-step authentication, we only got the partial network access. A successful attack plan requires a backup option. To ensure that we didn’t lose connection via the wireless network we connected a Rasberry Pi in their network. This provided the reverse connection to our company for maintaining access.

Internal Phase – Technical Analysis :

We started testing their internal network. After a primary analysis, we got access to their FTP server, Printers, IoT devices, Configuration panels but that was not sufficient for us. We tried digging further inside, and after a thorough analysis, we got access to their RDP’s. Unfortunately, the monitoring team shut down the RDP. (Kudos to the banks’ Blue Team)

We tried LLMNR and NBT-NS Poisoning and received some of the NTLM hashes of users, but finding plaintext credentials from NTLM was taking long and considering the Blue Team was actively monitoring us we did not waste the active time on these hashes.

The team observed that one of the FTP server is accessible with anonymous login and has a URL and Credentials of their Citrix server. We considered the possibility of it being a honeypot because the credentials we got didn’t have a system associated with it. However, we got a rough idea where the Citrix server runs. We also confirmed that the Blue team is actively monitoring the network.

business-computer-connection

We observed that their Citrix server’s login is configured over SSL, but the SSL was not enforced. The team tried SSLStriping to downgrade the protocol along with MITM and successfully received several credentials of their Citrix systems. Our Red Team configured the Citrix receiver with received credentials and successfully got access to the system which has admin rights and contains all the internal data of the bank. The same credentials allowed us to join our created system in the AD and gained persistent access into their network.

Citrix server and any other centralised server should be the first target in any red team activity since most of the companies do not follow the security best practices for implementation and leave it vulnerable. Also, these systems can give us the huge scope to reach our target.

Concluding the Red Team Activity:

Alternatively, we got access to their monitoring system where we could disable the entire monitoring system and put the Blue team in trouble and allowed us access to assets of the bank assigned to Blue Team. We have done exactly the same and gained the access to domain admin by pivoting in the absence of blue team.

Security Audit of IBM AS/400 and System i : Part 2

Posted by on August 22, 2018 0 Comment

Security Audit of IBM’s AS/400 System i: Part 2

Process Segregation for AS/400 security audit

This post is a continuation of part 1. We will dive deeper into the security audit of IBM AS/400 and system i. As we are aware that AS/400 is not just an application, it provides a complete environment to run the application including front-end(Green screen), business logic, backend, file storage and operating system support. So no third party interaction is allowed in the application for the execution environment.
In this case, the complete AS/400 environment becomes the scope of security audit to make sure the overall environment is secure. Considering the same, we segregate the security audit process in 3 major categories.

• System Security Analysis
• System Configuration Audit
• Application Logical Testing

AS/400 Segregation

System Security Analysis

The ‘System Security Analysis phase covers the security assessment of system environment which works as a container to run the application. Any system, running the application is one of a layer for an attacker to break into to get the access of all applications (including target application) running in that particular system. To secure an application, we must ensure that system which is providing the environment for running that application is also secure.
The system security analysis covers these critical points to analyze and ensure system security.

• System OS version.
• Open ports on the system.
• Services that are running on the system.
• Default services enabled on the system.
• Accessibility of system to end user.
• Vulnerability analysis of the services running on a system

Tools might be helpful to complete this phase :

There are a lot of tools available which helps in port scanning, service enumeration, vulnerability assessment and analyze other systems/network services. Below are the most common tools which are efficient and user-friendly and considered to be flexible for all types of environment.

NMAP can help you in port scanning and service enumeration where Nessus helps out with the vulnerability assessment for the services running on a system. Combination of NMAP and Nessus create a perfect suite for any Auditor while doing a security assessment of a system/network.
With the help of NMAP and Nessus or any other alternate tool, we need to ensure that we can identify all the ports, services running the system and point out the vulnerabilities existing in the system. This phase should cover all the above-listed points to ensure the security of the system which is layer 1 for our application.

Security Configuration Audit

Every system/application has a layer of inbuilt security to run the application with a secured configuration to avoid any unauthenticated/ unique access into the system. The system security configuration is designed by vendors to run with a best security practice which becomes user-friendly for system administrator or end user to configure the system as per standard security guidelines.
AS/400 also have some inbuilt security configuration to ensure the security of a system. All the system security configurations are easy to understand and implement for any AS/400 administrator who is capable of operating the AS/400 systems.

Mentioned below is the checklist for security configuration of AS/400 which can help to configure the AS/400 system with security best practices.

 Download our checklist here:  AS400 audit checklist Security Brigade

Note: This checklist is created based on the experience of audits Security Brigade has done so far. It’s not derived from vendors or any other external resources.

Application Logical Testing

Application logic testing covers the core logic behind application be it like business logic, data transmission, bidirectional component interaction and other checkpoints playing a crucial role in the application environment.

Logic and processes may include:
• Data transmission between client-server
• Request endpoints
• Communication protocols and conceptual behaviour
• Input processing
• Business logic layer integration and data processing
• File system
• Data storage
• Input/Output Encoding/Decoding
• Origin verification
• Application client accessibility and behaviour
• Application client enforcement
• Data manipulation during transmission

In the previous post, we mentioned specific challenges you may face. The system is entirely different from other conventional systems, so we need to work out to set up the testing environment first.
For security testing of any application, an auditor needs below parameters to work on:

• Architecture of system
• Protocol Analysis
• Setup the environment to view/modify/replay traffic
• Understanding the application logic
• Request/Response Analysis
• Local memory analysis

The above parameters are possible if we can view/modify/reply to the data transmission between client-server. So, first of all, we need to set up an environment which allows us to monitor and manipulate the application traffic. With HTTP/HTTPS based application this is easy, but when it comes to different protocols with security checkpoints of a vendor, it becomes complicated to work with.
We have already mentioned the architecture of this system in the previous system. So let’s have a look on the possibilities an auditor have to work with these systems in respect of security audit.

Analyzing The Protocol :

As per the standard protocol and design by the vendor, AS/400 work on TCP and allow to connect with the application via telnet. So there is no involvement of HTTP/HTTPS in this case which could help us to audit the system smoothly.

So we need to work on the initial analysis of system behaviour first to analyze the protocol so that we can figure out the solution to view/modify/replay the requests.
Here, Wireshark helps you analyze the traffic on a particular network interface. You can quickly filter out the traffic of as/400 with the below filter.
IP.src == <Your Local IP> && IP.dst == <IP of AS/400>

Once you can see traffic for AS/400 sent from your system or as/400 client terminal you can analyze and find the protocol it is using for communication.
IBM iSeries AS/400 Character Encoding: AS/400 uses different character encoding, but in most of the cases you can see that it uses EBCDIC which is a traditional character encoding for any application written in Cobol. In the next step, we need to figure out a solution/tool which helps us to deal with traffic over TCP with EBCDIC character encoding or any other encoding it is using.

Setup The Environment To View/Modify/Replay Traffic :

AS/400 comes with an IBM suite which has various utilities to connect, configure, troubleshoot and maintain the system. IBM emulator is one of them which help an end user to connect to the system. The same uses telnet instance in the background for remote connectivity.
We now need to think how we can place our proxy tool in between the IBM emulator and AS/400 system. We are using the below mediators as proxy tools for this purpose to capture/modify/replay the traffic :

• Echo Mirage
• ITR(Interactive TCP Replay)

We can have a look below to see the data representation in ITR :

Interactive TCP Replay AS/400 System Security Audit

However, thinking from a different perspective, here we have 2 ways to connect to AS/400.

  1. Using IBM Emulator provided by the vendor.
  2. Using telnet terminal with third party utility or system itself.

While connecting through IBM emulator, you’ll encounter a green screen window to operate the system as shown below.

Green Screen for AS/400 Security Audit

Green Screen for AS/400 Security Audit

Analyzing both ways for connectivity you should see that you are not able to capture the traffic using any of the above proxy tools if connecting via IBM emulator but you can capture the traffic while you connect directly using any telnet terminal. There might be the main reason which does not allow us to capture the traffic while connecting with IBM emulator. One of the main reasons is that IBM emulator is wrapped with their security checkpoints which do not allow an end user to route the traffic through other non-standard utilities.

“So we can eliminate the first challenge to capture the traffic by directly using telnet client instead IBM emulator to connect to AS/400.”

Still, if the system is configured to use only IBM emulator and deny the connection request with other utilities, we have to go with python to replay the request for testing which is not an efficient solution to deal with this challenge, but it is undoubtedly going to reduce your effort.
“So we can eliminate the second challenge to capture the traffic by using python scripts to reduce the effort and replay the requests.
Once we can capture/modify/replay the traffic, our setup is ready to proceed with the technical audit.

Understanding The Application Logic :

AS/400 based application is the standard application and provides you functionalities from inbuilt modules as per the user’s need. So all the modules are already created as per the standard procedures and guidelines. Whenever a new requirement comes, the particular set of modules are configured and provided to the end user.

The application process on the server itself and only remote access of the application can be used by the user, so there is no logic base at client end which can be exploited from the front end and manipulation between client server. The application allows a user to select particular options or write the commands (if CLI is provided to users) and these directly goes to the server so in this case, no manipulation is possible.

The application is just an interface to interact with the backend, and business logic for the same get processed on the server itself where the user does not have any command over the logic manipulation.

Moreover, we can try the below test cases to ensure the security from front end :

• DB2/SQL Injection
• JCL Injection
• Command Injection
• Input Validation Issues
• Logical Errors
• User Enumeration
• Privilege Escalation
• Insecure Cryptographic Algorithms

All of the above issues are straightforward to test as we perform testing in standard thick/thin client applications. Few of the test cases can be done with the help of inbuilt tools provided in the IBM suite such as iSeries Navigator.

iSeries Navigator allows us to access the integrated file system of AS/400 which can be used to analyze the storage, privileges, directories, security configurations, SoD and many more. This tool also helps us in configuration review of the file system as well as other access control related checkpoints.

Checkout Accessing the integrated file system

Request/Response Analysis
These request and response are purely EBCDIC encoded and can easily be seen in plain text also, but as we already know, the application logic is processed on the server itself so there is a minimum chance of doing a client-side manipulation which could lead to a severe compromise.
The below request can be seen to understand the application encoding character set transmitted in EBCDIC :

Wireshark Request

The system is developed and owned by IBM, so they have their parameters and security checkpoints to ensure the secure transmission of data. So an auditor has to mainly focus on the client side testing and security configuration review.

Local Memory Analysis :
AS/400 based application use its inbuilt integrated file system which we have discussed in previous post and analysis of the same’s discussed in the above phase. Now we mainly focus on the local storage analysis at runtime.
WinHex is a well known and efficient tool for memory analysis which allows us to monitor and analyze the memory at runtime. It is a multipurpose tool for computer forensics, data recovery, and low-level data processing. For this audits purpose, we’ll take benefit of this tool for memory analysis from the security perspective. With the help of WinHex, we can check, how the application stores data in memory in the runtime environment.

Download our checklist here:  AS400 audit checklist Security Brigade

 

References:
https://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-Carmel/bh-eu-06-Carmel.pdf
• https://cplusglobal.wordpress.com/2015/06/25/ibm-i-as400-security-audit-controls/
• https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_72/rzamv/rzamvsecauditchecklists.htm
• https://search400.techtarget.com/tip/Is-your-AS-400-secure-How-a-hacker-could-get-valuable-information-from-your-system
• https://www.sec-consult.com/wp-content/uploads/files/whitepapers/SEC-Consult_Whitepaper_COBOL_V1.1.pdf
• https://resources.infosecinstitute.com/application-security-testing-of-thick-client-applications/#gref

Security Audit of IBM AS/400 and System i : Part 1

Posted by on August 21, 2018 0 Comment

Security Audit of IBM’s AS/400 System i: Part 1

In this blog post, we will be describing our experience of conducting a security audit of IBM AS/400 and System i.

AS/400 also known as IBM i Series or Green Screen System was initially designed for micro businesses. By industry need and reliable performance of these systems with the efficient output, IBM redesigned the system for distributed networks.

AS/400 supports the distributed network communication while interacting with multiple core applications to serve the data in a multi-direction manner. It runs on its internal operating system called OS/400 which is equipped to provide versatile all-purpose services.

OS/400 based AS/400 system is a milestone success, where IBM can compete with Windows and Unix based servers. Unlike Windows and Unix, its multi-purpose environment and inbuilt security implementation make it safer and reliable in the industry.

Features Of The AS/400 System

Given that most companies have adopted other popular systems where users have accessibility, reliability, efficiency, troubleshooting, human resources, cost-effective, and ease of implementation, we’ll argue the case for why companies should consider adopting AS/400 over other popular systems.

AS/400 systems/servers have always been an attraction for the businesses that deal with a high volume of transactions. These systems are entirely reliable, safe and efficient as per the business need. Below are some key factors which work as a backbone for the existence of AS/400 in the industry:

  • Performance
  • In-built Security
  • Thousands of inbuilt application environment
  • Fully integrated h/w and s/w components
  • RISC processor technology
  • Efficiency
  • Stability
  • Accuracy
  • Versatility

AS/400 or System i Architecture

As we all know, dealing with financial transactions and sensitive user data has always been a concern for organizations. These types of operations require maximum efficiency as well as accuracy as they are expecting the security of critical assets. So organizations tend to go with systems which are capable of providing all these critical factors along with a high-performance environment to the end user to avoid any business/security issues in the place.

IBM AS/400 uses an integrated file system that allows applications to access specific segments of storage that it organizes as logical units. These logical units are files, directories, libraries, and objects.

Integrated File System

There are various file systems in the integrated file system:

  • Root (/)
  • Open Systems (QOpenSys)
  • Library (QSYS.LIB)
  • Document Library Services (QDLS)
  • LAN Server/400 (QLANSrv)
  • Optical Support (QOPT)
  • File Server (QFileSvr.400) etc

IFS

Challenges During Security Audits of AS/400

The above overview, architecture, file system is enough to understand that these systems are entirely different from other systems which are commonly in use. Whenever we talk about security audit of any system, it directly relates to and depends on the architecture and workflow of that system. So auditor must have an idea about the architecture and workflow of the target system to create the strategy for security testing of that particular system.

As we are aware that, these systems entirely different from other systems to the process and methodology of security testing for other systems would not work here anymore.So let’s have a look on the challenges auditors usually face while doing the security audit of AS/400 based system:

  • It uses it’s own IBM client to access the application which is completely wrapped with IBM security checkpoints, so it is difficult to intercept the traffic for testing.
  • Requires expertise in AS/400 system commands, where most of the auditors are from a Windows, networking or other background and don’t have in-depth AS/400 security knowledge.
  • A file system is different from other conventional systems, so analyzing and choosing attack vectors for the respective module is difficult.
  • Runs on IBM Mainframe based systems, so it is challenging to understand the background support processes as mainframe is in infrequent use.
  • If a third party utility is used to access the application, IBM’s security checkpoints crash the utility and don’t allow the user to access the application using other utilities.
  • Another reason of crashing the utility is that AS/400 is a high performance and reliable system so it requires a utility to access the application which capable as per the AS/400’s requirements, and usually, other utilities are not capable.
  • Most of the AS/400 system works on EBCDIC (Extended Binary Coded Decimal Interchange Code) character set so tools used as a proxy in other application by auditors may fail.
  • It transfers data character by character, so mass manipulation of data is difficult to perform.
  • Depending on the configuration done by administrators, AS/400 may only allow the request from the IBM client only, so auditor’s methodology of sending or replaying existing request might get blocked.
  • Client-side manipulation is difficult as it is made by the IBM standard code which is being used since it’s deployment.
  • As the application logic is processed on the server, there is almost no scope for application logic testing.
  • It is challenging for those companies or auditors to audit AS/400 who mainly depends on the automation testing as there is a minimum scope of automation testing in this scenarios and as such no automated scanner is available.

Tools and Techniques to be used in AS/400 Audit

Below are some tools which can help you during the security audit of AS/400. Use of a particular tool depends on the application behaviour and client application. The role and reason behind choosing these tools will be explained in the core audit process.

  • Wireshark
  • ITR(Interactive TCP Relay)
  • Echo Mirage
  • SysInternalSuite
  • WinHex
  • In-built IBM Utilities
  • Python(To reduce the effort during testing)

In the next part, we will explain the process segregation and core audit process covering various aspects of a security audit in regards of AS/400 environment.

KRACK Attack: Breaking WPA2

Posted by on October 17, 2017 0 Comment

The Krack Attack affects most wireless networks and clients across the world. Wireless networks play a crucial role in the digital world and most internet users use WiFi networks on a daily basis. Having encryption on wireless networks has become the benchmark and over the years we’ve had many encryption algorithms for WiFi communication – First WEP, followed by WPA and now WPA2.

That being said – In line with Murphy’s law and assisted by growing computational capabilities thanks to Moore’s Law – Each one of them has eventually succumbed to a vulnerability that renders it irrelevant.

WPA2 has been so far considered as the most trusted and secure protocol for wireless communication till date.

A security researcher from the Belgian University KU Leuven named Mathy Vanhoef released details about an attack called KRACK – Key Re-installation Attack for WPA2 protocol on his website.

Vanhoef writes about this attack on his website:

The weaknesses are in the Wi-Fi standard itself, and not in individual products or implementations. Therefore, any correct implementation of WPA2 is likely affected. To prevent the attack, users must update affected products as soon as security updates become available.

Our main attack is against the 4-way handshake of the WPA2 protocol. This handshake is executed when a client wants to join a protected Wi-Fi network, and is used to confirm that both the client and access point possess the correct credentials (e.g. the pre-shared password of the network). At the same time, the 4-way handshake also negotiates a fresh encryption key that will be used to encrypt all subsequent traffic. Currently, all modern protected Wi-Fi networks use the 4-way handshake. This implies all these networks are affected by (some variant of) our attack. For instance, the attack works against personal and enterprise Wi-Fi networks, against the older WPA and the latest WPA2 standard, and even against networks that only use AES. All our attacks against WPA2 use a novel technique called a key reinstallation attack (KRACK). 

Here’s How the KRACK WPA2 Attack Works:

What is the impact ?

According to the researcher the impact of this vulnerability depends on the handshake being attacked, and the data-confidentiality protocol in use since against AES-CCMP an attacker can only replay and decrypt packets but can’t forge it.

“The impact of exploiting these vulnerabilities includes decryption, packet replay, TCP connection hijacking, HTTP content injection, and others,” the US-CERT warned. “Note that as protocol-level issues, most or all correct implementations of the standard will be affected.”

To simply a bit, the communication over HTTPS is secure (but may not be 100 percent secure) and cannot be decrypted using the KRACK attack. That being said, you are advised to use a secure VPN service – which encrypts all your Internet traffic whether it’s HTTPS or HTTP.

How to protect your networks from Krack Attack?

As of now the only efficient mechanism is to apply patches / updates for clients and deploy the latest firmware being released. Changing the password of your Wi-Fi network does not prevent (or mitigate) the attack.

Below are some firmware and driver updates available for KRACK WPA2 vulnerability for the major vendors :

The complete list is available at Bleeping computer where they are tracking the progress of each specific vendor’s patch release.

Krack Attack - WPA2 Patch Story

Image Source : CommitStrip

Is there anyway to mitigate this attack?

Until a patch and firmware update are released by your vendor, you can try to mitigate attacks against routers and access points by disabling client functionality (which is for example used in repeater modes) and disabling 802.11r (fast roaming). For ordinary home users, your priority should be updating clients such as laptops and smartphones.

Assigned CVE Identifiers

The following Common Vulnerabilities and Exposures (CVE) identifiers were assigned to track which products are affected by specific instantiations of our key re-installation attack:

  • CVE-2017-13077: Re-installation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
  • CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
  • CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
  • CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
  • CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
  • CVE-2017-13082: Accepting a re-transmitted Fast BSS Transition (FT) Re-association Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
  • CVE-2017-13084: Re-installation of the STK key in the PeerKey handshake.
  • CVE-2017-13086: re-installation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
  • CVE-2017-13087: Re-installation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
  • CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.

Note that each CVE identifier represents a specific instantiation of a key re-installation attack. This means each CVE ID describes a specific protocol vulnerability, and therefore many vendors are affected by each individual CVE ID. You can also read vulnerability note VU#228519 of CERT/CC for additional details on which products are known to be affected.

How does it work?

The attack occurs due to a vulnerability in the 4-way handshake or against cipher suites defined in the WPA2 protocol and hence all products using the correct implementation of the protocol are vulnerable. The attacks targets the 4-way handshake, and does not exploit access points, but instead targets the clients.

The idea behind this attack is to abuse the keys being used in phase 3 of 4 way handshake where key is generated after 2 way handshake between AP and client.

This authenticated key can be captured with MITM and can be replayed to exploit the vulnerability since the keys are already used and fully authenticated and verified for handshake between AP and client.

Earlier the reuse of generated and used keys was not possible for further implementation since the router used to get restarted for multiple use of same key. Even if the same problem occurs in current scenario, the attackers are able misuse this since keys are stored in non-volatile memory on boot during restart