The Curious Case of Annie Myous: Part II

In one of my recent posts, I described how I was contacted by a young lady on Google Plus, and how I was having trouble tracking down the scam. Well, now that I know for sure it’s a scammer, rather than an unfortunately lonely real person, I can reveal a few more details:

Annie Myous was my name for Victoria Mark. which is a pseudonym for some random scammer. Shortly after I accepted the request, I received a message like this in my hangout:

I would like to get to know you more better You can drop me your phone so i can text you

I wasn’t about to send my phone number, so I responded with something along the lines of “let’s just use Google hangouts.” And I received this:

Same here I am single know kids How long have you been single What is your phone so i can text you when next i am online

Hmmm. So one thing is becoming very obvious. Either Huntsville school district has a lot of work to do teaching their kids proper grammar, or this is not a native English speaker. Scammers do not often have a very good command of the English language. Oh, and I never asked about kids.

I decided to see if the scammer would confirm knowing someone I made up. So I responded with this:

I see you went to Huntsville. Do you know Reg McDonald?

And what did I receive next? Nothing! Nada! It’s been four days since I sent that and I have received no reply! Am I not scam-worthy enough for you Mr. Scumbag?

Since I didn’t get very far before, I decided to Google the text of the messages I was sent. Bingo! There is some very similar sounding messages over here at Pig Busters.

At this point my feelings are hurt that I am not scam-worthy and I am bored. So goodbye, Ms. Mark. It could have been beautiful.

Posted in Computer Crime, Dialogue, Social Engineering

Are You Secure? Ten Signs That Your Security Program is Doing Pretty Well

Security is a process. It’s an evolving process that when mature, has certain qualities about it. Here are ten signs that your security program is at a decent point of maturity.

  1. A new critical security advisory is released and you are able to make a quick assessment of potential impact to an asset list you already have identified. You decide whether to include the fix in a normal patch cycle or to invoke your incident response plan.
  2. Your risk management program is integrated with the budgeting process, so major security needs are identified and budgeted for the year prior to implementation.
  3. Security is part of the procurement process. Security standards are included in the RFP for new products, even when they are not security products. Preference is given to vendors who demonstrate a commitment to security. When vendors fail to meet regulatory requirements, they are disqualified.
  4. A technical mechanism exists to respond to security incidents before they happen, such that the spread of malware can be stopped by flipping a few switches. You are confident in this infrastructure because, as part of your normal administration, it is kept up-to-date and fully deployed.
  5. Every effort is made to make security easier and preferable to insecure options for business users.  User interfaces matter. Documentation matters. Complaints are taken seriously. It does not get in the way of people just trying to do their job.
  6. The Security Department is seen as a business partner and a source of quality information about risks and trends. Business-integrated KPIs show the impact of various controls.
  7. The primary driver of the Security Department is not to add more tools, but to assess which tools are the best, and to get rid of those that provide little to no value. Reducing complexity while maintaining protection is part of an ongoing thought exercise.
  8. The largest expenditures of labor in the system procurement process is when a system is first introduced. Iterative security scans are performed. Listening ports are verified. Monitoring is set up. Rights are assigned according to least-privilege. The system is not production ready until the security requirements have been met or risks accounted for and compensating controls assigned.
  9. Your staff is qualified, well-rested, well paid and given multiple opportunities for professional development. Although they receive job ticklers from recruiters weekly, none are quite enough to make them jump ship.
  10. Audits are just another business process. While a check is done before the auditors come, it’s just to make sure everything is in order. Evidence has been collected throughout the year and is readily available at any time.

These aren’t all of the signs of a mature security program, but if you see five or more of these in your company, you are well on your way to a healthy program.

Posted in Dialogue, Incident Response, Secure Administration, Secure Design, Standards, Systems Hardening

The Curious Case of Annie Myous

I recently received a Google Plus request from someone I didn’t know. We’ll call her Annie for now. I usually dismiss these out of hand. They are commonly spam of two types: someone using a sexy pic of a young woman to lure people in, or some kind of “joke of the day” page designed to get followers. But this one was a bit different. It was a pic of a pretty young girl, but not sexualized, and “her” friends included many security peeps. So being curious as to what was up, I accepted. When someone else commented she had a nice pic, I +1ed the comment.

Within a day or two I got a message. She was interested in getting to know me better. How nice! I responded that I was unavailable (in the relationship kind of way) and have yet to receive a reply, but I’m eager to see if there will be a hook designed to draw me in further.

Using Pipl, I searched for the user’s name from the location in her profile. Nothing. I looked at the Exif headers from the photo. Nothing. I searched Facebook. Nothing resembling that user. I tried to get a list of graduates from the school she says she attended to verify the name. No luck. I did a Google image search. Nada.

