Home > Articles

This chapter is from the book

Breaking the Secure Safe

The final barriers you might need to bypass to associate with the wireless network are 802.1x-based authentication and higher layer VPNs. Attacking 802.1x and VPNs requires prior knowledge of the involved protocol's structure and operation. We strongly suggest reading Chapters 10 and 13 to learn more about 802.1x/EAP and Chapter 14 to review common VPN protocols before trying to understand the attacks we describe here.

Crashing the Doors: Authentication Systems Attacks

If the 802.1x implementation protecting the attacked network is using EAP-TLS, EAP-TTLS, or EAP-PEAP (reviewed in the Defense part of the book), the cracker might be out of luck and have to resort to DoS, social engineering, or wired side attacks against the certificate server or authority. There are theoretical investigations into possible man-in-the-middle attacks against tunneled authentication protocols—see "The Compound Authentication Binding Problem" IETF draft at http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-02.txt. Only time will tell if practical implementations of such attacks will come into existence. In a few cases, EAP-TTLS might be set to use older authentication methods such as MS-CHAP. These methods are vulnerable to an attack should the attacker manage to insert himself or herself into the tunnel.

An improved dictionary attack or plain old brute-force approach can be taken against Cisco EAP-LEAP because it employs user passwords, not host certificates. The EAP-LEAP dictionary attack improvement, first presented by Joshua Wright at Defcon 11, represents a formidable threat to WLANs that depend on LEAP security features. The main principle behind the attack is EAP-LEAP using MS-CHAPv2 in the clear to authenticate users. Thus, it inherits several MS-CHAPv2 flaws including plaintext user names transmission, weak challenge/response DES key selection, and an absence of salt in the stored NT hashes. Let us take a closer look at how the LEAP challenge/response operates. First, the authenticator (access point) sends a random 8-bit challenge to the supplicant (client host). The supplicant uses an MD4 hash of the authentication password to generate three different DES keys. Each of these keys is used to encrypt the challenge received and the ciphertext (3 x 64 = 192 bits in total) is sent back to the authenticator as a response. The authenticator checks the response and issues an authentication success or failure frame back to the supplicant, depending on the result.

Unfortunately, five nulls are consistent in every LEAP challenge/response exchange, making the third DES key weak. Because the challenge is known, calculating the remaining two DES keys takes less than a second. The trouble is that the third flawed DES key allows calculating the last two bits of the NT hash, leaving only 6 bytes to brute-force or run against a dictionary. That should not be difficult, because MD4 is fast, resource-economical, and insecure.

The attack against EAP-LEAP implemented by Joshua Wright in his Asleap-imp tool is as follows:

  • Calculate a large list of MD4-hashed passwords.

  • Capture EAP-LEAP challenge/response frames.

  • Extract challenge, response, and username.

  • Use the response to calculate the last two bits of the MD4 hash.

  • Run the dictionary attack against the hash taking the two known last bits into account.

Another tool that uses the same attack against EAP-LEAP and was posted to the public domain is Leap. Check out the detailed description of leapcrack, leap, and Asleap-imp use in Chapter 6.

EAP-MD5, the original (and fallback) implementation of EAP, is vulnerable to man-in-the-middle attacks against the AP because there is no AP/server-to-host authentication. A rogue access point placed between the EAP-MD5 supplicant and the RADIUS server can easily snatch the user credentials sent to the authentication server and even authenticate users employing false credentials. To perform such an attack, the cracker might install RADIUS on the rogue AP host and direct user traffic to this illicit RADIUS server. An alternative path is to employ the HostAP hostapd daemon-supported minimal coallocated authentication server. This server requests the identity of the wireless client and will authorize any host capable of sending a valid EAP Response frame. No keys are required and any client can authenticate. This is not the functionality you would like to employ in a real-world access point, but for a man-in-the-middle attack in the process of penetration testing it is really what the doctor ordered. To start hostapd with the authentication server capability, use the hostapd -xm wlan0 command. When the hostapd authentication server is enabled, clients not supporting 802.1x will not be able to send data frames through the rogue AP.

