I have to say that the speaker quality varied quite a bit. It ranged from “can I please die now” to “this guy is awesome”, and the level of knowledge transfer was about the same. I tended towards the technical talks when there were any, and whatever caught my interest otherwise.

The talks by Joe McCray from learnsecurityonline.com were excellent, if a bit fast paced. I managed to get the gist of the talks, but I wish some of the slides were up longer to copy commands down, but oh well. I learned a few things about SQL injection that I didn’t know – like playing 20 questions with the server to infer it’s information.

I also went to the iPhone forensics talk by Sean Morrissey, and was suitably impressed with what can be gotten off the phone without jailbreaking it – including the fact that you can send a phone to Apple and they will break the passcode protection (with a warrant). Now, that makes me think that if Apple can do it, someone else can too. It’s not like my passcode is escrowed at Apple (I hope).

The last really good talk I went to was on volatile evidence gathering in Linux – ie, gathering evidence on a still running system from memory and other changeable state information (running processes, network connections, etc). It was interesting, but nothing new for me.

Finally, I went to a few non-technical talks on “Cyber warfare”, which were basically rehashes of Sun Tzu and old military strategy, and nothing to do with how to fight it, just how it’s different. I certainly was not the target audience for these.

What I found amusing was that at Defcon you have “spot the fed” contests, at this conference, it was more like “spot the non-fed”. Almost every attendee works for the feds or a police department in a forensics capability. I was asked at one point why I wasn’t in forensics, and my answer was corporate culture problems – which I think is a general problem, not just for me. Most very technical people I know prefer to not work in the type of corporate culture that exists in the federal government and government contractors – strict dress code, no “toys” to play with, having to use a company issued (and controlled) laptop, etc.. It’s just not the type of environment that the bright minds of today (and tomorrow) want to be in, and until these organizations figure that out – and actually change something – they’re not going to attract the talent that they want.

But as you begin the process of migrating from Vista or XP to Win7, let’s not forget some of the important things that come with any major upgrade in OS. I’ve mentioned before some of the new security enhancements Win7 is bringing to the table. These are great features that are already given to you out of the box.

Things to do when you migrate:

• If your doing a fresh install (required if coming from XP) – or you just want a nice clean start (which is always recommended anyways) – make sure to select the “grab updates during the install process”. This will ensure that even on first startup you already have a decent amount of security updates already applied.


• But that doesn’t take care of all of it. The first thing you should do upon first startup is go to Windows Update and grab all the critical windows and software updates.


• Make sure you reinstall / update your anti-virus software. Make sure it is also compatible with Win7 before you begin the upgrade process so that you can ensure you have something to install.


• Check that any 3rd party software you plan on re-installing is also compatible with Win7. This is also a great time to update these 3rd party applications to ensure they are all properly up-to-date.


• If you had any non-standard permissions or security settings – don’t forget your going to have to re-apply these settings as everything will be returned to default.

Email forgery is made possible due to the way email servers accept mail from email client programs and from each other. The whole process is not much different from the way regular snail mail is delivered. When you mail a letter, you write the name and address of the recipient and (usually) your own name and address so they know where to send any replies to. But this is just what’s supposed to happen. In reality, you could write anyone’s name and address as either the sender or the recipient and the mailman wouldn’t really care—his job is just to deliver the letter to whatever recipient address is listed, not to verify that you are who you say you are.

The same is true with email client applications like Outlook, Thunderbird, Hotmail, and Gmail. We can think of them as letter writers, only they always write what they believe to be the correct sender email address on the front of the letter. Email forgery takes advantage of the fact that you can list any email as the sender address. It might help to walk through a simplified instance of an email being sent.

DudeBro: Sup dude.
Mailman: Hi
DudeBro: My name is DudeBro. I live in BigCity
Mailman: Ummm… okaaay … O.o
DudeBro: I want to send a letter to NiceGirl who lives in SmallTown
Mailman: Alright.
DudeBro: I want the letter to say “sup”
Mailman: That’s it? Just “sup?”
DudeBro: ... No. No, make it also say “whats ur twitter?”
Mailman: * facepalm *
DudeBro: That should do it. Thanks dude.
Mailman: No problem.