The security guy in me thinks this is probably a pretext to something. Why would a young woman with no apparent security interests have predominantly other security guys in her circles? Why would there be no results from Facebook, Pipl or something in the Exif header? Younger people typically leave some kind of digital footprint. Then again, I suppose it could be just a lonely person looking for a friend. Naaah!

I’ll post an update if I find out more. In the mean time, if you have tips for my armchair investigation, please do comment!

Posted in Privacy, Social Engineering

The OpenSSL Heartbeat Vulnerability: Forgotten Attack Vectors

The web is abuzz with reports of the OpenSSL Heartbeat vulnerability. It’s not an understatement to say that this is the most serious vulnerability to come along in several years. There are many good write-ups about it and I don’t need to repeat them here, but the bottom line is that sensitive information like oh, usernames and passwords can be remotely scraped from sites like, oh, your bank. And there is no log to indicate that it happened.

So while everyone focuses on getting their web servers patched, I wanted to point out a few areas where people may not be looking:

  • Mail servers use SSL to send mail and deliver it to you. If you run a mail server, patch your system and restart your mail services.
  • Windows servers don’t just run IIS. They run Apache, too. Sometimes vendors bundle Apache and/or OpenSSL with their applications and start an administrative interface on high-numbered ports.
  • Proxy servers, especially those that do SSL-interception, may be vulnerable.
  • SSL-based VPNs are ripe for the picking.
  • Embedded devices may use OpenSSL. A lights-out remote management style device would be another juicy target for attackers.

After you have your publicly-facing web site patched, think laterally. There’s more to this than meets the eye.

Posted in Encryption, Incident Response, Risk Management, Vulnerabilities

Changes with OSSEC

After many years, I have decided to step down from the OSSEC core team. It was not a decision I made lightly, but due to some recent changes in the project, I felt I would be more useful as a contributor, rather than as a maintainer. That is to say, I will still be hanging around, but I’ll leave the heavy lifting to the other guys.

If you haven’t checked in on the OSSEC happenings lately, hop on over to Github. There are lots of things going on.

What’s next for me? I’m not quite sure yet. I still have a strong desire to develop better OSSEC rules for detecting attacks. Maybe I’ll find another open source project that needs help. Then again, it’s about time to start my garden. The future has yet to be written. :)

Posted in Intrusion Detection Tagged with:

With Your Finger on the Trigger…

It was a pretty ordinary day. I think I was doing a review of our firewall ruleset–a decidedly monotonous but necessary task. Then in came an alert that McAfee had deleted a file on one of our workstations. That doesn’t happen often, but it’s also not out of the ordinary. A minute later there was another alert. Then another. By this time, my attention had peaked and my heart rate started to increase. Did we have an outbreak?

The CISO, who also gets these alerts, nearly crashed into me as we raced to each other’s office. Something was definitely up and we had to act fast. The pressure was on. An incident was happening and the first step was to contain the threat. We had two choices:

  1. It could be a bad DAT update. We could disable AV across the company until we had a chance to identify the problem, roll back the DAT and turn AV back on. If we didn’t disable AV, then we might have hundreds of blue-screening computers to deal with.
  2. It could be a worm spreading throughout the company. If we disabled AV, that could be catastrophic. It could allow the malware to take complete hold of the company.

So, what was the first thing I did? Nothing. That’s right, nothing. I took a few deep breaths. I centered myself. I prepared to act, but did not act.

When dealing with an incident, it’s imperative that you keep a cool head and keep your wits about you. It’s vital that you block out all distractions, including your superiors if they can’t help you in that moment, and focus on containing the incident. Minutes matter. Seconds matter. This is no time for disruptions.

Fortunately, the CISO and I work well together as a team, and he has the technical chops to be useful in situations like this. So we analyzed the symptoms:

  • The files being deleted were not always the same. Many of them were trusted executables that, as far as we could tell, had not been modified.
  • The files being deleted weren’t newly dropped onto the system
  • The files being deleted weren’t always binaries.
  • The detection component was always Artemis, which has a higher risk of false-positives.
  • Web traffic did not correspond with the pattern we were seeing.

Considering that we blocked executables at the proxy, combined with the other symptoms, we made the call that it must be a problem with Artemis and disabled that component temporarily in order to contain the immediate threat. We then followed with the remaining incident response steps: eradication, recovery and lessons learned.

It turns out we were right and we made the right call. But we could have just as easily made the wrong call. In the heat of the moment, you sometimes have to make the best decision you can with the facts at hand and then deal with the consequences of that decision.

