In July of 2011, Bryan Halfpap waited for his return flight home to Maryland. A network systems security professional working for a natural resource refiner and energy provider, he had just finished up the near week-long events of the security conference DefCon, in Las Vegas.
Slumped in his waiting chair, tired and bored, with time to kill he popped open his laptop. The sound and visual confirmations of open wireless networks sounded on his computer. McCarran International Airport, the gateway to the neon colored Pleasure Island that is Las Vegas, had free Wi-Fi. And for whatever reason, Halfpap wanted to kill the time by getting to know the airport he was sitting in.
He opened his web browser and pointed it to McCarran.com. With a quick click of a menu Halfpap had popped up the HTML code page of McCarran's website. Like any HTML-powered website, the code of the site is open to the public. It is how all web browsers can read the formatting of individual websites. So nothing digitally fiendish was done when Halfpap started searching through the lines of hypertext markup language and basic web scripting code in the webpage source.
With a quick look over of the code on several of the McCarran.com webpages Halfpap found that the files were being hosted by a Xerox Docushare Content management system (CMS) backend that had its own subdomain. Usually when you visit a subdomain CMS (Content Managment system) you will be greeted with an error display page in your browser. Only the sites and users given access to certain folders should be able to see any files. But that's not always the case. Automated search engines can sometimes see things that secure CMS are suppose to block.
Googling McCarran
Modern search engines index websites; in order for, say, Google to be able to find keywords on sites to load it uses an automated robot process to comb content as well as other links to other websites. If a website links to another site, Google follows that link and reads whatever it can for indexing. The search will keep doing this until all links have been followed and all pages have been indexed. The number of links to other websites gives you a ranking while the context is cached in text form by Google for keyword searches. So multiple sites that link to each other will usually have tons of data to cross reference from sub-pages of a main site. It's how you can find the contact page for McCarran without actually having to go to Mccarren.com first.
But you would think simply Googling "site:McCarran.com" would not turn up anything major from a web-facing hosting server. No one would be that foolish. There is no way a file with sensitive secure information could be found on a major international airport's public website. But being a network security professional Halfpap knew something basic, not everyone remembers to do what they are supposed to do all the time.
In what can only be called the mother of all inept network deployments, guest access was left on this Internet-facing content management system and a file marked PUBLIC that was supposed to be only for the staff of the airport had a sub folder called /security which had the airport's network documentation, security procedures documents, airport terminal hardware manuals and internal financial documents. All of this was found within the first 30 minutes of only basic Googling from his airplane waiting seat, says Halfpap.
In 2010, Las Vegas's McCarran International Airport ranked 22nd in the world for passenger traffic, with 39,757,359 passengers traveling though its terminal. It ranks ninth in the world for "Aircraft movements" with 505,591 takeoffs and landings. McCarran and Clark County Department of Aviation are completely self-sufficient enterprises, requiring no money from the Clark County, Nevada General Fund. With an airport that in the money, with slot machines and top-tier boutique stores inside, you would think it would have network security topping that of any Vegas casino.
Unexpected Find
But when Halfpap got home he was able to recover over 300,000 documents from this content management system made open to the public. While not all files had full guest access, document snippets were still cached and viewable from the guest account. Halfpap estimates that this only makes up about 10 percent of the files hosted on the CMS. The The full list of fields included that he could find without any security breaches and just simple Googling included:
- 600 user profiles and usernames
- 157 email messages
- employee directory
- organizational charts
- manuals for the servers
- deployment procedures for their servers
- deployment procedures for their desktops
- security policies
- network documentation
- network diagrams
- IP addresses
- specifics on their baggage setup
- specifics on how they use the common use terminals for flight check in
There was so much information Halfpap could never search it all. But then he thought, this was open to the web and was being indexed. He then went to Google and typed in "CMS.Mccarren.com PASSWORD" and there is was. Documents upon documents with usernames and passwords for a plethora of internal systems. Nothing he could access without breaking the security of the site but more than enough to do it without ever getting detected.
One thing though peeked Halfpap's interest: a simple manual -- for McCarran's custom-made Unix C airline feed architecture FID Systems (Flight Information Display system). It is the system that used to run the spinning clacking flip card screens telling passengers when and where flights leave. It is the system that controls the new digital screen systems and interfaces with airlines to update flight information online. It uses proprietary protocols that the manual fully explains. Not only that, it has the entire names of all the people who worked on the project inside the manual. The manual, from a purely open, non-hack intelligence level gathering standpoint, is a golden goose of information.
Not only did Halfpap now know the internal workings of the flight system for McCarran Airport, he also learned who wrote the code that ran it. He knew who edited what and where. With Google and job history social profile site Linkedin, he also could see where all the FIDS software developers worked now.
As a network security professional, Halfpap knew this was serious. He gathered a lot of information during a short period of time. Using online Internet tool The Wayback Machine, part of InternetArchive.org, he learned that this guest account access could have been left on with this public folder facing the Internet from as far back as 2003.
Slow Response
Armed with this information he contacted the airport in January 2012 to talk with the CIO or someone in charge of information security. But Halfpap got no response. No voice mails were ever returned. Halfpap tried contacting McCarran Airport via email as well and via its public Twitter account; he got no response.
It was now May of 2012, after several more failed attempts to get the attention of McCarran Airport Halfpap finally contacted a friend of his who worked for a government contractor that had close ties to the FBI. From there an FBI agent contacted an officer in the US Department of Transportation, and from there someone contacted someone in the Federal Aviation Administration, which then finally contacted the Clark County Department of Aviation to fix the problem. By May 17th 2012 the guest access had been revoked, and the public folder partialy removed.
But even still the airline had a serious problem. No one on the staff actually followed the Internet security policy of the airport. In my interview with Halfpap, he states:
Their security policy states 8 characters alphanumeric with symbols, don't write it down, change default passwords, and don't share passwords. Well they broke each one of those. Didn't change default passwords, shared them, and wrote them down as the shared files showed and has such gems as as "lasvegas1", the number "1", and "blank" as in nothing it's a blank password. And one of those might or might not been the password for a smaller domain of the network.
Halfpap says this with an uneasy laugh of frustration. Other passwords that could be found via Google besides the baggage system included email test admin passwords and passwords for McCarran's Stoneware account, a location deployment environment. Halfpap says they didn't give him the keys to the kingdom. But with this much information he could have easily spear fished or socially engineered his way in. He had the full employee directory with their titles, phone numbers, and offices. Everything that would ever be needed with his technical knowledge of the platform deployments to get in.
The root cause of this major security hole at McCarran was because the team that deployed the system forgot to turn the guest account off, and worse, a policy of keeping secure documents in a public folder was set.
Halfpap says if he had been in charge of this network and in charge of the deployment, he should have been fired. Today, Halfpap discussed his finding at this year's Defcon in a talk called "Grepping The Gropers: Airport Security".
At press time, BetaNews had not received response to several requests for comment, including the Clark County aviation administrator responsible for maintaining the airport's network.
Photo Credit: photobank.ch/Shutterstock
In May 2010, Google hit the headlines when it was revealed that street mapping cars had accidentally collected around 600GB of payload data from unsecured wireless networks around the globe.