Who is Abe Torkelton? - finding a webform bot

A recent web form hit made me curious, and a little bit of digging showed interesting behavior. Here's a bit about the observable anatomy of a form crawler bot going by the alias of "Abe Torkelton".

The bot has been tracked before, and apparently may show up as "Jorge Gonzales" leaving a phone number of 617-750-5939.

Hundreds of websites show in Google with hits from a registered user with a user string in the form:

Abe ???Torkelton????@cape-mail.com

The first three wildcards are letters, the last four are numbers - apparently part of a unique ID for the testing bot. Many more of these registrations can be seen by simply googling for either "Abe Torkelton"or "cape-mail.com".

The domain itself is registered through a domain proxy service run by gkg.net. This effectively hides the identity of the person running the bot.

What is the data being used for? I don't know yet - but somebody is finding every web form that they can submit user data to across the Internet, and they're seeing how those websites respond. Check your logs folks - this one is interesting to see.

UPDATE:

Thanks to comments on this post, I've posted an update.

SSN: when a unique ID isn't.

As regular readers know, I work in higher education. I switched employers earlier this year, and recently discovered that the switch led to some interesting issues with insurance. The description below is the best fit to what appears to have happened, however it is written with no inside technical confirmation.

The sequence appears to be:

1. End employment at former employer A, with insurance provided by insurance company X.
   
2. Start employment with new employer B, employer B also uses insurance company X.
   
3. Employer B insurance starts, and is identified by SSN to company X.
   
4. Employer A carries my insurance through for a few weeks, then sends notice to the same insurer to terminate insurance for my SSN.

This led to my insurance being invalid, despite my current employer - B, believing that it was active. It also points to some interesting flaws behind the scenes.

• A trusted entity can end insurance for a given SSN.
• A trusted entity can declare themselves authoritative or is by default authoritative for a given SSN.
  
• Crossovers are not flagged for activity - if employer A makes a change, then employer B makes a change, then A makes a change, this is not caught and investigated.
  
• There is no regular feed that updates this information.
• SSNs are used as unique IDs for the insurance - and even if you select a non-SSN ID (which the insurer offers) they appear to still be the primary key for your account.

Reconaissance: LinkedIn and social engineering

I attended Ed Skoudis's SANS 504 track in Las Vegas last week, and picked up a lot of useful tidbits. One of the more interesting offhand comments Ed made was about using LinkedIn to assess what vendors a given organization is buying from based on their recent link adds.

It makes for a fun exercise, and could potentially be useful when doing recon of an organization for penetration testing. A quick look at my own contacts lends some credence to the idea, and given a bit of other research, a LinkedIn survey seems like a clever method to get a few extra bits of information.

Does this mean that using professional social networking should be banned? Probably not, but it is a great reminder of the level of detail an intelligent aggressor can gather given a bit of cleverness and time.

CSRF handling and SunGard Banner

Paul Asadoorian from OSHEAN published a whitepaper on CSRF vulnerabilities in SunGard Banner - an ERP system common used in higher education. The whitepaper is a useful read for developers who work with Banner, but would also be useful background material for any programmer who works with authenticated web sessions. Very few applications that I've seen account for CSRF, and getting the techniques described in the paper implemented as part of your standard framework could save you a lot of pain in the future.

Emergency notification systems - SMS for emergencies

The College of Notre Dame (note, that's not the University of Notre Dame) used their e2Campus SMS based emergency alert system recently. e2Campus provides bulk SMS messaging (and other features) for emergencies - a similar system is the NTI group's Connect-ED messaging service. These services provide emergency contact via SMS, email, and phone messages - and may provide additional options. This goes beyond what many of us were used to with campus tornado sirens having special tones for other emergencies - these services can provide news briefs in a timely manner to large groups.

Many colleges are starting to adopt these services as a useful way of contacting their cell-phone carrying student base. It is interesting to note that a percentage of students did not receive the message - while the article says that this percentage is low, it does point out that SMS messaging is not a total coverage solution and should be only a part of a comprehensive emergency communication system. With that said, notifying your constituents with enough detail to do something useful is an amazing tool to have in an emergency.

Would a system like this be useful to you? Quite possibly, depending on your user demographics and what your communication needs are.

A few caveats and comments up front:

1. A test should be done to ensure that information is properly entered - in the case of a University, this would probably need to be done each semester.
   
2. Rules need to be in place to control the use of the system - like any communication system, if the SMS capability is co-opted for non-emergency use it will be more easily ignored. The backlash from spam from the emergency system would likely be massive.
   
3. Users must be made aware that the system will not be a 100% solution - cell phones may not always receive SMS messages. Use your alternate information sources as well.
   
4. Spoofing may be possible via a VOIP or other system - having a known sender is still useful, but not a guarantee of validity.
5. Control expectations, and let your users know how and why you will contact them.
   

SSL testing: Foundstone's SSLDigger

If you're required to be PCI-DSS compliant, or you just want to check the SSL settings for your site, Foundstone provides a great free tool: SSLDigger. It checks certificate details, encryption and cipher settings, and is generally a good way to double check your SSL setup. Note that it does require the .NET package to be installed first.

Email bomb threats

The Indiana Daily Student is carrying an article about an email bomb threat to Indiana University's Bryan Hall. The University of Iowa received a similar threat and noted that other universities are receiving these threats as well. With widespread email bomb threats spreading, it is useful to note that the email was sent with specific details - to a dean and threatening Bryan Hall in the case of IU, and threatening the library at UI. In addition, the article notes that the email was sent through an anonymous service. This is the modern day equivalent of phoning in your bomb threat from a payphone.

I've seen old style phone-in bomb threats can shut down classes and campus buildings for hours at a time. With the heightened security response from many schools in a post VA Tech mode, emailed bomb threats have a significant chance of disrupting school activities. As the school year starts, it will be interesting to see if this is just the beginning of a trend. Hopefully this won't become widespread - targeted availability attacks like this can wreak havoc on campus schedules and events.

Now is the time to review your emergency communications plan - can you communicate effectively to your staff, students, and other community members? Do you have evacuation plans for buildings?