Earlier this month, at the Secure360 conference in St. Paul, Seth Peter (NetSPI’s CTO) and I gave a presentation on enterprise vulnerability management. This talk came out of a number of discussions about formal vulnerability management programs that we have had both internally at NetSPI and with outside individuals and organizations. While many companies have large and relatively mature security programs, it would not be an exaggeration to say that very few have formalized the process of actively managing the vulnerabilities in their environments. To accompany our presentation, I created a short white paper addressing the subject. In it, I briefly address the need for such a formal program, summarize a four phase approach, and offer some tips and suggestions on making vulnerability management work in your organization. When reading it, keep in mind that the approach that I outline is by no means the only way of successfully taking on the challenge of managing your security weaknesses. However, due to our unique vantage point as both technical testers and trusted program advisors for many organizations across various industries, we have been able to pull together an approach that incorporates the key elements that will allow this sort of program to be successful. Download Ryan’s white paper: An Approach to Enterprise Vulnerability Management
For those that aren’t keeping track, June 30, 2012 is a day to mark on your calendar. Not because of any special anniversaries or birthdays (although if yours does fall on that day then Congratulations!). June 30 is the day that we can add one more validation point to our compliance lists from the PCI Data Security Standard. The testing procedure for requirement 6.2 will transition the risk ranking assignment to new vulnerabilities from optional to mandatory. And yes, this does impact those filling out a Self-Assessment Questionnaire (SAQ) as well, but only the SAQ D. Specifically the requirement’s reporting detail reads: If risk ranking is assigned to new vulnerabilities, briefly describe the observed process for assigning a risk ranking, including how critical, highest risk vulnerabilities are ranked as “High”*(Note: the ranking of vulnerabilities is considered a best practice until June 30, 2012, after which it becomes a requirement.) * The reporting detail for “Observe process, action state” is not required until June 30, 2012 Personally, I think this is a good idea as it actually gets you thinking about the impacts of the vulnerabilities specific to your organization. It also allows you to downgrade the vendor supplied criticality should you have existing controls in place to lessen the vulnerability realization. A common example is having to apply a patch to a web server on a very restricted network (full Access Control Lists, etc.) because the vendor rated it critical (the patch fixed an exploit for remote code execution). The critical rating is perfectly valid for public facing websites but not as severe for servers that don’t interact with the Internet. For those that don’t currently have an established risk assessment process in place (or those that could use some tweaking), the following blog posts might be helpful; “The Annual Struggle with Assess Risk” and “Measuring Security Risks Consistently.” Seems like we planned those other blogs, doesn’t it?
In November of 2010, Facebook introduced their “@facebook.com” messaging option that gave users the opportunity to create their own facebook.com email address. Currently, all Facebook users have the ability to claim their own facebook.com email address. It’s easily accessible from the “messages” page, if your account has not already been set up for it. While the service is a nice way of communicating with non-Facebook friends via email and the Facebook message dashboard, there are some security issues that open up along with the service.
Facebook accepts incoming email messages for delivery from their MX Record – smtpin.mx.facebook.com (220.127.116.11). These messages are currently being accepted for delivery based on their source IP address and whether or not the address is associated with a PTR record. This is supposed to prevent spoofing, but the mail server only checks the IP for a valid PTR record for that IP, and not if the domain of the sender’s email address matches the IP of the mail server. To fix this, Facebook needs to ensure that a message coming from a gmail.com address is originating from a Gmail mail server. Messages from non-PTR record IP addresses are stopped by the Facebook mail server.
SMTP connection attempt from an IP without a PTR record:
$ telnet 18.104.22.168 25 Trying 22.214.171.124...
Connected to smtpin.mx.facebook.com (126.96.36.199).
Escape character is '^]'.
554 5.1.8 DNS-P3 https://postmaster.facebook.com/response_codes? #dns-p No PTR Record
Connection closed by foreign host.
The Facebook mail server does however allow incoming messages from IPs with a PTR record, which allows us to spoof messages from other users. If you are behind an IP address with a PTR record, you can spoof a message from an external domain to a facebook.com email address.
Currently, Facebook is properly blocking incoming messages spoofing a facebook.com domain. If Facebook gets breached, and their semi-private @facebook.com email addresses are leaked publicly, someone could easily start spoofing messages between users to propagate spam, phishing attacks, and/or malware. Right now, it’s not very hard to guess someone’s Facebook email address based off of their Facebook username, so Facebook needs to implement a filter that ensures the IP address from which a message originates matches the IP address of the MX record for the domain the message claims to come from. This will prove the sender of the message is on the same domain as the address they are claiming to represent. This does not outright remove the risk of spoofing between users, but it’s a good start. Currently Facebook does some notification on suspicious messages. This equates to a small yellow triangle in the right hand corner of the message. It’s not very obvious and could easily be interpreted as “important” or “urgent.”
The above message was sent from my spoofed Gmail address to my @facebook.com address.
It should be noted that Facebook is not the only site that falls victim to SMTP spoofing issues. Many of the social networking sites that allow users to accept emails as messages may be vulnerable to the same issues.
Necessary cookies help make a website usable by enabling basic functions like page navigation and access to secure areas of the website. The website cannot function properly without these cookies.
YouTube session cookie.
Marketing cookies are used to track visitors across websites. The intention is to display ads that are relevant and engaging for the individual user and thereby more valuable for publishers and third party advertisers.
Analytics cookies help website owners to understand how visitors interact with websites by collecting and reporting information anonymously.
Preference cookies enable a website to remember information that changes the way the website behaves or looks, like your preferred language or the region that you are in.
Unclassified cookies are cookies that we are in the process of classifying, together with the providers of individual cookies.
Cookies are small text files that can be used by websites to make a user's experience more efficient. The law states that we can store cookies on your device if they are strictly necessary for the operation of this site. For all other types of cookies we need your permission. This site uses different types of cookies. Some cookies are placed by third party services that appear on our pages.
Discover why security operations teams choose NetSPI.