Yes, I survived the Recon 2010 hotel fire. It was held in Montreal from July 9th to the 11th at a supposedly posh hotel where the air-conditioning wasn’t working at all building-wide during a heat wave. Imagine 200 sweaty dudes in a room full of laptops and projectors. As always, it was one of the most interesting reverse-engineering conferences of the year, covering most aspects of reversing ranging from hardware hacking to automated exploit generation to malware analysis. No vendors, no booths, just people that love reverse-engineering.

Like most people, I missed some of the presentations in part or totally because of the unbearable heat in the conference room but no fear, all the presentations were recorded and will be posted online shortly by the organizers. Training was given before and after the conference by Rolf Rolles, Gerardo ‘gera’ Richarte, Alex Ionescu and Tomislav Pericin and a lockpicking training session was given during lunch hour by Deviant Ollam.

Here is a list of the speakers:
Pierre-Marc Bureau and Joan Calvet - Understanding Swizzor's Obfuscation Scheme
Stephan Chenette - Using Fireshark to Analyze Malicious Websites (20 minutes)
Ero Carrera and Jose Duart - Packer Genetics: The Selfish Code
Gynvael Coldwind and Unavowed - Syndicate Wars Port: How to port a DOS game to modern systems
Dino Dai Zovi - Mac OS X Return-Oriented Exploitation
Nicolas Falliere - Reversing Trojan.Mebroot's Obfuscation
Yoann Guillot and Alexandre Gazet - Metasm Feelings (30 minutes)
Travis Goodspeed - Building hardware for exploring deeply embedded systems
Sean Heelan - Applying Taint Analysis and Theorem Proving to Exploit Development
Alex Ionescu - Debugger-based Target-to-Host Cross-System Attacks
Ricky Lawshae - Picking Electronic Locks Using TCP Sequence Prediction (20 minutes)
Assaf Nativ - Memory analysis - Looking into the eye of the bits
Danny Quist - Reverse Engineering with Hypervisors
Deviant Ollam - Finding Chinks in the Armor - Reverse-Engineering Locks
Sebastian Porst - How to really obfuscate your malware PDF files
Jason Cheatham and Jason Raber - Reverse Engineering with Hardware Debuggers (20 minutes)
Stephen Ridley - Escaping the Sandbox
Igor Skochinsky - Intro to Embedded Reverse Engineering for PC reversers
Michael Sokolov - SDSL reverse engineering
Jonathan Stuart - DMS, 5ESS and Datakit VCS II: interfaces and internals
William Whistler - Reversing, better
Georg Wicherski - dirtbox, a highly scalable x86/Windows Emulator
Sebastian Wilhelm Graf - Rainbow tables re-implemented

The most memorable ones that I have seen included the hardware hacking presentation by Travis Goodspeed, who designed the Hope 2010 badge, Dino Dai Zovi, who got me interested again in Mac OS X reversing, Sean Heelan and William Whistler, who both talked about new ways to look at assembly code, Danny Quist, who gave a presentation very similar to mine from the last edition of Recon, Michael Sokolov and Jonathan Stuart, who gave an improvised talk together about VAX/VMS, Pierre-Marc Bureau and Joan Calvet, who talked about very interesting malware that seemed oddly familiar to me and finally, Sebastian Wilhelm Graf, for his use of lolcats and lolgroundhogs.

The organizers held dinners or parties every night and took everybody through a “pub crawl”, a tour of some of the local bars like Tokyo, Saphir and Café Campus. The conference was coincidentally located next to the club district so everything was within walking distance. They even had a show by a nerdcore rapper called Dual Core.

Some icons of the online reverse-engineering community were sorely missed: Mammon, Woodmann, Zero and Fravia (who is now sitting next to +ORC in heaven). I learned reversing from the descendants of the legendary +HCU, who started the first online reverse-engineering community to promote the free sharing of information and tutorials. Reversing for fun led me to malware analysis then to the security field. I am not an academic; I am a product of the internet community who managed to make it in the corporate world, thanks to these guys.