Finally, there is a whole spectrum of DoS attacks against various implementations of EAP:

  • DoS attacks based on flooding with EAPOL-Start frames. A cracker can try to crash the access point by flooding it with EAPOL-Start frames. The way to avoid this attack is to allocate limited resources on receipt of an EAPOL-Start frame.

  • DoS attacks based on cycling through the EAP Identifier space. A cracker can bring down the access point by consuming all EAP Identifier space (0–255). As the EAP Identifier is required to be unique within a single 802.1x port only, there is no reason for an AP to lock out further connections once the Identifier space has been exhausted. Nevertheless, some access points do just that.

  • DoS attacks against clients based on sending premature EAP Success frames. The IEEE 802.1x standard enables a client to avoid bringing up its interface if the required mutual authentication is not completed. This allows a well-implemented supplicant to avoid being tricked by a rogue authenticator AP flooding with premature EAP Success frames.

  • DoS attacks against clients based on spoofing EAP Failure frames. The EAP specification requires supplicant clients to be able to use alternative indications of successful or failed 802.1x authentication. Thus, a well-implemented supplicant should not be fooled by a cracker flooding the network with EAP Failure frames. A supplicant that receives EAP-Failure frames from a rogue authenticator outside of the legal 802.1x exchange should ignore the frames. Not all supplicant clients possess such capability. If the proper authenticator AP wishes to remove the supplicant client, it would follow the EAP failure by the deassociation frame. There is nothing to stop attackers from imitating such a situation. File2air is the current tool of choice to launch such attacks.

  • DoS attacks using malformed EAP frames. An example of such an attack is a FreeRADIUS 0.8.1 crash caused by an EAP TLS packet with flags 'c0' and with no TLS message length or TLS message data. This attack was reported at http://www.mail-archive.com/freeradius-users@lists.cistron.nl/msg15451.html.

