Wednesday, 26 August 2015

Introducing Am I Sharing Stuff

A while back, I posted about the dangers of open FTP services that a lot of home routers provide. The more I thought about, the more I realised that it wasn’t visible to people on how to find out if they were sharing files via FTP without going to sites such as Shodan or FileMare.

That is why I created Am I Sharing Stuff and it is now live at https://www.amisharingstuff.com so let me tell you about it.

About Am I Sharing Stuff

After I wrong the post, I went through a number of different ideas on automating searches so that people could see if their router was doing anything suspicious. The more I looked into it, the more I could see that the problem was only getting bigger as routers were being compromised and more files were been exposed.

So I came up with an idea of load a page and tell the person what is wrong and so Am I Sharing Stuff was born.

It is a very simple site that checks if your current IP is sharing information via FTP. It is limited to the FTP service at the moment, but I will expand it to HTTP, Telnet and SMB as these are the most common vulnerable services.

On loading the page, you will be shown your IP and any information the scanner has. Over 40 million IPs have been scanned so far covering the Nordics (Norway, Sweden, Denmark and Finland) with country blocks been added daily.

You can request a scan of your IP and the server will attempt to connect to your shown IP address. Feedback is sent in real time from the scanner so that will get an update while you wait. You can only scan the IP address you are connected from. This is simply to prevent abuse and using the scanner to scan to IP addresses.

You can also remove your information from the site but at the moment there is no permanent blacklisting but this will be coming on stream in a couple of days.

FAQ

What are you doing to connect to my router?

The server sends a request to your router on port 21, the port used by FTP. If your router answers, the crawler will attempt to login using the anonymous credentials. If it logs in, it will attempt to get a list of the directories. The crawler then sends the following information back to the server

  • The IP address that was scanned
  • The country that the IP is registered to
  • If port 21 was open
  • If items were found

No details of the types of files, the number of files or any other information is retrieved nor stored.

Do you charge for the service?

No. Its free to use

What if I don’t want my data on the site

Click the Remove your details button. The site information is deleted. If you click Scan, it will be inserted again. I will be rolling out permanent blacklisting in the next couple of days.

Will removing my site mean you will not scan me again?

Yes, Am I Sharing Stuff’s crawler will not however other crawlers may.

What do I do if I am sharing files and I didn’t realise it?

You can check with the manufacturer of your router and see how to change it. The most common manufacturers are listed below

Technical FAQ

The site is ASP.NET MVC hosted on Azure. Technical write will be coming soon.

Friday, 19 June 2015

A thank you to Skandiabanken

At my NDC Oslo talk today, I showed how to downgrade HTTPS to HTTP on Skandiabanken. It was with the kind permission of the people at Skandiabanken and I would like to express my thanks for that.

The attack I used is a very narrow attack and doesn’t not compromise the bank’s security because of the excellent security that they have implemented but it does show the vulnerability of the underlying network.

The main lesson for people is to keep an eye on your browser because as you saw, the browser showed the correct site but address was webskandiabanken.no.

If you are a regular user of the bank website you should be ok due to the way attack works, as for it to work, you must not have visited the bank in that browser before.

Again, many thanks for their kind permission.

NDC 2015–Session Resources

Here are the resources from my talk “A Pentester’s Toolkit” which I presented today at NDC 2015. Thanks to all of you who came to my talk and I hope you got something out of it.

Since there was a lot of tools shown, I didn’t post a link to them in the session but instead they are listed here in order of appearance in the talk.

Web Links

Recon Tools

Exploit Tools

Network tools

Friday, 27 February 2015

Make me an offer I cant refuse–Writing abstracts for conference organizers

DISCLAIMER: This is all a personal reflection of my experiences and thoughts in relation to being on ONE agenda committee. It does not reflect any of the views of any companies or any other committees etc. I am writing it to provide some help to aspiring speakers who are looking to improve their abstracts and possible their acceptance rate.

TL;DR; Writing abstracts is hard. Write the abstract as if the person reading it, will be making a decision on it in about 15 seconds of reading.

I sat on my first conference agenda committee last week. It was a hugely enlightening experience for me. It was the first time to get to see what happens behind the curtain at these meetings and how hard a job an agenda committee have. It is a very difficult job to decide what talks to include and what talks to reject.