A mature incident response program will allow for bad calls as well as good ones. It will have checks and balances. It will stand behind the people making the call if they are otherwise good people, even if it turns out to be the wrong call. It will be team-focused and not individual-focused. It will learn and grow and it will evolve. The point is to have a program in place and do something. The rest will follow.

Posted in Incident Response, Intrusion Detection

Malicious Data From Trusted Companies

Last night, I received one of the typical malicious “you have a package waiting” spams to an email address that I have only used at one place–in this case DynDNS.com. It included a link inviting me to print a shipping label, which of course leads to malware.

I logged into my DynDNS account with the intention of notifying support that they may have been breached, when I happened to stumble on some community forum posts indicating that others were experiencing the same thing. This in turn linked to an acknowledgement by the company that they were at least aware of the issue.

In this case, DynDNS believes that a business partner was responsible. Although we can never really know for sure, it does point out that your security is dependent on an entire ecosystem of trust. You trust companies that you do business with not to send you malicious data, and they trust companies that they do business with to do the same. They also trust that company to not send malicious data to their customers, because they have inherently opened themselves up to some liability for some quantifiable benefit.

Tony Perez of Sucuri Security does a decent job explaining how external services can compromise the integrity of your web site. It’s not uncommon these days for major sites to deliver malicious data to their users by way of ad networks.

The one thing I see missing with DynDNS and others like them is an acknowledgement of responsibility. When a company chooses to places trust in a business partner, that doesn’t mean they are off the hook for security. The company needs to hold that partner accountable, as the customer should hold the business they are interacting with accountable. The responsibility and accountability has to end with someone and in this case, it is DynDNS that is responsible for the breach of trust.

No one does security perfectly, but remember to vet your partners carefully. Think about what customer data you share with your business partners and remember to extend your incident response plan to include scenarios where that partner becomes compromised, because ultimately, you are the one accountable to your customers.

Posted in Incident Response, Risk Management Tagged with:

OSSEC CON 2013 Materials Available

My and my esteemed colleagues’ presentations from OSSEC CON 2013 are now available. The conference summary can be found here and my presentation can be found here.

It was great meeting everyone and we had some great discussions surrounding how to make OSSEC better. Version 2.7.1 is just around the corner and we are really looking forward to some exciting changes for v3.0 (still in planning). Once again, I would like to thank Trend Micro for graciously hosting this event and for their generous contributions to the open source community.

Posted in Intrusion Detection, Log Analysis, Log Management Tagged with: ,

OSSEC CON 2013

Please join me at the second annual OSSEC conference, OSSEC CON 2013. I have the pleasure of joining Scott Shin, CTO of AtomicCorp, and Santiago Gonzalez, Director of Professional Services at AlienVault, in presenting. Time is running out to register, so make sure you sign up before there is no space left. What’s the cost? Free. Nothing. Zip. Nada! And there’s even free lunch. Hope to see you there.

Posted in Intrusion Detection, Log Analysis Tagged with:

Voting Without Photo ID

I successfully voted for President of the United States tonight without showing a photo ID. Perhaps some background is in order…

Last year, Texas passed a law that required voters to present photo ID to vote. A federal court later overturned the law, ruling that it would impose “strict, unforgiving burdens” on poor minority voters. Regardless of your views on whether this was a just ruling or not, this means voters do not have to present a photo ID to vote.

Other forms of identification are acceptable to vote, such as a utility bill. So with that in mind, I decided to test the response of the election workers to see if they had been properly instructed on the new law.

So with my water bill in hand, I handed it to the poll worker. She asked for photo ID. I replied that I was going to use my water bill as identification. The worker next to her asked if I had a driver’s license and I replied in the affirmative, but that for the purposes of voting I was going to use my utility bill. We went back and forth a couple more times until the original worker recalled that she had been told in training that using a utility bill was acceptable. One last attempt was made asking me for my driver’s license number, to which I declined. Eventually, I was allowed to vote.

To my surprise, I was then given the option of a paper ballot or an electronic vote. Of course, I chose paper since electronic voting has been found to be less than robust.

So what did I learn from this experience? Was this a vast right-wing conspiracy to deny me the right to vote by ignoring the judges’ ruling? No, I don’t think so–not for a moment. I think this was simply a case where the workers did not know how to account for the one individual who declined to show a photo ID, who did not follow the norm. It was a training issue. But that’s not to say this is not an important issue. Whether the intention is underhanded or not, I did feel pressured to show ID and that was not required by law.

Election integrity is important in all aspects, whether it is due to vulnerable electronic voting machines or a failure in process. People are just as important as technology and in no other area can this matter than in a democracy.

Posted in Personal Liberty