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?

Dial an Identity Thief: a story from the front lines

A co-worker was kind enough to share his story of attempted identity theft today:

I received a interesting phone call on my office phone this morning.

The caller claimed to be with the 'recovery department' of a company in New York. The caller spoke English very poorly and the connection was noisy, so I never did figure out the name of the company he supposedly represented.

The caller claimed to be calling about $650 that was supposedly withdrawn from my account (not sure what kind of account, or where) several years ago, apparently without my permission. He wanted to confirm some information, so he could return the money to me. He was difficult to understand, but I am fairly certain that he said he needed my credit card number.

We went around and around for several minutes, as I tried to figure out who he supposedly represented and how much information he already had. I finally told him that if he knew how to reach me by phone, he should also know how to reach me by mail, and he should simply send me a check.

Callerid on my phone reported that the call originated from 1234567890. That number is completely bogus. The caller was probably using an internet phone; it is relatively easy to fake callerid with an internet phone.

My thanks to the co-worker for giving permission to post his story. The moral of the story here is to always ask questions, to not give up information without verification, and to always know the identity of your callers. How would you respond to a call like this? What would you do if the callerID had matched a local bank instead of a number you didn't recognize?

I normally advise people to call the company back - ask for a number that you can verify in their website and call that number. If they can't provide that information, ask them to send you more information using your contact information on file. And, as always, the FTC identity theft website is a great resources. While you're at it, you may also want to check out the Privacy Rights Clearinghouse.

So you want an IT job?

Readers here know that Richard Bejtlich's Taosecurity is a favorite read for me. On Tuesday, he posted "What Hackers Learn that the Rest of Us Don't", and included a bit of commentary about his views for hiring IT staff.

I've had the pleasure of working with IT staff from a variety of backgrounds, from the computer lab IT guy who was a fine arts major, to the gifted Windows admin with a marketing background. They have taught me that a CS degree or an MIS degree frequently isn't the best indicator of suitability to the job. One infamous quote from a CS major undergrad that I knew was "I don't care how the computer works, I just program for it!". That's the same as "I don't care about edge cases, it works most of the time!", or other quotes that scare security folks every time we hear them.

As Bejtlich points out, native curiosity and interest - paying attention to the edge cases and the little details are some of the things that can make a hacker successful. The same goes for hiring an IT professional. During the past few years, I've developed a short list of things that I look for when hiring:

• Curiosity - if I mention a new technology, technique, or other area of interest, does the candidate ask questions, and do they absorb knowledge?
• Passion - not everybody can go home and play with things for the entire night, but do they actively enjoy doing what they do? Do they want to do it? I tend to ask candidates what their home network looks like, and how they're securing it. I ask what they'd like to play with, and what opportunities they've had and what they've enjoyed.
  
• Laziness - not the bad kind, but the right kind. I look for someone who does it right once, rather than badly over and over again.
• Active learning - are they expanding their knowledge, either formally via courses and training, or informally by tinkering?
  
• Active pursuit of knowledge. Far too many candidates come in who read a security magazine once a month to stay in touch. That's not a useful way of staying up to date in the modern security world. Ask your candidate what they read to stay up to date, and what mailing lists they're subscribed to. I look for depth and breadth of knowledge seeking.
  
• Personality - can they make and take a joke? Can they deal with users? How do they come across?

So, what do you look for in an IT candidate? And how does a security professional differ?

Your password must be at least 18770 characters long

Courtesy of Digg, the next time your users complain about your egregious security policies, point out this handy Microsoft KB article regarding Windows 2000 authentication against an MIT Kerberos domain.

The specific message returned is:

"Your password must be at least 18770 characters and cannot repeat any of your previous 30689 passwords. Please type a different password. Type a password that meets these requirements in both text boxes."

Who says that 30 day password changes longer than 8 characters are so bad? This is almost as much fun as Compaq's "Where do I find the any key" article.