I am a long time speaker and I have submitted talks to lots of conferences around the world. Anytime my abstracts were rejected, I have tried to ask why, not as a criticism but to make my abstracts better and also to learn if there is anything that I can do better. Unfortunately agenda committees rarely have the time to do this and I have been lucky to get some feedback from organizers which I have factored in to this post.

What you need to know about agenda committees.

Agenda committees are invariably a small group of people who have a vested interest in making the best conference possible for the greatest number of attendees. They have limited resources in time, energy and speaking slots. They have their own areas of expertise and will have their own thoughts on certain topics.

So let me put the following scene in your mind.

Its 0900 on a crisp February morning. You are fully charged and ready to review all the submissions you have received in the Call for Papers (CFP). You sit down, a steaming mug of freshly brewed coffee in hand and open your laptop. You start your browser of choice and log into the conference website where your quarry waits. You do a quick count and realize that you have close to 900 submissions to review. It is at this point, that you realize that this will be a monumental task to distil this many talks down into the slots you have available.

How does a committee pick an abstract?

I cannot speak for all committees but I am working on the assumption that the following generally holds true.

The committee first reads the title and they will see does it spark any interest. They may also look at the name of the speaker that is submitting and if they have submitted any other talks.

At this point, a couple of different things can happen.

  • Title is interesting to at least one person, read the abstract
  • Speaker is known and considered “good”, read the abstract
  • Quickly scan the abstract to see if anything stands out

You may have noticed that the first two options mean that your abstract is read while the third option means it is scanned. Invariably most of us are in the third category. This is why a solid abstract is necessary.

Before we discuss the abstract, let us first look at the other components.

The bio

Your bio is how you present yourself to both the organizers and the attendees. It should be enough that people can get a feel for you as a speaker.

Make sure to include a bio. The bio tells people who you are. If you do not fill in a bio/profile and we do not know who you are, it means we have to go search for you and that raises the frustration a bit especially when evaluating you against a similar people. I suppose this is different if you are a household name but even those fill in the bio.

Some common pitfalls that I have seen.

  • Include a photo that is a decent headshot. This is quite easy. Not all of us are great with names and your picture will jog our memories.
  • I feel that you do not need to include your marital status, whether you have kids or a dog etc. I think this is more an American thing but in European countries, it is not required. Again just a personal preference.
  • This does not need to be a CV nor does it need to list all your achievements. It can include some of your previous conferences etc. to give people an idea of where you have spoken before (if applicable)

The Title

A catchy title will help. It does not have to be the funniest, wittiest thing but it should give you enough that you will read the abstract. It should also describe the talk as well.

Below are examples of good titles according to me. These titles are from memory and the abstracts I have seen at conferences. This is not an exhaustive list but just an example of some that I like and why.

  • Brewing beer with Windows Azure - Maarten Balliauw
    • A catchy title, tells me it will be doing something with beer and the cloud
  • Databases: the elephant in the continuous delivery room – Enrico Campidoglio
    • A common problem phrased a catchy way
  • How do you scale a logging infrastructure to accept a billion messages a day? – Paul Stack
    • Problem as a title.
  • Applying S.O.L.I.D principles in C# - Chris Klug
    • Don’t even need to read an abstract to understand what the session is about
  • Embracing HTTP in the era of API’s - Hadi Hariri
    • Doesn’t give a lot away but I imply it will do something with REST and HTTP

The title will be the first thing an agenda committee will see and it should generate a spark. The easiest way to review your own titles. Read it as if you know nothing about the subject and see how you react. Would you go see this talk based on that one line?

The Abstract

Now to the meat of the subject. The abstract is your sell to both the organizers and the attendees. It should be effective enough that on a first scan, people will know what to expect and be able to decide if they should go see it.

I usually go with a four 1 to 2-sentence paragraph approach. This gives the both audiences the breakdown of what I am trying to speak about without being overwhelming. This is not a hard and fast rule, but it is something that I use so that I can simplify the process of both writing abstracts and consuming them. I try to write the abstract so that the person scanning the talk can make an informed decision within the first two or three lines.

My abstract for my talk “Defensive Programming”. Note I chose my own talk as it allowed me to break it down easily and does not offend anyone (other than myself). After following my own advice, I have rewritten parts of the abstract to make it clearer.

The web is a funny old place. You create a wonderful application; deploy it for the world to see and then everybody just wants to break it.

This session will show you some of the most common security mistakes developers make and how to avoid them. There will be (possibly frightening) demos with code in C#.