How about practical implementations of these attacks? Unfortunately, there is no Nemesis or Wnet-style custom frame-generation toolkit for 802.1x/EAP at the time of writing. As mentioned earlier, you can always try to create your EAP frames in binary and send them using File2air. Besides, QA Cafe has released a commercial EAP-testing Linux suite they call EAPOL (http://www.qacafe.com/eapol/). You can only run EAPOL using Cisco Aironet 350 cards. A demo version of the suite, which includes binaries for Red Hat and Debian distribution, is available for download from the QA Cafe Web site. Here is the description of all tests supplied by the demo version of EAPOL as stated at http://www.qacafe.com/eapol/test-summary-demo.htm#4:

Authenticator sends EAPOL packets to supplicant's unicast MAC address:

Description:
  step 1. Send EAPOL-Logoff to place controlled port in
  unauthorized state
  step 2. Send EAP-Start to initiate authentication
  step 2. Wait for EAPOL packet from Authenticator (up to txWhen
  seconds)
  step 3. Verify destination MAC address is supplicant's MAC
  address

  Reference: IEEE Std 802.1X-2001
  Section 7.8 EAPOL Addressing

  NOTE: The authenticator should be in the CONNECTING state after the EAPOL-Logoff
ccc.gif/EAPOL-Start packets are sent by the supplicant.
   

Basic case of authenticator-initiated authentication:

Description:
  step 1. Send EAPOL-Logoff to place controlled port in
  unauthorized state
  step 2. Initiate ICMP Ping on LAN port to Trusted host
  step 3. Continue ping attempts for 120 seconds
  step 4. Verify authentication occurs for the configured type
  step 5. Verify ICMP ping to Trusted host

  Reference: IEEE Std 802.1X-2001
  Section 8.4.2.1 Authenticator initiation

Basic case of supplicant-initiated authentication:

Description:
  step 1. Send EAPOL-Logoff to place controlled port in
  unauthorized state
  step 2. Send EAPOL-Start to initiate authentication process
  step 3. Verify authentication occurs for the configured type
  step 4. Verify ICMP ping to trusted host

  Reference: IEEE Std 802.1X-2001
  Section 8.4.2.2 Supplicant initiation

Authenticator sends EAP Failure after supplicant sends EAP-Logoff:

Description:
  step 1. Send EAPOL-Logoff to place controlled port in
  unauthorized state
  step 2. Wait up to 15 seconds for EAP Failure packet from
  Authenticator

    Reference: IEEE Std 802.1X-2001
    Section 8.5.4.4 Disconnected

Authenticator sends EAP Failure if identity is unknown:

Description:
  step 1. Configure the supplicant to use unknown identity
  step 2. Send EAP-Start
  step 3. Wait for EAP Identity request
  step 4. Respond with unknown identity
  step 5. Verify an EAP Failure is received

  Reference: IEEE Std 802.1X-2001
  Section 8.5.8.6 FAIL

  NOTE: This test uses the Identity 'badUserName' which must not
  be a valid user name on your Backend authentication server.

The test summary of the full EAPOL suite gives an idea of how many possible DoS attacks against the EAP do exist. The summary can be viewed at http://www.qacafe.com/eapol/test-summary.htm. The EAPOL setup for wireless 802.1x authentication testing needs a Linux machine with one Ethernet and wireless interface. One interface of the EAPOL-running host is the 802.1x supplicant interface connected to the authenticator device (access point). The second interface must be connected to the trusted part of the device (access point Ethernet port) or network that does not require 802.1x authentication (wired LAN into which the tested AP is plugged). EAPOL is a lab testing suite for wireless security software and protocol developers, beta testers, and security consultants, not a canned "script kiddie" DoS tool. However, because the information about attacks exists "in the wild," we expect that hacked-up Xsupplicant clients and HostAP-based authenticators implementing the attacks described are under development in the hacker community and will surface soon.

To summarize, the main problem of EAP frames is the same with the 802.11 management and control frames: lack of proper authentication and integrity protection (secure checksums).

Tapping the Tunnels: Attacks Against VPNs

Attacks on higher layer VPNs is hardly a wireless-specific topic that surely deserves a book of its own. Here we can only provide some directions for a security professional or enthusiast to follow in his or her future research into it. Point-to-Point Tunneling Protocol (PPTP) and various IPSec implementations are the most common VPN solutions encountered. PPTP took a heavy battering from the security community and multiple tools have built-in options to attack PPTP tunnels. Anger is one such tool:

arhontus:~# ./anger -- h

usage: anger [ -v ] [ -d device ] output1 [ output2 ]

Write sniffed challenge/responses to output1.
If output2 is given it will perform an active attack on
PPTP connections and write the password hashes to output2.

     -d    Device to open for sniffing.
     -v    Some diagnostics.

As the documentation packaged with the tool states, Anger is a PPTP sniffer and attack utility. It sniffs PPTP MS-CHAP challenge/response packets and outputs them in a format suitable for feeding to the infamous L0phtcrack password cracking program. Anger implements an active attack against the MS-CHAPv1 password change protocol. When the sniffer detects a PPTP client attempting to log in using MS-CHAPv1, it fakes a password change command from the server. If the deceived user follows the dialog to change his or her password, Anger logs the hashes of the current password as well as the hashes of the new password chosen. These hashes can be given to L0phtcrack to crack the password or be used with a hacked-up PPP client for use with the Linux PPTP client to log onto the network. There are other utilities implementing the PPTP password change attack besides Anger, such as deceit by Aleph One (http://packetstormsecurity.nl/new-exploits/deceit.c).

After the publication and exploitation of flaws in the MS-CHAP protocol, Microsoft released a new version of MS-CHAP. This new version is not vulnerable to the password change attack. It does not perform a challenge/response authentication based on the weak LM hashes, and possesses the capability of server authentication. Microsoft has added a number of new steps to the response-to-challenge generation and implemented SHA1 hashing. However, the sniffer can still precompute hashes, and L0phtcrack does not require any changes to handle MS-CHAPv2 cracking.

The latest versions of Anger support sniffing MS-CHAPv2 challenge/response packets. The outlines for MS-CHAPv2 have the LM hash set to all zeros, as it is not available. Unfortunately, it is not possible to use the command-line version of L0phtcrack to crack MS-CHAPv2 entries because it does not attempt to get the NT response via a dictionary attack, unless there is an LM response present. However, you can use the Windows GUI version of L0ptcrack to crack the MS-CHAPv2 entries. In such a case, you must disable the cracking of the LM hash and enable cracking of the NT hash in the L0ptcrack options panel because L0phtcrack will not recognize the all-zeros LM response field as invalid and will still try to crack it. Replacing this field with something else leads to a parsing error.

Ettercap possesses a whole collection of plug-ins written to sniff PPTP tunnels, decapsulate traffic, and get user log-in passwords:

H03_hydra1  1.1   -- PPTP: Gets the passwords
H04_hydra2  1.0   -- PPTP: Decapsulates connections
H05_hydra3  1.0   -- PPTP: Forces renegotiation
H06_hydra4  1.0   -- PPTP: Forces PAP authentication
H07_hydra5  1.0   -- PPTP: Tries to force cleartext
H08_hydra6  1.0   -- PPTP: Forces chapms from chapmsv2

If you use PPTP on your WLAN, you should know how disruptive these plug-ins can be if PPTP is the only or best defensive measure standing between the cracker and WLAN traffic. If your interest in PPTP security lies beyond trying a few of the underground attack tools available, recommended reading includes "Cryptanalysis of Microsoft's PPTP Authentication Extensions (MS-CHAPv2)" by Bruce Schneier and Dr. Mudge (http://www.counterpane.com/pptpv2-paper.html) and a follow-up to this paper published by Team Teso (http://www.team-teso.net/releases/chap.pdf).

The main prerequisite to attacking IPSec VPNs is understanding how IPSec works. Without such an understanding, the discussion here makes little sense. Skip to Chapter 14 to learn more about the workings of the IPSec protocol and you will see that actually there is no such thing as an attack against IPSec; there are only attacks against specific IPSec modes or implementations. IPSec implementations that have known security problems such as buffer overflows or man-in-the-middle attack susceptibilities include the following:

  • Cisco VPN Client 3.5

  • Cisco VPN Client 1.1

  • SafeNet/IRE SoftPK and SoftRemote

  • PGPFreeware 7.03 - PGPNet

  • WAVEsec

To poke around the IPSec-protected LAN use IKEProber.pl by Anton T. Rager or Ike-scan by Roy Hills. IKEProber and Ike-scan are Internet Key Exchange (IKE) packet manglers written to discover and fingerprint IKE-running hosts. The command syntaxes of both tools is as follows:

arhontus:~# ./ike-scan -h
Usage: ike-scan [options] [hosts...]
Hosts are specified on the command line unless the --file option is specified.

Options:

--help or –h  Display this usage message and exit.

--file=<fn> or -f <fn>
     Read hostnames or addresses from the specified file instead of from the command line.
ccc.gif One name or IP address per line.  Use "-" for standard input.
   
   --sport=<p> or -s p     Set UDP source port to <p>, default=500, 0=random.
   Some IKE implementations require the client to use UDP   source port 500 and will not
   ccc.gif talk to other ports. Note that superuser privileges are normally required to use nonzero
   ccc.gif source ports below 1024.  Also only one process on a system may bind to a given source
   ccc.gif port at any one time.
   
   --dport=<p> or -d p
   Set UDP destination port to <p>, default=500. UDP port 500 is the assigned port
   ccc.gif number for ISAKMP and this is the port used by most if not all IKE implementations.
   
   --retry=<n> or -r n     Set total number of attempts per host to <n>, default=3.
   
   --timeout=<n> or -t n
   Set initial per-host timeout to <n> ms, default=500. This timeout is for the first
   ccc.gif packet sent to each host. Subsequent timeouts are multiplied by the backoff factor which
   ccc.gif is set with backoff.
   
   --interval=<n> or -i <n>
   Set minimum packet interval to <n> ms, default=75. This controls the outgoing
   ccc.gif bandwidth usage by limiting the rate at which packets can be sent.  The packet interval
   ccc.gif will be greater than or equal to this number and will be a multiple of the select wait
   ccc.gif specified with --selectwait.  Thus --interval=75 –selectwait=10 will result in a packet
   ccc.gif interval of 80 ms. The outgoing packets have a total size of 364 bytes (20 bytes IP hdr +
   ccc.gif 8 bytes UDP hdr + 336 bytes data) when the default transform set is used, or bytes if a
   ccc.gif custom transform is specified.  Therefore for default transform set: 50 = 58240bps, 80 =
   ccc.gif 36400bps and for custom transform: 15 = 59733bps, 30 = 35840bps.
   
   --backoff=<b> or -b <b>   Set timeout backoff factor to <b>, default=1.50.
   The per-host timeout is multiplied by this factor after each timeout.  So, if the
   ccc.gif number of retrys is 3, the initial per-host timeout is 500 ms and the backoff factor is 1
   ccc.gif.5, then the first timeout will be 500 ms, the second 750 ms and the third 1125 ms.
   
   --selectwait=<n> or -w <n>
   Set select wait to <n> ms, default=10. This controls the timeout used in the select
   ccc.gif(2) call. It defines the lower bound and granularity of the packet interval set with --
   ccc.gif interval. Smaller values allow more accurate and lower packet intervals; larger values
   ccc.gif reduce CPU usage.  You don't need to change this unless you want to reduce the packet
   ccc.gif interval close to or below the default select wait time.
   
   --verbose or -v
   Display verbose progress messages. Use more than once for greater effect:
   1 - Show when hosts are removed from the list and when packets with invalid cookies
   ccc.gif are received.
   2 - Show each packet sent and received.
   3 - Display the host and backoff lists before scanning starts.
   
   --lifetime=<s> or -l <s>
   Set IKE lifetime to <s> seconds, default=28800. RFC 2407 specifies 28800 as the
   ccc.gif default, but some implementations may require different values.
   
   --auth=<n> or -m <n>
   Set auth. method to <n>, default=1 (preshared key). RFC defined values are 1 to 5. 
   ccc.gif See RFC 2409 Appendix A.
   
   --version or -V
   Display program version and exit.
   
   --vendor=<v> or -e <v>
   Set vendor id string to MD5 hash of <v>. Note: this is currently experimental.
   
   --trans=<t> or -a <t>
   Use custom transform <t> instead of default set. <t> is specified as enc,hash,auth,group.
   e.g., 2,3,1,5.  See RFC 2409 Appendix A for details of which values to use.For
   ccc.gif example, --trans=2,3,1,5 specifies Enc=IDEA-CBC, Hash=Tiger, Auth=shared key, DH Group=5
   If this option is specified, then only the single custom transform is used rather
   ccc.gif than the default set of 8 transforms.  As a result, the IP packet size is 112 bytes rather
   ccc.gif than the default of 364.
   
   --showbackoff[=<n>] or -o[<n>]
   Display the backoff fingerprint table. Display the backoff table to fingerprint the
   ccc.gif IKE implementation on the remote hosts. The optional argument specifies time to wait in
   ccc.gif seconds after receiving the last packet, default=60. If you are using the short form of
   ccc.gif the option (-o) then the value must immediately follow the option letter with no spaces, e
   ccc.gif.g. -o25 not -o 25.
   
   --fuzz=<n> or -u <n>     Set pattern matching fuzz to <n> ms, default=100.
   This sets the maximum acceptable difference between the observed backoff times and
   ccc.gif the reference times in the backoff patterns file.  Larger values allow for higher variance
   ccc.gif but also increase the risk of false positive identifications.
   
   Report bugs or send suggestions to ike-scan@nta-monitor.com
   See the ike-scan homepage at http://www.nta-monitor.com/ike-scan/
   
   arhontus:~# perl IKEProber.pl
   ikeprober.pl V1.13 -- 02/14/2002, updated 9/25/2002
   By: Anton T. Rager - arager.com
   
   Usage:
   -s SA [encr:hash:auth:group]
   -k x|auser value|user value [KE repeatedX
   times|ascii_supplied|hex_supplied]
   -n x|auser value|user value [Nonce repeatedX
   times|ascii_supplied|hex_supplied]
   -v x|auser value|user value [VendorID
   repeatedX|ascii_supplied|hex_supplied]
   -i x|auser value|user|rawip value [ID
   repeatedX|ascii_supplied|hex_supplied|Hex_IPV4]
   -h x|auser value|user value [Hash
   repeatedX|ascii_supplied|hex_supplied]
   -spi xx [SPI in 1byte hex]
   -r x [repeat previous payload x times]
   -d ip_address [Create Init packet to dest host]
   -eac [Nortel EAC transform - responder only]
   -main [main mode packet instead of aggressive mode - logic
   will be added later for correct init/respond]
   -sa_test 1|2|3|4 [1=86400sec life, 2=0xffffffff life, 3=192
   group attribs, 4=128 byte TLV attrib]
   -rand randomize cookie
   -transforms x [repeat SA transform x times]
   

Use these tools to discover vulnerable IPSec implementations on LAN, download appropriate exploit code, compile it, and give it a try.

WAVEsec mobile IPSec implementation is exploitable with kraker_jack from the AirJack suite:

arhontus:~# ./kracker_jack
Kracker Jack: Wireless 802.11(b) MITM proof of concept (with a bite).

Usage: ./kracker_jack -b <bssid> -v <victim mac> -C <channel number> [ -c <channel number> ]
V <victims ip address> -s <server mac>  -S <server ip address>
[ -i <interface name> ] [ -I <interface name> ] [ -e <essid> ]
n <netmask> -B <broadcast address>

-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.,
     00:de:ad:be:ef:00)
-v:  victim mac address
-V:  victim's ip address
-s:  wavesec server mac address
-S:  wavesec server ip address
-B:  network broadcast address
-n:  netmask 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 aj0)
-I:  the name of the interface to use (defaults to eth1)
-e:  the essid of the AP

If you want to find more on how kracker_jack performs a man-in-the-middle attack against WAVEsec, check out Abaddon's Black Hat briefings presentation at http://802.11ninja.net/bh2002.ppt.

As a less specific attack against IKE, you can try IKECrack, which works against IKE phase 1 aggressive mode and MD5_HMACs only. IKECrack (ikecrack-snarf-1.00.pl on the site) is a Perl script that takes a pcap-format file as an input and attempts a real-time brute-force of the PSK.

Finally, a desperate attacker can resort to DoS attacks against IPSec, perhaps to force the system administrator to bring down the IPSec tunnel for a while to determine what went wrong. If there is mission-critical traffic on the wireless link, the attacker's hope is that it will be allowed to pass unprotected while the network administration is searching for the source of the IPSec tunnel failure. A cracker can try to stop ISAKMP for IPSec traffic with a H09_roper Ettercap plug-in (likely to work only against the aggressive IKE mode). Less specific attacks such as flooding UDP port 500 on IKE-running hosts can also be launched. There is a report (http://www.securiteam.com/windowsntfocus/6N00G0A3FO.html) that continuous flooding of UDP 500 port on a Windows 2000 machine with large (more than 800 bytes) UDP packets can use all available CPU cycles and lock up the targeted machine.

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.

Overview


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.

Surveys

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.

Newsletters

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.

Security


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

Children


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

Marketing


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.

Choice/Opt-out


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.

Links


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