hrbrmstr, Author at rud.is

Author Archives: hrbrmstr

Don't look at me…I do what he does — just slower. #rstats avuncular • ?Resistance Fighter • Cook • Christian • [Master] Chef des Données de Sécurité @ @rapid7

VERIS Community :: JSON vs XML

2012-07-20 – 21:06
Posted in Information Security, Javascript, VERIS
Comments (2)

You may not be aware of the fact that the #spiffy Verizon Biz folk have some VERIS open source components, one of which is the XML schema for the “Vocabulary for Event Recording and Incident Sharing”.

While most Java-backends will readily slurp up and spit back archaic XML data, the modern web is a JSON world and I wanted to take a stab at encoding the sample incident in JSON format since I’m pretty convinced this type of data is definitely a NoSQL candidate and that JSON is the future.

I didn’t run this past the VZB folk prior to the post, but I think I got it right (well, it validates, at least :-) :

```
{
```
```
  "VERIS_community": {
```
```
    "incident": {
```
```
      "incident_uid": "String",
```
```
      "handler_id": "String",
```
```
      "security_compromise": "String",
```

      "related_incidents": { "related_incident_id": "String" },

```
      "summary": "String",
```
```
      "notes": "String",
```
```
      "victim": {
```
```
        "victim_id": "String",
```
```
        "industry": "000",
```

        "employee_count": "25,001 to 50,000",

```
        "location": {
```
```
          "country": "String",
```
```
          "region": "String"
```
```
        },
```
```
        "revenue": {
```
```
          "amount": "0",
```
```
          "iso_currency_code": "USD"
```
```
        },
```
```
        "security_budget": {
```
```
          "amount": "0",
```
```
          "iso_currency_code": "USD"
```
```
        },
```
```
        "notes": "String"
```
```
      },
```
```
      "agent": [
```
```
        {
```
```
          "motive": "String",
```
```
          "role": "String",
```
```
          "notes": "String"
```
```
        },
```
```
        {
```
```
          "type": "External",
```
```
          "motive": "String",
```
```
          "role": "String",
```
```
          "notes": "String",
```
```
          "external_variety": "String",
```
```
          "origins": {
```
```
            "origin": {
```
```
              "country": "String",
```
```
              "region": "String"
```
```
            }
```
```
          },
```
```
          "ips": { "ip": "String" }
```
```
        },
```
```
        {
```
```
          "type": "Internal",
```
```
          "motive": "String",
```
```
          "role": "String",
```
```
          "notes": "String",
```
```
          "internal_variety": "String"
```
```
        },
```
```
        {
```
```
          "type": "Partner",
```
```
          "motive": "String",
```
```
          "role": "String",
```
```
          "notes": "String",
```
```
          "industry": "0000",
```
```
          "origins": {
```
```
            "origin": {
```
```
              "country": "String",
```
```
              "region": "String"
```
```
            }
```
```
          }
```
```
        }
```
```
      ],
```
```
      "action": [
```

        { "notes": "Some notes about a generic action." },

```
        {
```
```
          "type": "Malware",
```
```
          "notes": "String",
```
```
          "malware_function": "String",
```
```
          "malware_vector": "String",
```
```
          "cves": { "cve": "String" },
```

          "names": { "name": "String" },

          "filenames": { "filename": "String" },

          "hash_values": { "hash_value": "String" },

          "outbound_IPs": { "outbound_IP": "String" },

          "outbound_URLs": { "outbound_URL": "String" }

```
        },
```
```
        {
```
```
          "type": "Hacking",
```
```
          "notes": "String",
```
```
          "hacking_method": "String",
```
```
          "hacking_vector": "String",
```
```
          "cves": { "cve": "String" }
```
```
        },
```
```
        {
```
```
          "type": "Social",
```
```
          "notes": "String",
```
```
          "social_tactic": "String",
```
```
          "social_channel": "String",
```
```
          "email": {
```

            "addresses": { "address": "String" },

            "subject_lines": { "subject_line": "String" },