Talk is rated level 200-300 with a target audience of web developers (not just ASP.NET. All the examples will be in .NET however if you are not a web developer, some of the parts of the talk will be handy)

It is assumed you have some knowledge of web programming, basic security concepts, a working brain and sense of humour.

So line by line

The web is a funny old place. You create a wonderful application; deploy it for the world to see and then everybody just wants to break it.

This opening sentence sets the scene. It tells you some the aspects I will be discussing and allows you to get a general feel if this is something you would like to go see. It is a tag line and could also be a question to the reader.

This session will show you some of the most common security mistakes developers make and how to avoid them. There will be (possibly frightening) demos with code in C#.

Second line, tells you what the presentation will show you. In two lines, you should have an idea of whether you would like to see the talk or not. It should distill down the talk to show that you understand what you are going to show and what the learning objectives are.

In these two sentences, you have the following information

  • Web Development
  • Web Security
  • C# code
  • Demos not just a PowerPoint deck
  • Security mistakes made

Talk is rated level 200-300 with a target audience of web developers (and not just ASP.NET developers. All the examples will be in .NET however if you are not a web developer, some of the parts of the talk will still be interesting)

The third paragraph tells you the level of the talk and the target audience the speaker is going for. This is a handy guideline, which will avoid bad speaker feedback by telling the attendee who the intended audience is. The level here is based on the Microsoft standard level concept which is detailed here

In short 100 means beginner with no knowledge and 400 is “deep dive weird shit™” Most people sit in the 200 and 300 brackets. However, one person’s level 100 is another’s 300 so take these with a pinch of salt.

It is assumed you have some knowledge of web programming, basic security concepts, a working brain and sense of humor.

The fourth paragraph gives you any other information such as prior knowledge, a computer with software installed etc. In my case, it acts as a teaser to say that I do this in a humorous fashion.

Some common pitfalls

  • Poorly formatted abstract.
    • Difficult to read means that people will get frustrated. This might bias any decision for your talk.
  • Spelling errors, missing words etc.
    • A common problem. You think and type. If you do not do a QA check on your abstract, it shows a lack of preparation, which may reflect how you will do your talk. I imply this, and spelling errors annoy me.
  • The abstract doesn’t define a learning objective
    • If it is unclear on what the person seeing your session will learn, then it makes it difficult to decide if it should be included in the conference
  • Abstract is overly long
    • People just give up reading after a while. It is that simple.

I did everything as you said and my talk was still rejected.

There are many reasons why your talk was declined.

  • Larger name speaker with the same talk
    • It is between you and the person that wrote the book/technology/framework. Who would you pick?
  • Another abstract similar to yours looked more appealing
    • This is one of the biggest reasons to decline a talk. Someone has a better abstract or spin on the same topic.
  • Topic was not applicable to the conference
    • Your topic is too niche or the wrong topic for the conference is usually the issue here. If you are doing something that is a bit esoteric then you need to have a good pitch for it. Also submitting a topic that is not in the spirit of the conference will be declined.
  • Session level was to low or too high
    • Beginner talks are welcomed at many conferences but when it is yet another intro to X technology, which is not bleeding edge; it probably will not be picked.
  • You did the talk at a similar conference recently or in a nearby area
    • Note this happened to me with ├średev and they gave me feedback as such. Some conferences have restrictions on performing the same talk again within a specific timeframe and/or geographic area. This can be a contentious point for speakers

Anything else

Some submission forms have a box for additional information and you can use this to sway the committee in your favour. Some examples

  • Video example of previous talks you have done and that are publically accessible.
    • Put the link in. This will save the committee trying to research you and also shows you have presented before·
  • Previous conference talks given and general ratings if you have them.
    • Two hundred people at your talk and all green. Put it down!

If you are a first time speaker then here are some additional tips

  • Find a mentor to help you.
    • I have been lucky and I have gotten a lot of advice from different speakers over the years on everything from tone to how to build my slide deck (kudos to Glenn Henriksen for a lot of help on this!)
  • Practice your talk with your local user group
    • If you have not given the talk before, larger conferences may not be willing to take the gamble. So having a run through of the talk before hand or saying it will be been presented at a local user group will inspire some confidence. It also benefits your user group!
  • Lightning talks
    • If the conference does a lightning talk system, submit your talk as one if possible. It is a smaller gamble and also gives the conference team a chance to see you in action,

So that is it. Again this is all from different experiences so your mileage may vary on this. It is not an exhaustive list at all but