Home > Articles

This chapter is from the book

The Frame of Deception: Wireless Man-in-the-Middle Attacks and Rogue Access Points Deployment

Our next stop is wireless man-in-the-middle attacks. The first question you might have is why we need man-in-the-middle attacks on 802.11 LANs at all. On the switched wired networks, man-in-the-middle attacks are frequently used to allow the possibility of traffic sniffing. 802.11 LANs are shared medium networks by definition, and once you've dealt with the encryption (if present) you can sniff all the packets on the LAN even without being connected to it. We have already answered this question when describing Dsniff utilities: The answer is connection hijacking and traffic injection. Positioning yourself between two wireless hosts gives an unmatched opportunity to inject commands and even malware into the traffic streams between both hosts. Becoming a rogue access point or wireless bridge means there are far more than two hosts to target with the connection hijacking or traffic injection and modification tools we review in the next chapter.

A specific implication of man-in-the-middle attacks is providing a rogue access point to attack one-way 802.1x authentication systems that use EAP-MD5. To perform such an attack, your rogue AP will also have to be a rogue RADIUS server providing fake credentials in the form of always positive authentication reply to the deceived client hosts. As you will see later, setting both a rogue access point and a RADIUS server on a laptop is not as difficult as you might think. However, such an attack would have a limited use, because the current 802.1x solutions support mutual (client-to-server and server-to-client) authentication and will use EAP-MD5 as a fallback solution only.

Wired man-in-the-middle attacks can be performed using DNS spoofing, ARP cache poisoning, or sneaking into the switch room and changing some cable plug-in positions (a la Kevin Style). Wireless man-in-the-middle attacks are akin to the latter case, but you can be miles away from the switch room. Man-in-the-middle attacks on WLANs can occur on both the first and second OSI layers. Layer 1 man-in-the-middle attacks refer to jamming an existing wireless AP while providing your own clear signal AP at least five channels away from the attacked AP channel. The jamming can be performed using a specific jamming device or by flooding the AP channel with junk traffic (e.g., using FakeAP, Void11 or File2air). If a jamming device is used, the defending side will need a decent frequency analyzer to detect the jamming attack; traditional wireless IDS won't help.

Of course, the parameters of your rogue AP (ESSID, WEP, MAC) should reflect the parameters of the legitimate access point. Layer 2 attacks differ by using a spoofed deassociation or deauthentication frames flood to kick the target host from its link with a legitimate AP. This is generally more efficient than the channel jamming. A determined attacker can easily combine both Layer 1 and Layer 2 attacks to reach the maximum effect. The majority of modern client cards will detect the new rogue AP on a channel different from the one they currently use and automatically associate with it if the association with the legitimate AP has been made hard or impossible. However, if the clients are preset to work at the specific frequency only, the chances of a successful man-in-the-middle attack are dramatically decreased because the attack will depend on outspoofing or outpowering the legitimate AP on the channel it runs. Such an attempt is likely to end up as a DoS attack due to the RF interference.

