Real Time Social Engineering

In "information gathering" circles the terminology "Open Source" refers to information that can be gathered overtly and in the public domain (rather than today's definition of code licensing). I have been wondering just how easy it is to perform social engineering tasks using open source information in the sort of time that one could operate in conversation.

Whilst social engineering is pretty unethical and it's not the business RapSec is in; I was attending a seminar about social engineering and attempted to see how much open source information I could attain about the speaker in less than 15 minutes whilst standing at a back of a crowded room.

Here is my methodology:

1. Listen. Clues are available from the subjects demeanour (middle class? got kids? clothing style, name, job, title, engagement ring, wedding ring, phone type etc)
2. Plan. If this is being performed in a short time then there are only certain facets of information that will be relevant - there is no point doing a normal graph of attack because there isn't the time and drawing out a plan will incite suspicion.
3. Gather. One must never believe everything you read on the internet. When I do this, I assign probabilities to each bit of data and then only follow high probability routes or indeed try to double check information from another source. I multiply probabilities when working with data depending on other data.
   

Gathering is quite hard on a mobile phone/small device. So I have been wondering if it is worth creating an 'app' to field specially crafted requests to various sites to aggregate the response quickly and for the user to assign probabilities to each leg of the outcomme in order to quickly prioritise the investigation. This has to be very fast. The target data would then be given an overall percentage probability that the user could act on, or dismiss. For most people, probably only useful at parties - but whilst performing a social engineering attack it would be very useful to be able to do this quickly from a standard mobile handset using open source information.

example
For the case mentioned above, I was just testing to see how much data I could find from my phone and in the end got close to the financial KYC minimum in 15 mins.

• checked the name of the speaker. speaker was female and many females use maiden names in a professional context. I missed the first part of the talk so had to google "speaker first name" and company name to double check surname. came up with one hit. probability 100% (there was a photo and a movie)
• the speaker was introduced to being a lot of things (in a humorous "maybe I have been suckered" way) but one crucial word "director" was mentioned. If one is a director of a UK Ltd company then there will be an AP01 or a CH01 form at companies house. Have WebCheck bookmarked into phone with spare credit and do a lookup. This 9 times out of 10 provides home address and also age. In my case I got a 100% probability but typically this is not so certain if you have had no direct contact with the target. For me this got a crucial middle name.
  
• double check the address: directors often don't update their address (this target had). I tend to use 192.com which is quite good for getting previous addresses and date or birth. Obviously previous address (especially shared flats) is very useful as legs of the investigation but in a real time situation they have to be forgotten about. I got a hit on the targets name and middle name with a recent address. Same as the one in companies house. 100% probability.
  
• I was at the back of the room and so I saw a rather large engagement ring. There was another name at the main address so googled that to find a rather nice story about engagement on a university alumni website and so with reasonable precision I could say they were married - and here is where I made a wee mistake - I presumed that the target was operating under a maiden name (as many professionals do) and in fact, there wasn't a wedding ring hiding there, just engaged.
• time ran out, but I would have gone back to 192. and looked for the wedding registration to treble check for better probability of outcome.
• Made for an amusing question at the end of the seminar, job done.
  

so summing up: I got name including middle name, date of birth, employment company including a little extra information about the company, current address, previous address (20% probability), partners name on a mobile phone, in 15 minutes.

Websites that are useful for UK searches:

• LinkedIn
• facebook advanced search and the facebook search sites
  
• friends reunited (not so good as it used to be)
• 192 - voters roll, telephone directory, companies house data
• companies house webcheck
• Skype Diretory
• Google - but be smart. Common names bring up to many false positives. So include favourite sports, industry, company names and so on. use Google crafted urls (see previous blog article)
• Google maps and streetview can provide contextual information but aren't that useful.
  

Proper social engineers use a far wider scope than this and will follow up and interact with high probability leads through the investigation using pretty much unregulated techniques and methods. Be aware that the new data Protection rules prevent "Blagging" but the act does not include using the above websites.

Pen testers, secure email and sexy vulnerabilities

Email has been likened to writing a postcard to a friend, in pencil and sending through the post. It can be read and altered at any point along the way. The postal metaphor encouraged by email clients such as Outlook, Notes, Thunderbird etc is that of a closed envelope so that users are trained into thinking that sending an email is secure.

The recent IT cockup at ACS:law, a law firm specialising in intellectual property theft has now made public what senders and recipients clearly assumed would be private for ever. ACS:Law's website was left mis-configured allowing anyone visiting their home page to right-click download an entire tar.gz archive file of their emails. individuals have taken the database of emails and made websites (e.g. http://ueof.co.uk/acslaw/ [now offline]) allowing various groups to mine the data.

A sample of the data included

• national insurance numbers
• bank account details
• data that would be classified as personal information
• and a lot of internal emails that may well prove inflammatory for various regulators and opposition groups to this firm.

Not only is the data now public - but it is public forever. The data has been spread far and wide over geo-political domains and like garden weeds, it will be difficult to eradicate and will keep coming back.

Clearly, for security researchers, communicating the level of risk inherent in system configurations should be part of the work that they do but all too often I see penetration testers chasing the sexy exploits rather than inform the business of actual risk. It takes skill for a security consultant to communicate the risk in terms that the business will understand without scaremongering.

One client of mine has just implemented a "Secure Email" system using Cisco Ironport. The Cisco product is market leading and has been implemented in a robust way. However, the pen tester (not us!!) brought in to look at the system focussed primarily on the Cisco product, and to their credit found some sexy-yet-minor Information and data leakage vulnerabilities HOWEVER, they totally failed to advise their client about the wider picture and thus missed client-built bespoke addons that were full of holes.

BMI sends out diamond club emails to wrong members

A simple mistake: BMI (British midland Airways) sent all of its Diamond Club members an email this morning - but, they sent the wrong data in the emails so that:

• emails are addressed to the right individual who owns the email address
• have the wrong diamond club information, including membership number
• but have direct HTTP GET links to update promotional choices for the incorrect diamond club account

So, I rang them up and the telephone operator even told me the name of the account holder whose information i received. So, I'm sorry Mr Mason - when I clicked on http://bmi-email.co.uk/re?l=5uh9yaI1nklj0xI1I5sdpup&req=dcnumber%3D00000710196 - I opted for your account to receive status miles instead of destination miles...

Separating a fool from their money

It's never been easier. The UK Gov (including the HMRC) have made it's online systems and telephone services so complex to get advice that many individuals are turning to the web for advice and support. What astounds me however is the information that people are adding as comments to blogs.

On this blog, the following information was given out by one individual:

• name
• address
• age
• national insurance number
• some tax code history

Another, offered their change of address - as a comment? There are at least 5 national insurance numbers & names. Did they really think that the dailydigit blog was the HMRC? Has none of the advice given out about web surfing and verifying the site identity got through to people - and more importantly, why are blogs like this moderating comments like this to appear?

It's also here; where a retired police officer volunteers even more information after being asked (well enough for an identity fraud)

For more information - google popular queries - "my NI number is", "my tax ref no is", "my passport number is"

Argos Sending Private Data in Receipt Emails

TheRegister has a great story about Argos using receipt emails that have HTML embedded in them that contains parameters including full unencrypted card number, CVV code, expiry date, name as printed on the card and address. Clearly a massive breach.

However, it gets more interesting when you look at one of these emails, Chris Geek Guy has copied one to his blog. Whilst it is clear that Argos have copied lots of personal data to the HTML email, I think there are bigger problems. The data is embedded in a GET html link. To me, this shouts out XSS and CSRF risk and also, if you look at the link, this data would always be sent across the internet in the clear - usually being cached as it travels through the internet - if the user did in fact click on the link in the email.

Potential targets for exploitation (and I haven't tried) would be: includeName, the com.ibm.commerce.context.experiment.ExperimentContext which looks like it is directly referencing an object (!!!) outside the context of the system. It would also be worth exploring what this link actually does and whether manipulating the receipt and performing a replay attack changes anything on the Argos server.