Ohio InfoSec Forum 2014

Somehow through twitter last year I found out there’s an active infosec group My home town, Dayton. Every year they have an anniversary con, one room, one track, and great speakers. Last year my favorite talk was about the Kali Linux project by Martin Bos. I hadn’t seen anyone discussing much other than the official website, so it was great to hear more details about the transition from Backtrack to Kali and the goals of the project.

Following the group in the last year, I found that this year’s anniversary fell on a weekend I was planning to head to Dayton with my family anyhow. Between a flexible wife and parents and a job that’s happy to let me set my own schedule, I got a Friday off for family time and a great Saturday of learning and networking.┬áThis years lineup had some familiar faces and some new ones, at least to me.

Dave Kennedy of TrustedSec opened with a great talk about awareness initiatives, things he’d seen succeed, things he had proven were failures, and ideas to move forward. Like all of his previous talks I’ve seen, Dave showed off his Java Applet attack in SET, which was honestly distracting to the greater message. Security program awareness and success is directly tied to discussions and interactions with the users, not the technical controls put in place. Dave explained how in one of his past positions he started outreach programs from the security and technical staff to the rest of the users. They explained media stories, answered questions, fixed personal laptops, basically taking any opportunity to help people understand what risks exist and how to make an intelligent decision about them.

Jerod Brennan is security consultant at Jacadis and deals with assessing customer’s environments, websites, and applications for security flaws. In this role he’s been analyzing mobile applications, both iOS and Android and found some alarming security flaws. He opened explaining that during penetration tests, mobile applications had not often been in scope, but as they started to grow in popularity, they’ve become a great target to help identify security problems in an organization. The problems identified in the past ranged from information disclosure to third parties having access to customer data.

Between stories of security problems he’s seen in the wild, Jerod discussed how to retrieve the application bundle and analyze the app itself. Both iOS and Android deploy apps in a zipped container, and inside that container are text files that can be scanned for some common words or phrases to begin to understand that the app is doing. Looking for things like “http://” or “password” often yield valuable information. Other dangerous security problems he has seen in the wild were things like including .dlls in an iOS app bundle. These were easily reversed to get the raw source code that provided valuable information. Problems like this often arise from using a cross platform development environment, lowest bidder contractors, or just laziness about security.

The most damning problem that Jerod had seen in the wild was where a client’s app had been developed by an outsourced developer. This developer had written a part of the application to contact his personal environment, in addition to the client’s, when it was connecting. Jerod didn’t disclose what information was being sent or retrieved, but he emphasized the security concern at play. If a malicious entity wanted to compromise the client’s app, they no longer have to deal directly with the client’s environment. This loophole in their mobile app has the potential to allow attackers to compromise the developer’s environment, and pivot from their into the client’s system.

The takeaway message was the same as many security talks, validate your assumptions, and verify your security. Even if you have a mobile app developed wholly in-house, it must be built with security in mind. Discussing, developing and testing security is the only way to be sure that you’re defending your organization and your customers, and the related data.

For a conference that only cost a $10 donation, breakfast and lunch were provided, which put everyone in the same room with no real goal, to allow for conversation. I met a couple gentlemen from a local managed services company who had never attended a security group before, they were getting great value of things they could bring back to build their business. At the same time I spent a few minutes talking to the organizers, who all worked from different companies ranging from Jacadis, to Rapid7, to an unnamed Department of Defense contractor(Dayton is in close proximity to Wright Patterson Air Force Base, which employs a large number of civilian contractors).

Deral Heiland is by day a penetration tester for Rapid7, and by night a guy that “googles how to code”. The combination of these two things is his application Praeda. Named for the Latin word for spoils or booty, Praeda is an application that will scan a network segment or IP for a device in its list. If it finds a matching device it will attempt to login with the vendor’s default credentials and extract/read/download any sensitive information.

Traditionally during network penetration tests, this sort of thing had been a last minute maneuver, just to show a few more basic vulnerabilities at the end of a test. When Deral first got his application working, he ran it and harvested enough information to get into much of the infrastructure that did not have default credentials, but did have sensitive information shared to less significant devices. What does this mean? That things like IP cameras, multi-function printers, or similar can hold and repeat a serious amount of potentially dangerous information. The result of this little demonstration was that now this is one of the first applications that Deral and his team run when they’re in a new environment.

Around this point, someone in the audience asked about how he discovered the exploits used in this tool. Deral gave half of a laugh and explained that there is no real exploit here. His tool is using intended functionality; that of a restricted portal or settings page. The problem is that it has published defaults that were never changed. Deral’s point, and one of the most damning problem with device or software security, is that of shipping with default credentials. In this particular case, Deral’s tool has found devices using default credentials that somehow have significant information about the company that owns them.

The talks ended with a great discussion of passwords by Tom Webster. His talk didn’t present anything particularly new, but reinforced a lot of debate that has been occurring lately, which are more secure, complex passwords, or long, simple passphrases? Security as a thing has generally encouraged complexity, but this fails the user in that it is very difficult for the human to remember, and technically easier for software to break.

At the end of the day(after the cake) I looked around and was shocked that the room was not full. Here was a day of great content, great discussion, and great networking for nearly free. I felt like this event was a great example of the giving nature of the InfoSec community, one that continues to surprise me every day. The organizers KNOW there are smart people around, they know these people have stories to tell that will help us all get better. So they’re doing what they can to make that accessible. Being on a Saturday means that people didn’t have to take off work. Being $10 means pretty much anyone can afford it. Being open to the public means anyone can come in. It’s pretty awesome to walk into a room of complete strangers on the other side of the state, and get welcomed like a regular. I hope I get another chance to attend or speak at an Ohio InfoSec Forum event.