So you can see, Mailman just sends it where DudeBro asks him to send it—and he doesn’t even care if DudeBro is really DudeBro. This is exactly how an email client (Outlook, Thunderbird, etc) gets your mail sent via SMTP. The following text parallels what happened above, only it represents the actual data communicated between the Mailman (as the email server), and DudeBro (as the email client).

helo bigcity.com
mail.man.net hello [192.168.0.33], pleased to meet you
mail from: dudebro@bigcity.com
250 2.1.0 sender ok
rcpt to: nicegirl@smalltown.com
250 2.1.5 recipient ok
data
354 enter mail, end with ”.” on a line by itself
sup
whats ur twitter
.
250 2.0.0 vGdK1c00F4DYCPY02GdXT5 mail accepted for delivery

So to forge the email, we just change the relevant part in the communication so it has a different “mail from:” entry. Since you essentially control the client side, its fairly straightforward. The recipient wont know if it came from who it claims it came from or not. Spammers and phishers often use this technique to do their dirty work. It is trivial to make an email appear to come from your best friend, or your roommate, or even your mom.

But if it is so easy, there has to be a way to prevent it, right? Sure, there are plenty of ways to verify that a message came from who it claims to come from (authentication). One such method is digital signatures which make use of asymmetric cryptography. If you’re interested in learning about the benefits of digital signatures, we offer training.

Each Tuesday, Security Musings features a topic to help educate our readers about security. For more information about Gemini Security Solutions’ security education capabilities, contact us!

The competition is based loosely on the setup of National Collegiate Cyber Defense Competition events. Each team is scored on their ability to correct problems on their network of machines, perform IT-related business tasks, keep critical systems operating, and defend their networks from the attackers. In the JMU competition, the defenders are allowed to work to secure their systems for one hour before the attackers are permitted to perform attacks. This is opposite what typically occurs in the national competitions – the attackers get to probe and attack the systems before the defenders are called in.

Last year we chronicled how the event transpired. This year, there were some differences in what worked, and what didn’t.

• Default Passwords: This was far less successful an attack than the year prior. Most every team had changed every externally-accessible password from its default. What was a cakewalk last year was quickly frustrating (for the attackers) this year.


• Running Older (vulnerable) Software/Processes: This was also less common. The only time these attacks were successful were when systems had to be rebuilt because they were damaged beyond the team’s ability to repair them, the teams forgot to re-patch the servers.


• Installing Unknown Software: The teams were once again given a business task to install software on a server, but the digital signature on the email was invalid. Only two teams installed this software, and both quickly noticed it was not what was expected and removed or patched it.


• Physical Access: A physical attack we performed – erasing the drives on all firewall machines by inserting a DBAN disc – turned out to be the difference in the competition. One team thwarted this attack by disabling the keyboard on their firewall. We only had 5 minutes of uninterrupted access to their systems and failed to get the drive erased on one team’s system. Being the only team standing while the others had to rebuild their firewalls completely allowed them to score enough points to win the competition.


• Web Application Security: The E-Commerce Site/Engine that was installed by default on the team servers was not well understood by the defenders. The attackers used knowledge of the system and its back-end firewall to install back doors and disable the site. Most teams either never got the web application running, or had it disabled for the entire competition.


• Not finding the real problem: This was less of a problem this time. The teams were effective at rooting out the causes of attacks and defending against them.

All in all, I believe everyone had an enjoyable and educational time. We look forward to the next competition!

Vulnerabilities are found in several places – the first place you’re likely to find public disclosure of a vulnerability is the Full Disclosure mailing list. On the downside, it’s a very high noise to content ratio (i.e. there’s a lot of noise – probably 90-95% noise). The second place it’s likely to show up, and be more useful to you is in the bugtraq mailing list – this is because bugtraq is moderated. It has a much lower noise to content ratio (90-95% of it will be useful). If you want to be on the cutting edge of vulnerability research, these are the two go-to lists.

milw0rm.org (which has questionable uptime at the moment) has a great database of exploits. If there’s an exploit in the wild, milw0rm will likely have a copy of it. And vice versa, if milw0rm has exploit code for it, you’re likely to see people attempting it.

