Domain: united.com
Stories and comments across the archive that link to united.com.
Stories · 12
-
Ethical Hackers Donate 1,000,000 Air Miles To Charity (offensi.com)
An anonymous reader writes:Certified ethical hackers at Offensi.com identified a bug allowing remote code execution on one of United Airlines' sites, and submitted their findings to the airline's "bug bounty" program. After a fix was placed into production, their team was awarded 1,000,000 Mileage Plus air miles, which they say was accompanied by an email informing them that the IRS would consider their award as $20,000 of taxable income. "If after evaluating the taxable amount you choose not to accept your award, you are also able to donate your award to charity," the e-mail explained. The hackers ultimately chose to distribute their air miles among three charities -- the Ronald McDonald house, the Muscular Dystrophy Association, and the Casa de Esperanza de los Ninos Organization.
Another security researcher complained in November that United failed to close a serious vulnerability he'd identified for almost six months. -
The Army Bug Bounty Program: a Critical Need In Defense (cyberdefensereview.org)
hypercard writes: It seems just about every major tech company and even a few other large non-tech corporations have bug bounty programs as part of an effort to improve security through a community effort. Captains Rock Stevens and Michael Weigand, both Cyber officers in the U.S. Army, recently published Army Vulnerability Response Program, an outline for a legal way of disclosing bugs in Army software and networks. They say, "[T]he Army does not have a central location for responsibly disclosing vulnerabilities found through daily use, much less a program that can permit active security assessments of networks or software solutions. Without a legal means to disclose vulnerabilities in Army software or networks, vulnerabilities are going unreported and unresolved." -
My United Airlines Website Hack Gets Snubbed
Bennett Haselton writes: United Airlines announced that they will offer up to 1 million air miles to users who can find security holes in their website. I demonstrated a way to brute-force a user's 4-digit PIN number and submitted it to them for review, emailing their Bugs Bounty contact address on three occasions, but I never heard back from them. Read on for the rest. If you've had a different experience with the program, please chime in below.United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:
- your e-mail address
- your street address
- your phone number
- your PIN
- your password
- your "old MileagePlus number"
And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.
This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.
I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)
So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.
I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.
It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).
The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.
As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.
I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.
So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.
I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.
And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.
-
My United Airlines Website Hack Gets Snubbed
Bennett Haselton writes: United Airlines announced that they will offer up to 1 million air miles to users who can find security holes in their website. I demonstrated a way to brute-force a user's 4-digit PIN number and submitted it to them for review, emailing their Bugs Bounty contact address on three occasions, but I never heard back from them. Read on for the rest. If you've had a different experience with the program, please chime in below.United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:
- your e-mail address
- your street address
- your phone number
- your PIN
- your password
- your "old MileagePlus number"
And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.
This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.
I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)
So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.
I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.
It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).
The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.
As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.
I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.
So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.
I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.
And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.
-
My United Airlines Website Hack Gets Snubbed
Bennett Haselton writes: United Airlines announced that they will offer up to 1 million air miles to users who can find security holes in their website. I demonstrated a way to brute-force a user's 4-digit PIN number and submitted it to them for review, emailing their Bugs Bounty contact address on three occasions, but I never heard back from them. Read on for the rest. If you've had a different experience with the program, please chime in below.United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:
- your e-mail address
- your street address
- your phone number
- your PIN
- your password
- your "old MileagePlus number"
And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.
This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.
I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)
So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.
I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.
It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).
The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.
As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.
I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.
So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.
I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.
And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.
-
My United Airlines Website Hack Gets Snubbed
Bennett Haselton writes: United Airlines announced that they will offer up to 1 million air miles to users who can find security holes in their website. I demonstrated a way to brute-force a user's 4-digit PIN number and submitted it to them for review, emailing their Bugs Bounty contact address on three occasions, but I never heard back from them. Read on for the rest. If you've had a different experience with the program, please chime in below.United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:
- your e-mail address
- your street address
- your phone number
- your PIN
- your password
- your "old MileagePlus number"
And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.
This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.
I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)
So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.
I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.
It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).
The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.
As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.
I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.
So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.
I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.
And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.
-
My United Airlines Website Hack Gets Snubbed
Bennett Haselton writes: United Airlines announced that they will offer up to 1 million air miles to users who can find security holes in their website. I demonstrated a way to brute-force a user's 4-digit PIN number and submitted it to them for review, emailing their Bugs Bounty contact address on three occasions, but I never heard back from them. Read on for the rest. If you've had a different experience with the program, please chime in below.United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:
- your e-mail address
- your street address
- your phone number
- your PIN
- your password
- your "old MileagePlus number"
And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.
This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.
I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)
So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.
I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.
It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).
The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.
As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.
I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.
So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.
I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.
And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.
-
My United Airlines Website Hack Gets Snubbed
Bennett Haselton writes: United Airlines announced that they will offer up to 1 million air miles to users who can find security holes in their website. I demonstrated a way to brute-force a user's 4-digit PIN number and submitted it to them for review, emailing their Bugs Bounty contact address on three occasions, but I never heard back from them. Read on for the rest. If you've had a different experience with the program, please chime in below.United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:
- your e-mail address
- your street address
- your phone number
- your PIN
- your password
- your "old MileagePlus number"
And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.
This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.
I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)
So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.
I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.
It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).
The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.
As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.
I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.
So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.
I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.
And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.
-
My United Airlines Website Hack Gets Snubbed
Bennett Haselton writes: United Airlines announced that they will offer up to 1 million air miles to users who can find security holes in their website. I demonstrated a way to brute-force a user's 4-digit PIN number and submitted it to them for review, emailing their Bugs Bounty contact address on three occasions, but I never heard back from them. Read on for the rest. If you've had a different experience with the program, please chime in below.United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:
- your e-mail address
- your street address
- your phone number
- your PIN
- your password
- your "old MileagePlus number"
And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.
This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.
I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)
So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.
I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.
It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).
The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.
As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.
I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.
So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.
I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.
And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.
-
My United Airlines Website Hack Gets Snubbed
Bennett Haselton writes: United Airlines announced that they will offer up to 1 million air miles to users who can find security holes in their website. I demonstrated a way to brute-force a user's 4-digit PIN number and submitted it to them for review, emailing their Bugs Bounty contact address on three occasions, but I never heard back from them. Read on for the rest. If you've had a different experience with the program, please chime in below.United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:
- your e-mail address
- your street address
- your phone number
- your PIN
- your password
- your "old MileagePlus number"
And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.
This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.
I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)
So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.
I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.
It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).
The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.
As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.
I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.
So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.
I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.
And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.
-
My United Airlines Website Hack Gets Snubbed
Bennett Haselton writes: United Airlines announced that they will offer up to 1 million air miles to users who can find security holes in their website. I demonstrated a way to brute-force a user's 4-digit PIN number and submitted it to them for review, emailing their Bugs Bounty contact address on three occasions, but I never heard back from them. Read on for the rest. If you've had a different experience with the program, please chime in below.United Airlines announced the program in May (also specifying rules which specifically prohibited hacking in-flight systems, but which included "[t]he ability to brute-force reservations, MileagePlus numbers, PINs or passwords".) I poked around on their website and discovered that on their "Forgot your MileagePlus number?" page, you can request a reset of your password by submitting your first and last name, AND any ONE of the following:
- your e-mail address
- your street address
- your phone number
- your PIN
- your password
- your "old MileagePlus number"
And after submitting your information, the page will tell you whether your information matched an existing MilagePlus customer record.
This means that if you know a user's first and last name, you can guess their PIN, and the MileagePlus site will tell you whether you got it right or not. If the site doesn't limit your number of guesses, you can write a script that iterates through all 10,000 possibilities for the PIN until it finds the right one.
I wrote a script that did exactly that, and brute-forced my own account's PIN in a few hours (submitting one guess at a time, and running at 2 a.m. so as not to impact any other users). This means that United's website is not limiting the number of guesses per IP address, or showing a CAPTCHA after some number of failed attempts, or limiting the number of guesses per hour on a particular account, or any other countermeasures that you might expect. (The Bugs Bounty Program rules state, "[W]e do not allow execution of brute-force attacks on other users," which I interpreted to mean that brute-forcing your own account ought to be fine.)
So, United, if you're reading this, the immediate fix should be to disable the "PIN" option on the "Forgot your MileagePlus Number?" page. Keep the option to retrieve your account number by submitting your password, since even weak passwords are far harder to guess than 4-digit PIN numbers. But get rid of the PIN option.
I mentioned other possible countermeasures, including limiting requests per IP address and showing a CAPTCHA, but I actually don't think either of these would be effective. If you limit requests per IP address, any serious adversary will have a botnet of machines that they can use to submit requests from different addresses. If you make the user type in a CAPTCHA to submit a request, an attacker can hire workers online to read and type in the CAPTCHAs for a penny apiece. If you limit the number of reset attempts per hour on a particular account, that will slow down the attacker's attempts to brute-force the PIN for a particular account. However, if the attacker has a database of 1000 customer names and wants to find PINs for all of them, on Day 1 they could try 10 PINs for customer 1, then 10 PINs for customer 2, and so on up to customer 1000, and then on Day 2 they could try the next set of 10 PINs on customer 1, customer 2, etc. The attacker can't find any particular customer's PIN quickly, but they will be able to recover all of the customers' PINs slowly -- even though they never did more than 10 PIN authentication attempts on any particular account in the same day. Without a safe countermeasure, then, simply getting rid of PIN authentication would be the best fix.
It's because of attacks like this that I would argue that 4-digit PINs should never be used by themselves for authentication, if there's any possibility of a brute-force attack. They should only ever be used (a) for authentication in conjunction with something else, like a password (for example, if you're already logged in to a financial services account, you could require an additional 4-digit PIN to transfer money to another user); or (b) in a scenario where a brute-force attack is infeasible (for example, if you call tech support and a live human operator asks you to authenticate yourself with a 4-digit PIN).
The same attack is probably possible on the MileagePlus login page, since you can log in using your 4-digit PIN as an alternative to your password. However, this is less of a glaring security hole, because to brute-force a someone's PIN number on that page, you would have to at least know their MileagePlus number. The "Forgot Your MileagePlus Number?" page, on the other hand, allows you to brute-force someone's PIN number when all you know is their name.
As is often the case with stolen PINs and passwords, the most harmful effect here would probably not be the compromising of the user's MileagePlus account. The biggest problem is that most users use the same PINs and passwords for multiple accounts, and the attacker now has the 4-digit PIN that the user probably uses for their voicemail password, their ATM card, their burglar alarm, and who knows what else.
I first sent sent two emails about this to United's bug bounty email address reporting the issue on May 23, a few hours apart, and then followed up on June 1 asking if anyone had seen the first messages. I still have not receive a response.
So why didn't United reply? Have they just been receiving too many submissions by email? About 18 months ago I wrote about a researcher who emailed a security hole to Google and never heard back from them, even after they fixed the issue (although Google apologized and paid him his reward after the article ran). I suggested that if email submissions sometimes get back-logged, it would be a more effective approach to have email submissions reviewed by a lower-paid, less-experienced team of interns than by senior security researchers. The principle is that while it takes experience to find and fix security holes, it only takes some simple logical reasoning skills to evaluate whether a particular discovery constitutes a security hole, so the work can be farmed out to interns who want to gain work experience. By having each submission reviewed by, say, 3 randomly chosen interns from your pool of evaluators, you can churn through the submissions faster and reduce the chances of a legitimate bug falling through the cracks.
I'm sure some of the submissions are crap, and it's not United's fault if they initially got behind because they got more mails than they expected. But as soon as they realized they were getting swamped, they should have put more people on it -- even if those extra people were IT interns with just enough computer experience to read a bug description and tell if it was legit.
And one of the interns could also proofread the submission guidelines. Currently, under "things we will pay 250,000 miles for", the program page lists: "Brute-force attacks." Under "things that will result in criminal prosecution," the same page lists: "Brute-force attacks." If United keeps both promises, I hope my air miles don't expire before I get out of jail.
-
United Airlines Invites Hackers To Find Security Vulnerabilities
An anonymous reader writes: Following a recent spike of interest regarding the potential to hack planes, United Airlines has created the first rewards-for-exploits scheme in the aviation industry. The 'Bug-Bounty' program offers up to a million air miles for submitters who find a specific range of exploits in the company's websites and digital infrastructure. The scheme not only bans participants from probing on-board flight systems but threatens criminal prosecution for any such attempt.