Recon follows the same train of thought, the free sharing of information and knowledge. All the speakers are the top experts of their own field, all related to reverse-engineering or security in general (except the speed talk about HPV, wrong kind of virus maybe?). The new techniques showed and explained in great details allow us to do a better job by working more efficiently. The fields of automated exploit generation and taint analysis could really speed up implementing vulnerability detection, especially on Patch-Tuesdays, where we are bound to our customers by a 24h SLA. We also sometimes do malware detection when there is enough demand for it so all those new analysis techniques will definitely help speed up the coverage development, especially when there are many variants to cover. Finding new ways to automate repetitive tasks always sounds good to me. Some companies might not see a value or ROI in going to Recon since it is not a commercial conference but it was definitely worth it.

All in all, I can’t wait for the next edition of Recon, which hopefully will be held in a different hotel but it doesn’t really matter as the important thing was meeting all these interesting people.
BTW I met Tavis there. Even though there is a disagreement between him and nCircle, he is a really great guy when talking over a beer. Politics had no place at Recon, that’s one of the many things that makes it so special.

The "full disclosure" vs "responsible disclosure" debate has been going on for years, and I doubt it will ever end but recently we seem to have hit a point of critical mass. First we had the "no more free bugs" movement and more recently we have had a series of 0-day vulns dropped under the guise of "full disclosure". I say that it's under the guise of full disclosure because it's not full disclosure. FD is about making companies that refuse to acknowledge vulnerabilities stand up and deal with them… it's not about tooting your own horn and saying "hey look at me". I'd like to think that my arguments in favour of FD in the past give me some ground to stand on as I begin this little diatribe.

Things that are happening lately, and by things, I mean Tavis dropping the Help and Support Center 0-day 5 days after notifying Microsoft, do not qualify as FD. It's being called FD but it's not. Full Disclosure is not the absence of Responsible Disclosure, it is, in the end, an extension of it, designed to call out companies that are not responsive to RD.

Dropping this 0-day was a stupid thing to do… there's no room for additional discussion to be had; it's a plain and simple point. If Microsoft had not acknowledged it after a month, or refused to fix it, then sure… use FD as it is intended… but that's not what happened. My comment is the office after the 0-day was dropped was that my next blog post should be entitled "Tavis is the new Gobbles".

I've been, on occasion, a fairly harsh critic of Microsoft, but in this situation I imagine I was doing the same thing that they were doing. If I were in a cartoon, I'd have had a thought bubble that simply read, "WTF?" but I suppose that people will do what they want to do.

I had intended to leave this topic alone but Brad Spengler posted to DailyDave yesterday and inspired me to write this post. In his post he decided to take the FD another step backwards and present Tavis with kudos for waiting only 5 days. He also called out a number of individuals for speaking against the claimed "FD". This list included Robert Hansen and Andrew Storms, two people I respect and consider to be good friends.

Robert's post on the subject was one of the first I read, and I found myself agreeing with it. I tend to run things by my employer before I discuss them if I expect controversy, whether I'm writing about them here or on my personal blog. We then look at the best way to approach something and handle it in a responsible manner.