All of these sites are for all vulnerabilities, including many that may not affect you, and if you’re short on time, you want to know what vulnerabilities affect you – and if there’s a patch. Vendor specific mailing lists (or web pages) are your friends here. Sometimes, you have to be a support paying customer to have access to these lists, but the ones I list here are free for everyone to join.

-Windows has several options depending on what you want to get from them.

-Apple has their security-announce list available through mailing list or RSS feed.

-FreeBSD has a whole group dedicated to vulnerabilities, with links to a list of the vulnerabilities in FreeBSD as well as the ports tree.

-Sun has a knowledgebase article that lists all current vulnerabilities and advisories.

-Linux vulnerabilities are generally listed through the distribution you choose to install.

• Red Hat has several public lists for vulnerability announcements depending on the product you’re interested in.
• Debian – debian-security-announce mailing list
• Ubuntu – ubuntu-security-announce mailing list

• SuSE has a web page devoted to advisories.

  Whatever operating system you run or administer, find out where the advisories are posted and monitor them for activity. Everything is going to have vulnerabilities sooner or later; you’re not “safe” just because you run an obscure operating system or application. Keep up-to-date and you’ll reduce the surface area for attacks.

  
  ]]> http://securitymusings.com/article/1481/keeping-up-to-date-as-an-administrator/feed 0 http://securitymusings.com/article/1481/keeping-up-to-date-as-an-administrator http://feedproxy.google.com/~r/SecurityMusings/~3/RF0wK1aZjPg/simplecapi-and-the-case-of-the-disappearing-keyset http://securitymusings.com/article/1477/simplecapi-and-the-case-of-the-disappearing-keyset#comments Fri, 09 Oct 2009 16:43:27 +0000 Walt Turnes http://securitymusings.com/?p=1477 After recently upgrading to Windows 7, I installed our company’s SimpleCAPI tool to import some test certificates for a project. While I was unit testing my new code, I discovered some strange things had occurred during the certificate import process. Some native CAPI code I had written was failing with a “KeySet does not exist” error, but only for certain certificates. So, I fired up SimpleCAPI again, deleted the certificates, and re-imported them. After doing that, the unit tests ran fine.

  Some time later, I ran into a similar problem unit testing another segment of code, and the same fix worked for that problem as well. After retracing my steps a bit and trying to re-create the error, I found that the keysets could only not be loaded when I had launched SimpleCAPI as an Administrator in Windows 7 to install the certificates, and my unit test project was not run under an Administrator context. However, when the certificates were imported in a SimpleCAPI session that was not launched as an administrator, then the keys were available regardless of the unit test context.

  This probably isn’t going to be a problem that’s widely experienced, as 999 times out of 1000 (1), certificates are imported using the standard Windows certificate wizard, not an external application like SimpleCAPI. However, I do need to figure out why this is happening. My guess is simply that the key container created during the certificate import is flagged with administrator access only, so attempting to acquire a handle to the key context in my native CAPI code was failing due to a read/write permissions error, not a problem with the KeySet’s existence.

  I also need to fix the CAPI code so that the key handle can be obtained with a read-only context. Hopefully that will get around the problem entirely. Regardless, I took this as a lesson that the “Run as Administrator” shortcut in Windows 7 can have more subtle implications than just granting some extra privileges for an application. This is something that I’ll need to keep in mind when developing Windows applications going forward.

  1: 84% of all statistics are made up on the spot.

  
  ]]> http://securitymusings.com/article/1477/simplecapi-and-the-case-of-the-disappearing-keyset/feed 0 http://securitymusings.com/article/1477/simplecapi-and-the-case-of-the-disappearing-keyset http://feedproxy.google.com/~r/SecurityMusings/~3/5UMU14q96zo/how-effective-is-the-pci-dss http://securitymusings.com/article/1474/how-effective-is-the-pci-dss#comments Fri, 25 Sep 2009 18:36:32 +0000 Nick Staples http://securitymusings.com/?p=1474 The PCI-DSS (Payment Card Industry Data Security Standard) is a set of requirements for businesses and merchants that deal with credit card information. These standards are designed to protect the customer by requiring businesses to protect sensitive cardholder data. Complying with the PCI-DSS requirements can result in changes to a business data infrastructure, including securing networks, implementing access controls, and creating a robust information security policy.

  However, despite the stringent requirements, there has still been doubt about the real-world effectiveness of the PCI-DSS. The idea that PCI-DSS doesn’t make consumer credit card data much safer has been discussed ad nauseum, and not without some compelling evidence. In 2008, 4.2 million credit card numbers were stolen from the PCI-DSS compliant grocery chain Hannaford Brothers.

  But isolated instances of failed PCI-DSS policies provide nothing more than anecdotal evidence of the perceived weakness of the standard. To truly examine its impact, a formal study should be done. On September 24, 2009, the Ponemon Institute released the results of such a study. This study (pdf) included survey data collected from people representing a number of different companies and businesses.

  Some of the important key findings:
  

  
  
  • Cost of PCI is, on average, 1/3 of the overall security budget
  
  
  • 79% have had a data breach
  
  
  • 55% of companies focus only on protecting the credit card data and not other sensitive information
  
  
  • There is uncertainty as to what personell are the most accountable for PCI-DSS compliance
  
  
  • Smaller companies are less compliant than larger companies (75k+ employees)
  
  

  From the study, one can deduce that the standards favor larger companies, who are usually better able to conform to the requirements, due in part to larger security budgets and more resources. It is also interesting that the majority of companies surveyed (55%) expressed interest in only protecting the card holder data. This means that other consumer data (such as social security numbers, addresses, etc) could be swinging in the wind with no protection at all. It almost seems as if companies want to adhere to the PCI-DSS just enough to be compliant.

  But if companies don’t have a serious vested interest in protecting their customers’ sensitive data (ALL of it), then maybe they’ve missed the point. The PCI-DSS certainly gets merchants thinking about security, but the lengths that they go to achieve this security shouldn’t stop with PCI-DSS compliance. Naturally, no set of standards is capable of covering all fronts—especially not in a landscape that changes as frequently as information security. But if companies don’t take the hint and think seriously about protecting data and securing their systems against threats, then compliance is nothing more than a glorified checklist representing an ineffective baseline for security practices.

  If we think of the PCI-DSS as a panacea for cardholder data breaches, then it is indisputably ineffective. However, if we think of it as a guideline and a foundation on top of which real security measures can be built, then it may prove to be quite valuable.

  
  ]]> http://securitymusings.com/article/1474/how-effective-is-the-pci-dss/feed 0 http://securitymusings.com/article/1474/how-effective-is-the-pci-dss http://feedproxy.google.com/~r/SecurityMusings/~3/Adwn3yxlFks/security-metrics-the-new-topic http://securitymusings.com/article/1463/security-metrics-the-new-topic#comments Wed, 16 Sep 2009 10:21:49 +0000 Laura Raderman http://securitymusings.com/?p=1463 NIST recently released an overview report on the current state of research in security metrics (short story: there are almost none), and some areas where they feel more research is warranted. One of the problems with security as a business process is that managers are being taught process improvements is the way to save money, but with security, there are no obvious metrics to measure to improve the process. Security is subjective, based on the person and the situation, and measurements tend to the objective side of things.

  I think that seeing new measurements is really going to improve the overall security landscape – once they’re accepted and used. NIST and the Feds already kind of lead the way with FIPS and Common Criteria (European based), and I think that if they start using a particular metric, the commercial world will follow. One of the detriments to security metrics is that until the last few years, it hasn’t been well studied in universities – the “hotbeds” of research. I think that now we may start to see more metrics coming out as more graduate students start to study it. And if you happen to be a current grad student interested in security metrics, the NIST paper has some great starting points for a thesis.

  
  ]]> http://securitymusings.com/article/1463/security-metrics-the-new-topic/feed 0 http://securitymusings.com/article/1463/security-metrics-the-new-topic http://feedproxy.google.com/~r/SecurityMusings/~3/qc1vdLGL7xI/hp-swfscan-tool-adobe-flash-application-security-scanner http://securitymusings.com/article/1450/hp-swfscan-tool-adobe-flash-application-security-scanner#comments Thu, 10 Sep 2009 21:16:21 +0000 Tim Donaworth http://securitymusings.com/?p=1450 One of the most expanded targets lately in vulnerability research is Adobe’s Flash. It has become a common everyday occurrence on the web; everything from banners, to games, to file uploads. It’s almost hard to find a mainstream site that doesn’t have some sort of flash application running somewhere within the domain. As a result it has become a target for many attacks. But one thing that hasn’t increased is the amount of time and checking that goes into the flash applications to ensure they are secure.

  HP has been kind enough to release SWFScan, a .swf scanning utility that can de-compile applications built in Flash to extract the ActionScript code and statically analyze it to identify security issues. Some of the key items it can report on are:
  

  
  
  • Information disclosure (CC numbers, Personal information, etc)
  
  
  • Improper security calls (Security.allowInsecureDomain(), LocalConnection.allowDomain(), Security.allowDomain(), etc)
  
  
  • Database connection string leakage.
  
  
  • Inclusion of private keys for encryption
  
  
  • Insecure flash storage object.
  
  
  • XSS through FlashVars
  
  
  • MD5 Hash detection.
  
  
  • Source code path disclosures.
  
  
  • And plenty more…
  
  
  
  

  
  What it really breaks down to is swf files are not protected. It is quite easy to decompile them so you have to be very careful as to what information you include, collect, or expose within the code. But if you’re curious as to the current state of your flash applications, or even those that you might happen to use on a daily basis, HP’s SWFScan can be used to help assist in the discovery phase.
  

  Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!

  
  ]]> http://securitymusings.com/article/1450/hp-swfscan-tool-adobe-flash-application-security-scanner/feed 0 http://securitymusings.com/article/1450/hp-swfscan-tool-adobe-flash-application-security-scanner http://feedproxy.google.com/~r/SecurityMusings/~3/UYB4dUM-1n0/sanitizing-input-in-web-apps-part-3 http://securitymusings.com/article/1439/sanitizing-input-in-web-apps-part-3#comments Thu, 10 Sep 2009 04:17:06 +0000 Nick Staples http://securitymusings.com/?p=1439 Last time in our web app input sanitation series, we looked at unsanitized input as part of an HTML tag or attribute. This entry focuses on sanitizing SQL queries.

  Case 3: Sanitizing SQL Query Data

  The basic SQL attack takes advantage of improper sanitation to execute its own queries against a database. This can lead to a database being compromised.

  Take this snippet, for example:

  ———————————————————————
  
  ———————————————————————

  The code takes in a variable “id” and queries the database to see if that ID exists in the system. If it does, it prints out some simple HTML. The problem is that the “id” parameter is not sanitized beforehand.

  A normal query would be something like:
  http://example.com/user.php?id=33

  Which would send the following to the database as a query:
  SELECT count(*) from members where id LIKE ‘33’;

  However, a malicious query might look different:
  http://example.com/user.php?id=33’ and password like ‘user_password

  Which would send the following to the database as a query:
  SELECT count(*) from members where id LIKE ‘33’ and password like ‘bunnyslippers’;

  This means an attacker could use the page to execute a query to find out sensitive information. In this case, if the user’s password is “bunnyslippers,” the page will display “ID found.” Depending on the way the original query is set up, there may be many things an attacker can do to take advantage of a SQL injection vulnerability.

  The basic step to sanitize query input is to encode single and double quotation marks so that the query data isn’t interpreted as special SQL commands, operators, or delimiters. Although writing a function to do this is possible, PHP has a built-in function to clean up SQL query data.

  Simply run all query variables through mysql_real_escape_string() and everything should be fine (with very few exceptions). In the above example, if the malicious input was filtered by the function, the SQL query that was executed would be:

  SELECT count(*) from members where id LIKE ‘33\’ and password like \’bunnyslippers’;

  Resulting in no unintentional leak of information since the quotation marks are escaped by the function.

  Security Musings features a topic to help educate our readers about security. For more information about Gemini Security Solutions’ security education capabilities, contact us!

  
  ]]> http://securitymusings.com/article/1439/sanitizing-input-in-web-apps-part-3/feed 0 http://securitymusings.com/article/1439/sanitizing-input-in-web-apps-part-3