```
            "urls": { "url": "String" }
```
```
          }
```
```
        },
```
```
        {
```
```
          "type": "Misuse",
```

          "notes": "Notes for a misuse action.",

```
          "misuse_variety": "String",
```
```
          "misuse_venue": "String"
```
```
        },
```
```
        {
```
```
          "type": "Physical",
```

          "notes": "Notes for a physical action.",

```
          "physical_variety": "String",
```

          "physical_location": "String",

```
          "physical_access": "String"
```
```
        },
```
```
        {
```
```
          "type": "Error",
```

          "notes": "Notes for a Error action.",

```
          "error_variety": "String",
```
```
          "error_reason": "String"
```
```
        },
```
```
        {
```
```
          "type": "Environmental",
```

          "notes": "Notes for a environmental action.",

          "environmental_variety": "String"

```
        }
```
```
      ],
```
```
      "assets": {
```
```
        "asset_variety": "String",
```
```
        "asset_ownership": "String",
```
```
        "asset_hosting": "String",
```
```
        "asset_management": "String",
```
```
        "os": "String",
```
```
        "notes": "String"
```
```
      },
```
```
      "attribute": [
```
```
        { "notes": "String" },
```
```
        {
```

          "type": "ConfidentialityPossession",

```
          "notes": "String",
```
```
          "data_disclosure": "String",
```
```
          "data": {
```
```
            "data_variety": "String",
```
```
            "amount": "0"
```
```
          },
```
```
          "data_state": "String"
```
```
        },
```
```
        {
```

          "type": "AvailabilityUtility",

```
          "notes": "String",
```

          "availability_utility_variety": "String",

          "availability_utility_duration": "String"