When launching man-in-the-middle attacks, you don't have to pose as an access point in all cases; sometimes an attacker might want to knock off a selected client host and substitute his or her machine as that host to the access point and the rest of the network. This task is significantly easier: A client host is likely to have lower EIRP, so you don't have to set your host as an access point (emulating the attacked host's IP and MAC is enough) and a quick man-in-the-middle attack against a single host is less likely to cause user complaints and disturbance in the logs. Besides, you can be closer to the victim machine than you are to the access point.

DIY: Rogue Access Points and Wireless Bridges for Penetration Testing

Many wireless security literature sources depict wireless man-in-the-middle attackers as people carrying hardware access points and accumulator batteries around. Frankly, this is ridiculous and makes it sound more like a van-in-the-middle attack. How long would you be able to wander around with a heavy battery, an access point, a laptop, cables, and antennas? Also, it is much easier to hijack connections and inject data if you do it on one of the hijacking machine network interfaces rather than force a hardware access point in a repeater mode to route all traffic through the Ethernet-connected attacking host (how would you do it in reality?). Thus, the optimal solution is to set a software-based access point on a client card plugged into the attacker's laptop (or even PDA). A second plugged-in card can be used as a jamming/frame-generating device to bring down a legitimate AP. Both cards might have to run using different drivers or at least be produced by different vendors to provide proper functionality separation. Several variations of the attack exist, such as using two bridged access point-enabled client cards or using two laptops instead of one, with the obvious functionality of one being used as an access point and another as a DoS-launching platform.

The access point functionality can be set using the following:

  • HostAP and Prism54g on Linux (Prism chipset cards)

  • HermesAP drivers on Linux (Hermes chipset cards)

  • Patched Orinoco driver + monkey_jack on Linux (Hermes chipset cards)

  • Ifconfig mediaopts hostap paramater or WiFi BSD drivers on FreeBSD (Prism chipset cards)

  • wicontrol mediaopt hostap paramater on Open and NetBSD (Prism chipset cards)

  • ZoomAir Access Point software on Windows 95/98/NT/2000 (ZoomAir cards only, these cards have a Prism chipset)

Our discussion will be mainly devoted to Linux-based access points, because we had more play time with them. There is nothing wrong with using BSD-based APs in wireless security auditing. A Windows-based ZoomAir access point is easy to set up, but offers limited functionality, and there are hardly any decent hijacking or traffic injection tools for the Microsoft platform.

The easiest way to launch a man-in-the-middle attack is by using the monkey_jack utility provided with AirJack, assuming your AirJack compilation and configuration went well as we described in Chapter 5:

arhontus:~# ./monkey_jack
Monkey Jack: Wireless 802.11(b) MITM proof of concept.
Usage: ./monkey_jack -b <bssid> -v <victim mac> -C <channel number> [ -c <channel number>
ccc.gif ] [ -i <interface name> ] [ -I <interface name> ] [ -e <essid>  ]                  ]
   -a:  number of disassociation frames to send (defaults to 7)
   -t:  number of deauthentication frames to send (defaults
   to     0)
   -b:  bssid, the mac address of the access point (e.g.
   -v:  victim mac address.
   -c:  channel number (1-14) that the access point is on,
   defaults to current.
   -C:  channel number (1-14) that we're going to move them to.
   -i:  the name of the AirJack interface to use (defaults to
   -I:  the name of the interface to use (defaults to eth1).
   -e:  the essid of the AP.

Supply all the necessary parameters, press Enter, and see your host's Hermes/Orinoco chipset card being inserted between the target host on the WLAN and the access point. To amplify the attack on the first layer, use the highest EIRP you can reach with your cards and available antennas on both flooding and the AP cards. Try -v FF:FF:FF:FF:FF:FF for a weapon of mass deception.

Alternatively you can set an access point employing two Prism chipset cards and hostap drivers and use FakeAP as a channel flooding tool on one of the cards, while the second card runs in a Master mode (AP). Flooding a channel with beacons is not as efficient as sending deauthentication frames, so you might opt for combining one card running under HostAP and one using airjack_cs. To do the latter, edit the /etc/pcmcia/config file and bind one card to the "hostap_cs" and another to "airjack_cs" modules. Restart the PCMCIA services, insert both cards, and go. Use wlan_jack or fata_jack to deassociate hosts from the network AP. Alternatively, you can stick to HostAP drivers only, install Libradiate, and use omerta to generate deassociation frames sent by one of the cards. Even better, you can strike with Void11 using an opportunity to deauthenticate multiple hosts, run concurrent floods, or even try to take down the legitimate access point with authentication or association frames bombardment. The choice is yours.

Installing and setting HostAP drivers is very easy. Grab the latest version of HostAP from the CVS at http://hostap.epitest.fi/, do make && make_pccard as root (we assume you use a PCMCIA client card), restart the PCMCIA services, and insert your card. You should see something like this:

arhontus:~# lsmod

Module                  Size  Used by    Tainted: P
hostap_cs              42408   0  (unused)
hostap                 61028   0  [hostap_cs]
hostap_crypt            1392   0  [hostap]

arhontus:~# iwconfig
wlan0     IEEE 802.11b  ESSID:"test"
Mode:Master  Frequency:2.422GHz  Access Point: 00:02:6F:01:ab:cd
      Bit Rate:11Mb/s   Tx-Power:-12 dBm   Sensitivity=1/3
      Retry min limit:8   RTS thr:off   Fragment thr:off
      Encryption key:off
      Power Management:off
      Link Quality:0  Signal level:0  Noise level:0
       Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
       Tx excessive retries:0  Invalid misc:425   Missed beacon:0

The card automatically runs in the access point (Master) mode with the default ESSID "test." Note that if you insert a Hermes chipset card, it will work with hostap_cs, but you cannot place it into the Master or Repeater modes, the interface is eth1, and the default ESSID is blank. To change the card modes use iwconfig <interface> mode ad-hoc || managed || master || repeater || secondary || monitor. Read the fine manpages to learn more about the modes supported. Try the Repeater mode with HostAP and Prism chipset card to insert a rogue repeater into the testing wireless network as another man-in-the-middle attack possibility:

arhontus:~# iwconfig wlan0 channel 1 txpower 100mW mode repeater essid Sly
arhontus:~# iwconfig wlan0
wlan0     IEEE 802.11b  ESSID:"Sly"
Mode:Repeater  Frequency:2.412GHz  Access Point: 00:00:00:00:00:00
          Bit Rate:2Mb/s   Tx-Power=20 dBm   Sensitivity=1/3
          Retry min limit:8   RTS thr:off   Fragment thr:off

Another similar and rather fanciful thing to try is inserting a double card wireless bridge into a point-to-point link (a true man-in-the-middle attack, because the best position for the attacker would be right between the endpoints, in the middle of the Fresnel zone). For this attack you'll need to have bridging and 802.11d (if you want to use the Spanning Tree Protocol, or STP) support enabled in the Linux kernel and bridging tools (http://bridge.sourceforge.net/) installed. Setting a wireless bridge is similar to setting a wireless distribution system (WDS), but you'll have to use another wireless interface on a second card instead of the usual wired interface:

iwpriv wlan0 wds_add 00:22:22:22:22:22
brctl addbr br0
brctl addif br0 wlan1
brctl addif br0 wlan0
brctl addif br0 wlan0wds0
ifconfig wlan1
ifconfig wlan0
ifconfig wlan0wds0
ifconfig br0 <insert IP here> up

Then the bridge can be set to participate in the STP process and add new distribution links automatically. To accomplish the latter, the command prism2_param wlan0 autom_ap_wds 1 is used. As the README.prism2 file outlines, you can use several commands to check the operation of your bridge:

'brctl show' should show br0 bridge with the added interfaces and STP protocol enabled.

'brctl showstp br0' should show more statistics about each bridge port. The state'
ccc.gif parameter should show 'learning' for a few seconds and change to 'forwarding' afterward.
   'brctl showmacs br0' can be used to check behind which bridge port each known MAC address
   ccc.gif is currently allocated.

Now you probably want to become a root bridge on the STP network. Run Ettercap on one of the wireless interfaces, go to the plug-ins selection ("p/P") and select the plug-in lamia. The priority value for the root bridge should be as low as possible—select zero. You might also need to set your MAC address to a lower value in case there is another bridge with a zero priority. When a tie based on a priority value takes place, the lower MAC wins.

Imagine the amount of traffic you will get through on a busy wireless network using such a bridge!

If you only have a Hermes/Orinoco chipset card (we strongly recommend that you have three different chipset cards [Cisco Aironet, Prism, and Hermes] for proper wireless security testing), you can use Hermes-AP (http://www.hunz.org/hermesap.html) to set a software-based access point. HermesAP is much younger than HostAP and lacks many of the features of HostAP, but it is catching up. Installing HermesAP is more complicated than setting up HostAP because both the Hermes card firmware update and orinoco driver/pcmcia-cs patching are required; see the README file (http://www.hunz.org/README). Once set, HermesAP is configurable via Linux Wireless Extensions, and supports WDS, RFMON, and closed ESSIDs. Because we don't know how to generate traffic (other than beacons) with HermesAP, we do not review it any further in the man-in-the-middle attacks discussion. Nevertheless, HermesAP is a very interesting project and we hope that this paragraph will spark more interest in its development and attract more hackers on its side.

Finally, on the BSD side you can set an access point functionality with a command like wicontrol -n foobared -p 6 -f 6 -e 0 (this is an OpenBSD example, as we are going to use Wnet later; -p 6 stands for hostap mode, -f sets channel, -e 0 means WEP is not required to associate). The interface set to act as an access point can then be employed to bombard the network with deassociation and deauthentication frames (Wnet dinject) telling the defenseless hosts to disconnect from the current access point. Yes, this means that under OpenBSD you might not need a second card to perform an efficient man-in-the-middle attack, thus saving some configuration time and a lot of battery power. You will probably need to write a small shell script to make dinject tools send multiple deauthenticate or deassociate frames for a successful DoS attack. Also, don't forget that you are limited to Prism chipset cards only.

Hit or Miss: Physical Layer Man-in-the-Middle Attacks

To conclude the man-in-the-middle attack section, we would like to share some thoughts on Layer 1 attack attempts. On a physical layer there are two possible avenues reinforcing a chance of a successful man-in-the-middle assault:

  1. Network management is restricted by the legal FCC, ETSI, or equivalent EIRP output regulations. At the same time, the attackers do not care about these restrictions (when an attack is launched the law is broken anyway) and can easily surpass all legal power output limits imposed. For instance, a cracker can use a powerful 23 dBm (200 mW) PCMCIA client card with a decent gain antenna (e.g., 24 dBm dish or grid directional). The EIRP would reach about 45 dBm (subtract 2–3 dBm for the obvious connectors and pigtail loss), which equals about 31.62 W of output. Such output is much higher than the legally permitted 1 W point-to-multipoint wireless LAN EIRP and should be significantly higher than the allowed EIRP on the majority of point-to-point wireless links deployed.

  2. 802.11 hosts are supposed to associate with a wireless access point on the basis of basic error ratio (BER). In practical terms, it comes down to the signal strength and SNR ratio, assuming all other parameters such as ESSID and WEP key are correct. Theoretically, introducing the rogue access point with a very high EIRP as described earlier should be able to force the hosts on a WLAN to associate with the rogue and not the legitimate AP. The reality is not that simple, as many wireless clients tend to reassociate with the AP they were associated with before and will only change the frequency to a different one in case of a very powerful RF noise flood hitting the used channel. These association choice features are usually built into the card's firmware. In several cases, such as the AirPort client card configuration under Mac OS X, it is possible to configure manually whether the host will join the AP with the highest SNR or stick with the most recently associated access point. Of course, roaming WLANs are at greater danger from physical layer man-in-the-middle attacks, because roaming hosts should associate on the basis of AP signal strength. Nevertheless, for the reasons outlined earlier, Layer 1 man-in-the-middle wireless attacks are rather unreliable and should be supplementary to the data link attacks employing targeted deassociation and deauthentication frame floods.

Phishing in the Air: Man-in-the-Middle Attacks Combined

A man-in-the-middle attack does not have to be limited to a single layer. Just like the defense-in-depth would cover all seven layers of the OSI model, so can the attack-in-depth, efficiently sneaking under and over the safeguards deployed. Consider the possible disadvantages of the Layer 1 man-in-the-middle attack we have discussed. Nevertheless, if both Layer 1 and Layer 2 attacks are combined, the outcome is almost certain. Not only do you deassociate the hosts from the network AP to lure them to yours, you also outpower the AP, making sure that your rogue AP is preferred. At the same time, you can flood the legitimate AP channel with noise.

This is not hard to accomplish. For example, you can combine the HostAP Master mode (the rogue AP >= 5 channels away) with FakeAP (generating noise on the network AP channel) and Void11 (single or mass host deassociation). If EAP-MD5 is used on the network, you can add the hostapd authenticator and authentication server functionality to trick the connecting hosts into an association with your rogue AP and obtain the password. In a few pages, we review this attack in more detail. Finally, if higher layer security protocols such as SSH or SSL are involved, you can add man-in-the-middle attacks against these protocols to the combined Layers 1 and 2 man-in-the-middle attack for the full efficiency.

An interesting and rather specific case is when the wireless access point or authentication server uses Web-based user authentication, as commonly done by wireless hotspots. This can be performed using NoCat (see Chapter 13) or by employing various proprietary hotspot user authentication solutions. In such a case, the appearance of the user login Web page defines the trust. Once you can fake the page, the unsuspecting users would happily log in and enter their credentials, only to be told later that "a network error has occurred and the connection was lost." Even better, a sequence of other Web pages can be faked to present the target with common login pages (e.g., eBay, Paypal, Hotmail) for more credentials to grab. A suite to abuse users' trust in such a sneaky way is called Airsnarf. It doesn't matter if the connection uses SSL or PGP keys a la NoCat, the end users won't know it and some of them will inevitably associate with the rogue AP and enter their credentials. The question is how many of them. Airsnarf, as presented first at Defcon 11, uses Layer 1 outpowering to overcome the legitimate network AP. This, of course, brings in all the previously discussed problems of Layer 1 man-in-the-middle attacks. What if the clients are set to use a specific channel? What if the interference is too strong? What if the rogue AP is PDA-based and uses a casual built-in antenna in a CF client card, whereas the AP under attack has a high IR value and is connected to a high gain antenna via an amplifier?

This is exactly the case when combining a Layer 1 and Layer 2 attack is necessary for success. The Airsnarf + HostAP + Void11 + FakeAP combination immediately comes to mind. In fact, a determined attacker can also try to shut the legitimate access point down at the same time. This can be done using other instances of Void11, hammering the AP with authentication and association frame floods. If the attacker can associate with the hotspot or is an already associated rogue user, he or she can launch higher layer DoS attacks to disable the network AP first. Such attacks can be SNMP-based (how many users or "administrators" don't change the default community names?) or employ more traditional DoS attacks, such as SYN flooding. We found out that many commonly deployed access points have problems dealing with intensive traffic using large packets and can be knocked out by ping -s 65507 -f or similar actions. At the same time the rogue AP, perhaps a Zaurus PDA in the attacker's pocket using Airsnarf from an ipkg package, will entrap unsuspecting users and snatch their user names and passwords. This underlines the necessity of profound AP testing for resistance to various common higher layer attacks as well as known Layer 2 wireless threats before the production cycle starts. If, in the process of a security audit, a penetration tester can crash or freeze the AP, too bad. This isn't just a DoS attack; it signifies an additional vulnerability of every host on the tested WLAN to the man-in-the-middle menace. To reduce this particular threat, make sure that any kind of AP management from the wireless side is turned off completely and no open AP ports are presented to the users on the WLAN.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information

To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.


Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.


If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information

Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.


This site is not directed to children under the age of 13.


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information

If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information

Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents

California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure

Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact

Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice

We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020