OWASP AppSec Conference Videos Posted
Jason Dean at 12Robots.com points out that the OWASP AppSec conference videos are available on blip.tv.
A number of these looks interesting to me, and the OWASP folks are sharp - these should be worth watching.
Jason Dean at 12Robots.com points out that the OWASP AppSec conference videos are available on blip.tv.
A number of these looks interesting to me, and the OWASP folks are sharp - these should be worth watching.
Posted by
David
at
5:30 PM
0
comments
A recent firewall issue reminded me of a co-worker's observation: look for round numbers.
Most firewalls - and many network devices - have a maximum session count. In our case, we had a maximum number of IP filter sessions which hadn't been hit during years of service. When reports of connection issues started to crop up, we went through our normal troubleshooting process - starting at the endpoints then tracking the traffic inwards.
In the end, a co-worker noticed that our IP filter use was at exactly 1500 - a suspiciously round number, and unsurprisingly enough the exact number set in the configuration for the device.
A simple fix later, we were able to restore connections and start troubleshooting what had opened so many new connections.
The moral of the story: use logging, and check for round numbers in your dashboards!
Posted by
David
at
9:17 PM
0
comments
Labels: firewall troubleshooting
The Society of Payment Security Professionals forum is a great resource for PCI compliance discussions. Sadly for user goodcvv_vn, it is not a good place to sell CVV2 codes.
The price list is, however, a great resource for my security talks - and of course, the offer to share free socks is compelling, as seen in the forum post, quoted here:
Sell cvv2 good& cheap....!!! and share free socksThe use of LibertyReserve, a Costa Rica based payment processor is also worth noting for those investigating payment card fraud.
Hello, I'm a new seller, Im from vietnam, I have any friend hacker
my cvv are the best for you
Ccv US is $ 1.5 per ccv (Visa)
Ccv US is $ 2 per ccv (master)
Ccv US is $ 3 per ccv (Amex + Discover)
Ccv UK is $ 4 per ccv (Visa + Master)
Ccv UK is $ 5 per ccv (Amex + swith)
Ccv Ca is $ 6 per ccv (Visa+ Master)
Ccv Ca is $ 9 per ccv (Visa Business + Visa Gold)
Ccv EU is $ 6 per ccv (Visa + Master)
Ccv EU is $ 7 per ccv (Amex + Discover)
Ccv Au is $ 6 per ccv
I can check balance in cvv,balance will be as you like and price agreements
if u buy over 50, I will sell for you good cheap, good price
I only accept payment with LibertyReserve
i will discount my price for u if u are reseller buy everyday or u buy many
all my cvv will be tested before sell, that's sure.
Please contact me: email redacted
on yahoomesenger: IM redacted
Posted by
David
at
12:30 PM
0
comments
Labels: payment card fraud, PCI, PCI-DSS
Kevin (happywaffle) tells the story of losing, then recovering his iPhone using the Find My iPhone feature. While his story might be dangerous under certain circumstances, his story is interesting. It is likely only a matter of time until someone is hurt while trying to recover a stolen or lost phone, but this story offers an interesting perspective on recovering a location aware, remotely accessible device.
Posted by
David
at
5:30 PM
0
comments
Labels: Find My iPhone, IPhone
Jason Lam's recent ISC diary post about WOT reminded me that we haven't reviewed browser security plugins for site recommendations recently. There are at least twoo browser plugins that can be useful for less savvy users when browsing the Internet, including:
Posted by
David
at
8:52 PM
0
comments
Labels: browser plugins, browser security, security plugins
Wireshark 1.2 is out, and if you're a Wireshark user, two of the features make this a worthwhile upgrade. First, a big bonus for casual and occasion users - display filters now autocomplete, meaning that searching for the proper syntax won't be quite as painful. Second, support for IP packet comparison was added, making one of the things I do often easier - comparison of packets to determine where a break point is.
As a reminder, you can also run Wireshark as a portable app on a PortableApps enabled device. That makes Wireshark an easy tool to provide to your system administrators and security staff. Note that if WinPCap isn't installed, this portable version will install it as needed, then uninstall it when complete - this isn't an entirely zero footprint portable app.
Posted by
David
at
8:38 PM
0
comments
Labels: winpcap, wireshark, wireshark portable
Joseph Bonneau's article "How Privacy Fails: The Facebook Privacy Debacle" points to deeper application data sharing concerns with Facebook's enforcement. His digging showed session parameters being passed to 3rd parties, in violation of Facebook's rules. More details on this issue can be found here.
These issues will make a great addition to awareness materials I'm preparing - while AllFacebook's 10 Privacy Settings are becoming more widely known, the risks of providing data to the whole host of quizzes, tests, and throwaway apps that populate Facebook are still largely unexplored by most users.
Posted by
David
at
9:11 PM
0
comments
Labels: Facebook, Facebook Application Security, Facebook Security
Many of us use Gmail for daily personal use. Some use it in their enterprise. What's missing? S/MIME support.
Fortunately, Google allows you to suggest desired functionality. Please join me in suggesting S/MIME support be added to Gmail.
Security bloggers and others, I invite you do make the same call to your audience. S/MIME support would offer a host of benefits, from greater functionality for Google's enterprise and higher education Gmail platforms to better trust models amongst Gmail users.
Posted by
David
at
5:30 PM
0
comments
Labels: Gmail S/MIME campaign
Wired has a great article about the rise and fall of E-Gold, including details on how carders and others used the service to transfer funds. Well worth a read.
Posted by
David
at
10:06 PM
0
comments
Labels: E-gold
Bruce Schneier recently wrote a blurb on the discussion of corrupted files for homework submission that has been making the rounds. Fortunately for professors and instructors, there are a number of ways to deal with corrupt files:
Posted by
David
at
5:30 PM
0
comments
Labels: corrupt files, electronic submission, homework
Posted by
David
at
6:00 PM
0
comments
Labels: ColdFusion security, cookies, xss
Wired's Threat Level writer Kim Zetter reports that Savvis is being sued as part of the 2005 CardSystems breach. Zetter notes that this is a legal first, making this an intriguing case to follow. Savvis' role as a Cardholder Information Security Program (CISP) auditor. This predecessor to our broadly adopted and audited PCI-DSS standards was expected to help ensure that a compliant entity was secure.
Additional coverage can be found on various security sites around the net, such as SC Magazine, which observes that the breach occurred almost a full year after the certification - enough time for a multitude of compliance issues to creep into any environment if not carefully maintained and re-assessed.
Zetter also notes that credit card companies are aware that even those companies that have clean audit results are often vulnerable. This creates an interesting scenario - companies are required to meet PCI standards, and pay for certified auditors to assess their systems. Should they then be indemnified against compromises? Where does responsibility for incorrect audits and assessments lie?
Unfortunately, it is rare for organizations to completely meet all of the standard, and exceptions and local accomodations are common - and even when an organization meets all of the standards, they do they can be vulnerable. The PCI-DSS standards are a step forward for credit card processor security, but this lawsuit is likely only the first in a series of lessons the entire industry will learn about auditing and standards compliance.
Posted by
David
at
12:30 PM
0
comments
Labels: audits and compliance, PCI, PCI-DSS
The (ISC)² hiring and employment outlook survey results recently announced on the (ISC)² website point to security as a continued area of growth, despite the economic downturn. Their survey was answered by over 2800 respondents, with 775 with hiring responsibilities. Interestingly, almost half of those were hiring at least one staffer. The survey also notes that many organizations had experienced lay-offs and/or budget decreases.
The responses regarding hiring also met my own recent experiences - finding qualified candidates with strong technical and interpersonal skills is difficult. The skillset required to be an analyst in a large organization with a diverse IT environment can be difficult to find, and competition for those highly qualified candidates remains stiff. Many candidates have specialized knowledge in a single area, but have little qualification across other crucial fields. Others have many paper certifications, but don't handle practical questions well. In short, the downturn seems to be shaking those with lower qualifications loose, and those with stronger backgrounds are still able to pick and choose their jobs.
The good news is that if you are a highly qualified security professional, you remain a valuable asset, and may have more opportunities then in other fields. The bad news is that the weak employment market may not greatly help you if you are a hiring manager - or you your resources may be so constrained that hiring a top flight candidate is impossible.
Posted by
David
at
8:39 PM
0
comments
Labels: (ISC)², Infosec jobs
A recent application issue pointed out what happens when a developer doesn't implement a normal TCP/IP port usage model.
In this case, the application doesn't appear to do what a normal application should: pick an ephemeral TCP port over 1024, then use that as the source port. Instead, the application binds to a specific source and destination port.
This might not be as much of an issue if the application didn't also suffer from a bad habit of not using keepalives for very long TCP sessions, necessitating a firewall rule that allows extremely long TCP sessions - over 18 hours to allow daily jobs to run.
When combined, this means that any TCP session that isn't properly closed will fail to re-start on a stateful firewall - and the application then breaks. The solution? Non-stateful firewall rules allowing host A to talk to host B, sourced from port X to port Y. You lose state tracking, protocol awareness, and any sort of application awareness, but you do get a working firewall rule even if bad things happen.
In the long term, we'll be asking the vendor about their take on how TCP/IP communications should be implemented...
Posted by
David
at
5:30 PM
0
comments
Labels: badly behaved software, ephemeral ports, stateful firwalll troubleshooting