As for Andrew, Brad chose to simply insult him and his intelligence. I've worked with Andrew for four years and we don't always see eye to eye (he's responsible for protecting our network and I want to break it :) ) but we're always chatting about things that are happening in the industry and our thoughts on them. On Patch Tuesday, if Andrew points to a patch as being an important one to apply, you can be damn sure that, from the enterprise point of view, it's the first one you want to apply. He's not pointing to specific vulnerabilities and talking about their inner workings, he's speaking as an experienced Director of Security Operations with regard to enterprise networks. It is unfortunate that Brad decided to ignore this and simply made a personal attack.

In the end I think that both Tavis and Brad brought us back a step. The actions that Tavis took indicate that he feels that Full Disclosure and Responsible Disclosure are completely disjoint from each other, while Brad resorted to personal attacks as a defense mechanism.

In the end, until the security community can accept that Full Disclosure exists within Responsible Disclosure we're going to have continuous FD debates. Personally, I'm getting tired of reading them and wish people would acknowledge that tagging something with "Full Disclosure" doesn't absolve them of all responsibility.

On Friday, Chris posted an excellent technical write-up on the TLS Session Renegotiation vulnerability. As he mentioned, nCircle has recently experienced an influx of questions from customers regarding the vulnerability, specifically with regard to PCI.

The most important thing to understand is that the existence of this vulnerability will result in PCI non-compliance from an ASV's point of view. The reason for this is fairly self-explanatory: the CVE (CVE-2009-3555) has a CVSS score of 6.4 and anything over a 4.0 is a fail in PCI-land.

When this vulnerability was first announced I was one of the first to say that it wasn't a "sky is falling" situation (like Conficker was) and I still believe that I was correct. That doesn't mean that I feel this vulnerability is insignificant and from a PCI standpoint, I think it addresses one of the key security aspects that merchants need to focus on; TLS, aka securing communication between the customer and the merchant website.

Q: What is the primary goal of PCI?
A: If you said, "The protection of cardholder data", then you're theoretically correct.

The primary means of protecting that data when it is entered into a website is that little technology that we call TLS. Many years have been spent trying to teach users to check for that yellow lock (and now the green bar) and to get them to trust it. It's not enough that merchants undermine these teaching attempts to save a buck or due to incompetence, now we have a flaw that undermines the protocol itself.

So how do we protect users at this point? We turn off legacy TLS Session Renegotiation and remove the flaw from the protocol implementation. The IETF is working on the latter and it's up to ASVs everywhere to ensure the former while we wait. So if you're dealing with nCircle, or any competent ASV and have this vulnerability, expect us to document it and report you as non-compliant until you resolve it.

There has recently been a couple questions from our customers regarding in-depth technical details of how nCircle detects if TLS Legacy Session Renegotiation is enabled on a server, and so it was suggested to me that I write a blog post about it. Since I've been meaning to set aside some time to write my first blog post since transitioning from being a Software Engineer here at nCircle to a Security Research Engineer on VERT, I figured this would be a great excuse to do just that.

First, I figure some background information would be appropriate. Session Renegotiation was defined by the IETF in RFC 2246 for the TLS protocol. This standard specified that either the client or server can initiate a renegotiation request during an established TLS session. Renegotiation allows new cryptographic parameters to be established for that session, meaning new keys can be used and new cipher suites can be chosen. Why is this bad? Because the server doesn't keep track, nor does it care, about which TLS session a renegotiation is being performed over. This opens up the door for a man-in-the-middle to hijack TLS sessions, meaning the attacker can potentially view confidential information such as credentials or credit card information being transmitted over the session, a big no-no for PCI. Though he cannot simply read the communications in plaintext, since the communication between the victim client and server will be encrypted after the renegotiation has taken place; by exploiting this feature of TLS, a man-in-the-middle may be able to modify the requests themselves in order to obtain confidential information. This vulnerability can defeat the entire point of using TLS, and so it's very important that TLS session renegotiation be detected by IP360 so that it can be disabled on the server before it has the chance to be abused. If nCircle detects this vulnerability on your system, you will not pass PCI compliance. In response to this problem, the IETF has created RFC 5746 to define a TLS extension that cryptographically ties a renegotiation to the TLS connection that established the initial encrypted tunnel. Making use of the renegotiation extension defined in RFC 5746 is commonly referred to as secure renegotiation, whereas the insecure method of renegotiating is known as legacy renegotiation.

In order to take advantage of legacy session renegotiation, an attacker first establishes a connection with the TLS server, and then intercepts a victim’s TLS communications and tunnels them through his own session. The attacker can either establish a TLS session ahead of time and wait for another client to attempt to connect, or the attacker can establish the connection on the fly. Either way, the Client Hello sent by the victim client is intercepted by the attacker, and sent encrypted over the attacker’s session as if the attacker was initiating a renegotiation. After the victim client finishes its’ handshaking process, the attacker then acts solely as a proxy between the victim client and the server. Communication between the victim client and server from this point on is encrypted. Even though the attacker may not be able to read the communications directly, he can inject his own content into the session in an attempt to obtain confidential information or make the server behave in a way that was not intended by the victim client.

An example attack that made use of the legacy session renegotiation flaw is the famous Twitter exploit where a researcher was able to obtain a user’s login credentials by injecting text into the https requests. This caused Twitter to dump the contents of the web request into a Twitter message after it had been decrypted by the server. If the same attack was attempted today, and Twitter’s servers only allowed secure renegotiation, this attack would not be possible. The server would have rejected the attacker’s renegotiation request if he attempted to use the victim client’s Client Hello since the attacker’s TLS session would have been cryptographically tied to himself.

Since I’ll be diving headfirst into the inner-workings of the TLS protocol, this post is geared toward a more technical audience. We have had some positive feedback from our customers regarding our detection of this vulnerability, mostly in cases where the customer thought renegotiation was disabled on their server only to find out that it actually wasn’t. Here at nCircle, VERT has put in a lot of work toward detecting this issue. Considering the critical nature of this vulnerability and how many potential people it impacts, we would like a chance to share our knowledge with other security researchers in the hopes that they may write or improve their own detection for it. At the same time, it would be great to hear feedback regarding our detection that may help us to make improvements to it.

Click here to read about how nCircle detects TLS Legacy Session Renegotiation.

I'm going to talk about something I don't normally discuss; smart phones.

I'm an avid BlackBerry user and would probably be lost without access to it but I've been thinking more and more about the security implications of using a smart phone for enterprise applications.

The BlackBerry is the king of enterprise phones, designed with the enterprise in mind and end-user features tacked as an afterthought. The iPhone, on the other hand, cleans up with average users and enterprise features were thrown in afterward. Either way, both phones ended up with a feature that has lead to them being declared "fit for the enterprise"; remote wipe capabilities. This feature, for those that don't know, allows you to remotely wipe a phone that has been lost or stolen.

I can't help but wonder if we rely too heavily on this feature. The concept of a remote wipe requires remote connectivity. Remote wipe might be sufficient for a phone that is accidentally lost, or randomly stolen, but this isn't really the cases where your data is at risk. The real risk comes from targeted attacks, where the thieves know exactly who's phone they're taking.

It's really no different from any other aspect of enterprise security in the cyber age. Targeted attacks contain the most risk -- Aurora was a great example of this. So how useful is a remote wipe when you're looking at a targeted attack? The answer is pretty simple, it's not.

Let's set up a scenario. If I'm an attacker and I know the phone I'm going after, I'm going to do my homework. I'm going to identify my target, find the best time to grab the phone and try to get it without the victim noticing.

My first move after acquiring the phone (or possibly even before acquiring it) is going to be to neutralize the remote wipe capabilities. I can do this with a $20 cell phone jammer easily purchased on the internet. If there's no signal to the phone, there's no way to remote wipe it. Since this is a targeted attack, I'm not going for the phone as a device to get free calls. I'm going after the data stored on that phone.

One of my colleagues pointed out that most of these devices have passwords and these passwords will wipe the machine after a specific number of failed attempts. My counter to this logic is as follows: In a targeted attack, I'm going to be watching you and paying attention, I'm going to finding out as much information about you as possible. I imagine I'd have a fairly good idea of what your password is, either by learning about you (how many employees passwords can be found by viewing their Facebook page?) or by watching you. Mobile devices don't do much to prevent shoulder surfing. In fact, given their constant use in public, they actually encourage it. With the numeric option on the iPhone or even the alphanumeric option of the BlackBerry, I won't have to watch you for long to determine your password, or at least a close guess at it.

The original iPhone release was deemed "not ready for the enterprise" because it lacked a remote wipe capability. Once Apple added this feature there were a lot of articles saying the iPhone was "now an enterprise tool".

I think that this mind set offers a false sense of security. If we're really relying only on remote wipe as a valid security method for targeted attacks we aren't very well protected. We have to come up with something better. Remote wipe provides peace of mind only for accidental loss or random theft of a smart phone and nothing more.

If you happen to visit one of my favourite blogs from Google Reader, you'll come across a page that simply says 'Invalid GET Data' (e.g. Google Reader link to Is Twitter Making Us Dumb? Bloggers, Please Come Back [working link]) . That's it. It seems that Google Reader, like so many other places today, is making use of Google Analytics Campaign Tracking. This means that every link suddenly has 'utm_source', 'utm_content', 'utm_medium', and 'utm_campaign' appended to it. I find this annoying with most sites because I end up trimming the URL before I email it to people or save it as a bookmark. I find it particularly annoying when visiting Securosis because it triggers what I would call a good security measure. It makes perfect sense for a server to send you an error page when it gets unexpected GET or POST data. That would sure make websites a lot more secure... and would be an added counter measure for when people use $_REQUEST instead of $_POST. I became so annoyed that I did a quick Google search and it turns out that quite a few people complain about campaign tracking and look for plugins to manually remove the extraneous data. I don't have a lot to rant about here... just wanted to point out my current annoyance.

There's been a lot of discussion lately around Steve Jobs' Thoughts on Flash. I read it, laughed and then stopped. In reality, I can't fault Apple for not allowing Flash on the iPad, if you're going to accepted an application that is restricted in as many ways as the iPad is and not having Flash is your biggest problem, then you're having a good day. Flash, like most Adobe products these days, increases the risk to any system it's installed on, not only because Adobe doesn't seem to have grasped security but because everything you add on increases the attack surface and therefore increases the risk.

That being said, I don't really want to be involved in this discussion because both Apple and Adobe have way too many fanboys and that's just a bad place to go. I do, however, have to share something that made me laugh.

After Mr. Jobs went on and on about supporting HTML5 and embracing it as the new standard, I decided to take it for a drive on my iPad. The HTML5 Gmail interface rocked, and HTML5 Youtube was pretty nice as well but that's where the good times stopped. Next I tried to visit the APIRocks HTML5 presentation and was rather surprised when safari crashed. No messages, no pop-ups, and no additional iPad problems... simply Safari closed and I was returned to the home screen. This seems like a bit of an 'oopsie' given how strongly Apple is pushing the "HTML5 instead of Flash" argument.

Check out the video of it happening:

*Poor video quality can be the Blackberry it was recorded with.
*The 20 seconds of sitting at the end of the video can be blamed on YouTube (they don't exist in the original)

In case my posts in the past haven't made this clear, I'm going to state it one more time, I don't see a difference between stability and security bugs. I consider denial of service to be a serious security issue and I know that I'm not alone in that belief. Microsoft even includes denial of service throughout the SDL Security Bug Bar. I used to get rather upset with every browser DoS but I've since accepted that since they'll never all be fixed, there's no use getting upset. This time, however, I want to gripe and I want to gripe about the importance of Email Client Availability.

If you read the bug bar link posted above and look at the client side section, you'll note the following line, "Normal, simple user actions, like previewing mail, viewing local folders, or file shares, are not extensive user interaction." This strikes me as meaning it's something people do on a regular basis and issues in this should be considered slightly more serious than issues in other components of the same product. For today, we're going to focus on previewing mail.

Like most of the business world, nCircle uses Exchange and, by extension, Outlook. Email is, in my opinion, business critical; so when I preview an email and Outlook crashes, I take it pretty seriously. Outlook restarts (minus the preview pane) and I'm good to go but that slight inconvenience can easily become more than an inconvenience if it happens more than once, primarily if an internal application can generate emails that trigger the issue.

I came across this issue by accident, because a piece of software was generating these emails. After it happened, I started digging around and discovered that the culprit was a chunk of HTML, and to be a little more precise that "chunk" is 33 characters long. Now code execution isn't possible, so that takes the issue down a few notches in severity but in my mind it's still an issue.

My mind went "denial of service that hinders my work" and I sent an email off to MSRC. The result of that email… "This is a stability issue; it will be addressed in the next service pack." I find it completely unacceptable that something that can easily interrupt my daily work flow is brushed aside and that I'm required to wait for a service pack release.

Does my little rant have a point? Only to say that if you're going to go out of the way to define "extensive" vs "not extensive" user interaction perhaps it should apply to all issues; that way my issue would be fixed appropriately and I wouldn't have to wait around for a service pack. The days of mail bombing may be long gone, but I fear what would happen if someone decided to target all the employees at a company with this "stability issue". The constant disruption could have serious impact on a business but I guess security isn't concerned with availability.

I've seen numerous blog posts, twitter comments and emails lately about "getting into security". It seems like they've been going on for the last year. Instead of posting my thoughts, I decided to just tell my story.

Before I started high school, I knew I wanted to work in IT. Before I finished high school, I learned I'd really wanted to work in IS. There's something exciting about IS that doesn't exist with run of the mill IT work. That's not to say IT isn't important... it's what keeps us running; but security has always held my fascination. I was your average computer geek in high school; sitting on IRC and forums, reading everything I could find and pissing off my parents by installing Linux on our family desktop. By the end of high school I'd played with robotics, learned a couple new programming languages and spent 2 years playing with Cisco gear and learning networking. I'd even managed to pick up a part-time gig as the administrator of an after school computer program. College brought a new beast; more networking, operating systems and a dash of security and programming. I was building systems and selling them in my free time, and also working 40 hours a week with the student support center where I mapped network drops, wrote some python and did laptop/desktop troubleshooting. Graduation came along, and I didn't know what to do... so I took a job as an "IT Services Manager" for a small marketing company. As the company's jack-of-all-trades, I did everything from printer maintenance to web and graphic design, desktop support to network re-architecture. It was fun (for a while) but not something I sought as a career.

A friend of mine pointed out that a company in Toronto (2 hours from where I was living) was hiring for a Security Research Engineer. I took a look at the website, and applied at 3am on a sleepless Monday morning. I was shocked when I received a call asking if I could come in for an interview. I woke up the morning of the interview (I had to take the 6am bus to make the interview) and decided I wasn't going to bother… they weren't going to hire me, so what was the point. My girlfriend forced me to go, coming along (and skipping class) to make sure I actually went. Here's the fun part of the story that I ended up telling numerous times in the interview that day. The bus I was on broke down midway between home and Toronto. Worried that I wouldn't make my interview, I called a cab to the middle of the highway and took a cab to the interview (to this date, it's still the priciest cab ride I've ever had).

The interview was amazing… I'd never spoken to so many people during a single interview or met so many people at once that spoke as many acronyms as I did. Even in college, I'd never had people around me that were serious about security (or even technology) at the level I was… but as soon as I started interviewing, I knew the people at nCircle were. After the first interview came a second interview (which I almost skipped because I didn't feel my first interview had gone well) and following that interview a job offer. I was also asked when I could start and being a small town country boy, I naively said "2 weeks". It's extremely difficult to tie up loose ends at your current employer, give notice on your apartment, pack, find a new apartment and get moved-in in only 2 weeks. Yet we managed… my girlfriend and I packed up and moved to Toronto (we moved to Toronto the day before I started work… it was crazy)

Yet I'd arrived. I was doing something that I loved and wanted to be doing. That's how I got into information security. Since then I've seen my name in articles (both online and in print). I've travelled further than I'd ever been before. I've spoken to management at Fortune 500 companies and presented research to rooms full of people. That being said, it hasn't been without its ups and downs, it's definitely been a wild ride.

A couple months back I celebrated my fourth anniversary with nCircle and over the course of 4 years I've moved from 'Security Research Engineer' to 'Lead Security Research Engineer'. I've made some incredible contacts and had more fun than work should probably be. I've also gotten to take part in some pretty amazing initiatives and product launches. All in all it's been a fun four years and I'm looking forward to plenty more.

So that's it… that's how I ended up in Information Security. These people that tell you that you need 42 certifications and a masters degree to get into security are steering you the wrong way… sure it's a valid path, but it's not the only one. Proof of that happened just 8 months ago when I was presented with an opportunity to teach a 6th semester security course at the college I attended. We ended up hiring one of my students as an intern and he was with us from January until last week in that capacity. This week he started with nCircle as a full time employee and in the near future will be blogging about his experiences.

Now for the interesting part… if I'd rolled over and turned off my alarm on that day of my first interview, I'd probably be crimping network cables or rebooting a mail server right now, our newest hire would probably be on the job hunt for a network administrator job and you wouldn't be reading this blog post. Amazing what one little decision can do eh?

I'm not sure… but I think that a lot of people might be confused about what a vulnerability is. It seems to me that some people think researchers that are discovering vulnerabilities are magicians, making the vuln appear out of thin air. This is not the case, it already exists… it's waiting there for somebody to stumble across, and yes, people do stumble across bugs that have a negative impact. People also simultaneously discover the same bug. If Person A reports the bug and the vendor does nothing while Person B starts exploiting the bug then there's going to be problems. Yet if Person A publishes the bug while Person B is exploiting it, the vendor will likely respond faster and the solution will be expedited.


There's another discussion point that seems to be causing some confusion. There are people that apparently believe that releasing a vulnerability increases risk by increasing the likelihood of attack. This isn't actually the case and I'm hoping to set people straight right now, once and for all. Let's take a look at the pros and cons of publicly disclosing a vulnerability.
• Pros

1. IDS/IPS, Vulnerability Management and Content Filtering vendors can ship protections and defenses to their customers much more quickly.


2. The vendor will have to respond more quickly and issue a patch sooner.


3. Enterprises and Individuals will know that the problem exists and can take precautions to prevent it from affecting their systems. Be it policy changes, software changes or applying mitigations.


4. Attackers who may have been using the code for nefarious activities are going to see the number of days in which their attack is effective decrease as user awareness increases and mitigations are released.

1. Attackers MAY not have known about the vulnerability, so we may be sharing information with them.