```
        }
```
```
      ],
```
```
      "timeline": {
```

        "timestamp_first_known_action": {

```
          "year": "2001",
```
```
          "month": "--12",
```
```
          "day": "---17",
```
```
          "time": "14:20:00.0Z"
```
```
        },
```

        "timestamp_data_exfiltration": {

```
          "year": "2001",
```
```
          "month": "--12",
```
```
          "day": "---17",
```
```
          "time": "14:20:00.0Z"
```
```
        },
```

        "timestamp_incident_discovery": {

```
          "year": "2001",
```
```
          "month": "--12",
```
```
          "day": "---17",
```
```
          "time": "14:20:00.0Z"
```
```
        },
```
```
        "timestamp_containment": {
```
```
          "year": "2001",
```
```
          "month": "--12",
```
```
          "day": "---17",
```
```
          "time": "14:20:00.0Z"
```
```
        },
```

        "timestamp_initial_compromise": {

```
          "year": "2001",
```
```
          "month": "--12",
```
```
          "day": "---17",
```
```
          "time": "14:20:00.0Z"
```
```
        },
```
```
        "timestamp_investigation": {
```
```
          "year": "2001",
```
```
          "month": "--12",
```
```
          "day": "---17",
```
```
          "time": "14:20:00.0Z"
```
```
        }
```
```
      },
```
```
      "discovery_method": "String",
```
```
      "control_failure": "String",
```
```
      "corrective_action": "String",
```
```
      "loss": {
```
```
        "loss_variety": "String",
```
```
        "loss_amount": {
```
```
          "amount": "0",
```
```
          "iso_currency_code": "USD"
```
```
        }
```
```
      },
```
```
      "impact_rating": "String",
```
```
      "impact_estimate": {
```
```
        "amount": "0",
```
```
        "iso_currency_code": "USD"
```
```
      },
```
```
      "certainty": "String"
```
```
    }
```
```
  }
```
```
}
```

I believe I’d advocate for the “timestamps” to be more timestamp-y in the JSON version (the dashes do not make much sense to me even in the XML version) and any fields with min/max range values to be separated to actual min & max fields. I’m going try to find some cycles to mock up a MongoDB / Node.js sample to show how this JSON format would work. At a minimum, even a rough conversion from XML to JSON when requested by a browser would make it easier for client-side data rendering/manipulation.

If you’re not thinking about using VERIS for documenting incidents or hounding your vendors to enable easier support for it, you should be. If you’re skittish about recording incidents anonymously into the VERIS Community, you should get over it (barring capacity constraints).

SSH Password Time-series Heatmap In D3

2012-07-12 – 14:33
Posted in Charts & Graphs, d3, Information Security
Tagged d3, heatmap, honeypot, passwords
Comments (1)

In @jayjacobs’ latest post on SSH honeypot passsword analysis he shows some spiffy visualizations from crunching the data with Tableau. While I’ve joked with him and called them “robocharts”, the reality is that Tableau does let you work on visualizing the answers to questions quickly without having to go into “code mode” (and that doesn’t make it wrong).

I’ve been using Jay’s honeypot data for both attack analysis as well as an excuse to compare data crunching and visualization tools (so far I’ve poked at it with R and python) in an effort to see what tools are good for exploring various types of questions.

A question that came to mind recently was “Hmmm…I wonder if there is a patten to the timings of probes/attacks?” and I posited that a time-series view across the days would help illustrate that. To that end, I came up with the idea of breaking the attacks into one hour chuncks and build a day-stacked heatmap which could be filtered by country. Something like this:

I’ve been wanting to play with D3 and exploring this concept with it seemed to be a good fit.

Given that working with the real data would entail loading a ~4MB file every time someone viewed this blog post, I put the working example in a separate page where you can do a “view source” to see the code. Without the added complexity of a popup selector and loading spinner, the core code is about 50 lines, much of which could be condensed even further since it’s just chaining calls in javascript. I cheated a bit and used jQuery, too, plus made some of it dependent on WebKit (the legend may look weird in Firefox) due to time constraints.

The library is wicked simple to grok and makes it easy to come up with new ways to look at data (as you can see from the examples gallery on the D3 site).

Unfortunately, no real patterns emerged, but I’m going to take a stab at taking the timestamps (which is the timestamp at the destination of the attack) and align it to the origin to see if that makes a difference in the view. If that turns up anything interesting, I’ll make another quick post on it.

Given that much of data (“big” or otherwise) analysis is domain knowledgable folk asking interesting questions, are there any folks out there who have questions that they’d like to see explored with this data set?

Security & Privacy Of Mountain Lion’s Dictation Feature

2012-07-12 – 09:43
Posted in Apple, Compliance, Information Security, Mountain Lion
Comments (3)

With Gizmodo doing a post hyping Mountain Lion’s new dictation feature it’s probably a good time to note that folks in regulated environments or who just care about security & privacy a bit more than others should not enable or use this feature for the dictation of sensitive information.

From Apple’s own warning on the matter:

When you use the keyboard dictation feature on your computer, the things you dictate will be recorded and sent to Apple to convert what you say into text. Your computer will also send Apple other information, such as your first name and nickname; and the names, nicknames, and relationship with you (for example, “my dad”) of your address book contacts. All of this data is used to help the dictation feature understand you better and recognize what you say. Your User Data is not linked to other data that Apple may have from your use of other Apple services.

It’s much like what happens with Siri, Dragon Dictation or a myriad of other iOS and modern desktop apps/browser extensions. Thankfully, it performs the transfers over SSL, but that still won’t help you if your dictating health, financial or other regulated/NPPI/PII data.

While the feature is cool and does work pretty well, it’s important to make sure you and your users know what it does, how it works and where they can/cannot use it.

Honeypot Analytics : 500 Pretty Passwords

2012-07-09 – 14:23
Posted in Charts & Graphs, Information Security
Tagged honeypot
Comments (2)

I had a few moments this past weekend to play with an idea for visualizing the passwords used against the honeypot @jayjacobs set up. While it’s not as informative as Jay’s weekend endeavors:

I'm messing around with how to visualize 60k passwords, how's this? : http://t.co/ocAjQdxm (cc @hrbrmstr )

— jayjacobs (@jayjacobs) July 7, 2012

it is pretty, and it satisfied my need to make a word cloud out of useful data.

The image below is of the top 500 passwords used against the honeypot and requires an SVG-capable browser and also requires horizontal scrolling, so you can view or download it standalone if there are any issues. For those generally SVG-challenged, there’s also a slightly less #spiffy PNG version to view as well.

Beach Blanket Tweetup
(a.k.a. GraniteSec Tweetup #5)

Brylcream? Check.
Decked out in your best Frankie Avalon or Annette Funicello beach fashions? Check.

Now, polish up your cruiser and get ready ‘cuz @GraniteSec is heading back to Fort Foster [info] [map] at Kittery Point, Maine for it’s fifth family & friends tweetup!

We can’t promise mermaids or sky-diving surfers, but you’re sure to have a groovy time hanging loose and chowing down with other hip cats & chicks.

For all the low down, check out granitesec.org (redirect to the latest tweetup Eventbrite page forthcoming) or rap with @hrbrmstr, @ITSecurity or @1_tjw on Twitter.

(And, if any of you younger cats are having trouble with the lingo/references, check this out, man…)

Also, if you want to help promote the tweetup, you can use the above 500x350px graphic or this 160x400px graphic and link to this post or http://granitesec.org/ which will have an Eventbrite redirect up in the near future.

RIM of Destruction

(With apologies to Barry McGuire & P.F. Sloan)

To a familiar tune…

RIM of Destruction

The mobile world, it is explodin’
executives flarin’, app updates loadin’
you’re Bold’s enough to sell but no one’s buyin’
no one believes in your PlayBook, but that’s what your totin’
and even the Curve won’t keep you a floatin’
but you tell us over and over and over again my friend,
ah you don’t believe you’re on the RIM of destruction.

Don’t you understand, what I’m trying to say?
Can’t you see the fears that I’m feeling today?
Your consumer and business customers are all running away,
There’ll be nothing to save with QNX in a grave,
take a look around you, Bidulka, it’s bound to scare ya,
and Thorsten tells us over and over and over again Boulben,
ah, he don’t believe he’s on the RIM of destruction.

BYOD’s got me so mad, my blood’s coagulatin’,
I’m tweeting here (from my iPhone), just contemplatin’,
I can’t twist the truth, it knows no regulation,
that iOS & Android are wildly propagatin’
and BB10 promises alone can’t bring integration,
when platform respect is disintegratin’,
this whole mobile world is just too frustratin’,
and you tell us over and over and over again my friend,
ah, you don’t believe you’re on the RIM of destruction.

Think of all the Samsung phones in China,
iOS is on top even in Redmond, WA!,
Ah, you may think you’re a leader in this space,
but you keep returning to that same old place,
your quarterly reports show no pride, just disgrace,
you buried your heads, and soon there won’t be a trace (of you),
copy your neighbours, who’ve all taken your place,
and you tell us over and over and over and over again my friend,
you don’t believe you’re on the RIM of destruction.
no no you don’t believe you’re on the RIM of destruction.

Honeypot Analytics

For this post (and probably a few subsequent ones), I’m taking the role of ‘Pinky” to @jayjacobs’ ‘Brain’ as I share some of my own analysis on the ssh honeypot passwords that Jay collected (you’ll need to read his VZB post before continuing). There are tons of angles for analysis and I’ve been all over the place as ideas have come & gone. I’m probably not breaking much (if any) new ground as there are a number of honeypot tools that provide #spiffy reports like this, but there may be some new insights or at the very least some starting points for folks new to the honeypot scene.

One of the first things I did with the data was to make a histogram of the password lengths the attackers used:

Some questions come up:

Why 6 & 8 as the most frequent?
What’s up with “khaled-dico-ana-wla-akhou-charmouta-tfeh-kess-ekhtak-bi-ayri-a5ou-a7beh”(the longest one), “FSDwef8529637531598273k1d123kid871kid872tralalalovedolce” and the other large passwords? Are they used in conjunction with other attack vectors (one of my posits)? Are they vanity signatures to inject into honeypots (one of Jay’s posits)

(btw: those are legit questions…if honeypot researchers know the answers, I am curious)

When looking at sources of these attacks, they seem to be concentrated in a few areas:

The brute-forcers also do not seem to rest (click for larger version):

The down days are when they honeypot was, well, down. I am curious as to what caused the surge on the 31^st & the 3^rd? I believe that actually maps to Fri/Mon if the source is China/Russia.

In the coming days/weeks, I’ll break down some analytics by IP address and focus a bit more on the passwords themselves.

Breach Reach : Google Insights

2012-06-23 – 10:16
Posted in Breach, Charts & Graphs, Information Security
Comments (1)

UPDATE: I had to remove the Google Insight widgets and replace them with static images. There was inconsistent loading far too often in non-Chrome browsers. Click on the graphs to go to the Google Insights detail pages for more interaction with the data.

Information security breaches have been the “new black” in the past eighteen months, with the latest fashion-trend being the LinkedIn passwords fiasco. This got me thinking: what is the “half-life” of a breach? It’s becoming obvious that users do not see the security of their information as a service differentiator or even a tier one decision point when choosing to use a new social network or online application. (How many of you closed out your LinkedIn accounts?) But, just how quickly does their attention wane from a breach event? Pretty quickly, if one formulates a conclusion based on Google Insights search data.

Let’s start with LinkedIn

We have a burst that – if one is generous – captures interest for about a week. Even more interesting is that it seems said interest was limited to very specific geographic regions:

Google Insights for Search - Web Search Interest_ linkedin password, linkedin passwords, linkedin hacked - Worldwide, Last 30 days

Plus, the incident continues to help show the lack of impact breaches have on stock price:

But, LinkedIn is not exactly a broad-reaching service (i.e. it’s no Facebook).

Breaches Don’t Stop The Shopping

Investor exuberance notwithstanding, LinkedIn is kinda boring since folks use it to actually publish personal data to the world. While it has some private messaging and may hold some financial account information, it’s not like Zappos which has payment information and shopping history, and who was also breached this year. How long did they get attention?

While there is a longer, flat tail, attention is still about seven days (you can interact with the chart and zoom in to verify that claim) and Zappos’ overall consumer interest does not seem to have waned:

Sownage Revisited

The word “Sony” is now almost synonymous with “breach” in the minds of most information security folk. It’s our “go to” example when talking with executives and application teams. Unfortunately, for the purposes of comparative analysis, it wasn’t just one breach. So, while the chart shows closer to a ten week interest period, that makes sense when one considers there were over ten news stories (one for each new breach):

I won’t go into the details as to why including a stock price chart has little efficacy in determining breach effect for Sony (it’s been analyzed to death), but a comparative look at “PlayStation” (with an added factor for “iPad”) shows (to me) that the breaches had far less impact on interest in the PlayStation (one of the main breach targets) than the iPad had:

Breaches Spook The Spooks

So, if breaches are of little interest to the consumer, they must have greater impact on the community that has some skin in the game, right? Kinda. If we look at the RSA & Lockheed breaches:

We see that the Lockheed breach kept attention from mid-April to about mid-July (12 weeks) and RSA spiked twice for about four weeks each time. Both of them were intertwined in the news and RSA had numerous (to be blunt) PR-events that helped keep focus on both.

RSA is part of EMC, so a stock view analysis has many other complexities that make it less than ideal, but both companies (EMC & Lockheed) did not seem to suffer from the extended initial breach interest:

Only One View

I mentioned at the beginning of the post that this was intended to be a single-factor analysis, limited to what insights Google gleans from what folks are searching for. It doesn’t provide a view into enterprise contractual agreements, service usage patterns or even blogger/social media sentiment analysis. Yet, folks search for what they are interested in and when I add a few parameters to the LinkedIn chart:

we see that people are far more interested in Scarlett Johansson, gas prices and even Snookie than they are in LinkedIn insecurity. Perhaps breaches just aren’t sexy enough or personally impacting enough to truly matter…even to security professionals.