Thu 6 August SecuriTeacamp

We hope you can brave the (potential) tube strike to join us on the 6th August for a Security themed #teacamp. We’ll be joined by everyone’s favourite whitehat hackers Glyn Wintle and Terence Eden (and maybe some of their peers). They’ll be talking about security, common exploits, passwords and other related themes.

It will definitely be an enlightening and entertaining session so you should bring some friends along to spread the importance of security. Plus there will be free tea and cake provided by dxw!

Time: 4pm – 6pm
Location: Café Zest, 2nd floor House of Fraser, 101 Victoria St London SW1E 6QX.

How does teacamp work?
If you want to come to teacamp, just turn up on the day, it is open to everyone. It is in the corner of the cafe and very informal and friendly. If you are coming for the first time or on your own, ask for Jane, Ian or Sarah and we will introduce you to some teacampers.

4.00 – 4.30pm:  free tea and cake, kindly provided by @thedxw
4.30 – 4.40pm:  introductions and you can plug any events, projects, etc
4.40 – 5.10pm:  speakers slot
5.10 – 6.00pm:  Q&A, group discussion
6.00pm: #beercamp in nearest pub, often led by @baskers….

Contact info
@teacamplondon Jane O’Loughlin
@_ianw  Ian Dow-Wright
@baskers Sarah Baskerville

---

Summary of the talks

Terence Eden’s talk focused on WordPress, which accounts for something over 23% of the top 10 million websites (according to Wikipedia) and is widely used in government. There have been a number of well-known WordPress hacks, but the system is reasonably secure if a couple of conditions are met:

• Users select good passwords (a common, recurring problem that is difficult to fix even if we use a password manager to generate random passwords and assign them to users – either the users will change them to something easier (which stereotypically winds up with a high percentage using very insecure choices like “password”) OR they will forget them and we will have to deal constantly with issuing new ones.
• The site owner implements two-factor authentication. That means that when users log in they would be required to, for example, type in a code sent to their phones. Users typically find this inconvenient.
• Both WordPress and any plug-ins that are installed are kept rigorously up to date.

Eden went on to demonstrate the kinds of issues that arise when these conditions are not met. Because WordPress is in such widespread use, it is a high-value target for hackers looking for vulnerabilities, and any vulnerabilities that are found are rapidly exploited to hack sites.

Using Google to search, type in the string: “rolex site:gov.uk” or “viagra site:gov.uk“.

Doing either will turn up myriad links to pages on government sites that are being used to sell dodgy goods like fake Rolexes or Viagra. Many that show up in such a Google search have already been fixed.

Eden went on to demonstrate inserting his own content into an abandoned NHS breast milk site. That is a particular danger for consumers, because anything sold on such a site appears to have the full support of the organization that owns the site.

Because departments are so frequently reorganized, it’s quite common for sites to get lost in the shuffle. An important aspect of security, therefore, is ensuring that such sites are either handed over or decommissioned.

Glyn Wintle gave two talks.

The first, on passwords, discussed a number of well-known problems. The first is that people tend to think in similar ways and choose passwords that are easily guessed. Despite years of user education, the most commonly used password is still “password”. The typical response is to restrict password design: one letter must be a capital, one character must be a number. That gets you: “Password1”. If you add enough restrictions, you wind up with passwords no one can remember and users write them down. Rotation policies often also work out well for attackers because many users implement them by simply incrementing the number at the end of the password or use the date of the change (which is usually at highly predictable intervals). This allows attackers to predict the new passwords with great accuracy.

Other commonly used passwords and patterns in Wintle’s experience include:

• personal secrets. Bear in mind that any password you choose may have to be disclosed to a support person at some point.
• “I love”
• “I hate”
• “I want to have sex with”

“Special characters” are almost always ., !, or *.

Wintle noted it’s often possible to tell from passwords how users feel about their job. Also popular: train stations, football clubs, and the names or usage of the sites where passwords are used (something we know from a theft of 2 million inadequately encrypted passwords from LinkedIn). The strategy suggested by the famous XKCD comic is good advice, but don’t use the password they demonstrate.

For content management systems there are two solutions: two-factor authentication (which, as noted, users don’t like), or reduce the risk by reducing the number of privileged users.

Wintle’s second talk was on how to read a penetration test report.

The report should always be provided in writing so it can be shared, shown to whomever needs to see it, and checked up on later.

The front page should be largely boring details.

Next should come the scope of the test, which should be reviewed thoroughly to ensure it’s correct.

Next is an executive summary that should be written in completely non-technical language and explain what attackers can do.

Next, the report will have a CVSS table of scores. People often use these to prioritize what to fix by choosing a threshold and deciding not to fix anything below it. This is not, however, what these scores are for. Decisions should instead be guided by the executive summary: does what the attacker can do affect something that matters?

Finally, the report will have a list of vulnerabilities in detail. While much of this will be technical, it can be useful for checking up on suppliers – for example, if the report says something can be fixed by changing one line of code in a configuration file and the supplier claims it will take three weeks’ work to remediate.

Summary by Wendy M. Grossman

---