Instant Penetration Testing Setting Up a Test Lab

Instant Penetration Testing Setting Up a Test Lab How-to [eBook]

This book is a good little read I decided to read it as I wanted to get an idea for a new lab I was working on and it didn’t disappoint me. As someone who tries to help other people get into security, I think this book will be a great buy for anyone new to the industry. The book is not extremely large so reading it in one or two days is not a problem with just 88 pages to the Ebook.

The first chapter gives you a basic background to pen testing which I don’t really think is needed as if you are buying this book you are only buying it to help with the lab setup for pentesting.

The book then goes onto talking about lab setups, you should be aware that some examples use windows and a wireless router so you may need to buy a license or purchase hardware, if you want to copy the labs exactly, all other software is pretty much free as it’s Linux based.

The book covers three main labs; one for web testing, one for wireless and online labs. You could get away with networking test labs too, from the setup, but not much networking is involved although you can scan the windows host and Lunux boxes and make changes.

The lab setup consists of Wireless router, Win 2008 web and database, win 2009 domain controller, Ubuntu FTP and radius server, and two windows boxes one XP and the other windows 7.

The book is pretty straight forward with step by step instructions, so it makes it really ideal for anyone even if you have never attempted anything like this before.

Web lab DVWA

The web lab just uses the DVWA that includes all common found web application issues like XSS, SQL injection, CSRF and much more. DVWA is pretty good to learn web application testing

There are also loads of other alternatives like webgoat that do not really get any mention in the ebook which I think is shame.

Wi-Fi lab

In order to setup the wi-fi lab you need to have a wireless router or purchase one off ebay. This lab is pretty good to do and it covers things like radius server too, which is pretty cool as it is not seen in many books.

Online Labs

The book then tells you about online labs and challenges that you can do, it mainly covers /www.hacking-lab.com/ which are pretty awesome labs and challenges with loads of different levels from easy to hard and it is really worth checking out if you have not done so already.

Conclusion

Overall this book is pretty useful if you are new to building a lab and would like step-by-step instructions to build one. However if you already have a lab or are not a complete newbie to pen testing then this book might not be for you. I think there is also information missing from the book and should include other chapters maybe along the lines of how to update your lab, as there are a lot more resources online with regards to building a pentesting lab like http://vulnhub.com/

BsidesLondon Part 2

BsidesLondon part Deux

Another year and another bsides. This year I was lucky enough to attend bsideslondon, however this time I wanted to see bsides from a different point of view. I had already seen it from the attendee’s point of view but wanted to see how much hard work and effort went into the day so I contacted geekchick aka Iggy and put my name forward to help out.

I turned up on the day around 9am as I had to visit a client site before hand. I gave my ticket in and got my green arm pass. I then asked if Iggy was about as I offered to volunteer I was quickly pointed to her as she was dashing about trying to get things sorted. I asked her how I could help and was told to get a crew top and speak to someone else, which was pretty crazy as everyone was dashing about and I was looking for someone that I had never met. But the great thing about the bsides crew is that everyone is really friendly and in a few minutes I had found the person that I needed to speak to. He asked if I could help fill the swag bags as they were a bit behind with, so I jumped to it. This took about 20 minutes to complete, as there were four or five people all mucking in to get the job done.

Once I finished I went downstairs to see what else I could do and was asked to give Mark a hand, who again was really friendly and helpful, since this was my first time as a crew member I didn’t have clue what was expected or what I really had to do. We put some signs up and just make sure the three rooms on the ground floor were all ready for the event, nothing too complicated but it had to be done. He then asked if I could just hang about as people had started to enter the event and just point people in the right direction. Which was again pretty easy but again vital to the running of the day as many people asked me for help so I felt I was filling a small but an important role in a much bigger picture. Throughout the day I had the chance to see some of the talks and talk to a lot of different people and catch up with a few friends too. Throughout the day I had to tidy up and put rubbish in the bins but again this was a team effort it would have been very easy for the crew members to make all the new members clean up but they don’t, everything is a real team effort and an enjoyable one. You are treated like you are part of big family having a joke with others and there no real hierarchy structure, it’s all about getting the job done and being involved which makes it all really fun.

After the event you have to get the bin bags out again and tidy up and pack up the event but everyone gets involved. We finished around 7.30ish which makes the day pretty long but really worth it.

I think if you are shy and find it hard to speak to people at events you should really get involved in being part of the team, which was a really awesome experience. I managed to see how much work really goes into the event from the crew but have a better understanding of how much work the directors of Bside London put in throughout the year. I was so impressed with how much work is actually involved that I approached Paul who is running things now, Iggy and someone else asking if I could be move involved with things. I gave them my contact details and I hope that they haven’t lost them as I really enjoyed the experience and cannot wait to get involved in more events.

Report Writing

As a pen tester the most important part of our job is the report. This is really what the client is paying for. This can also be the hardest part of the job, trying to explain technical stuff to non-techies is a skill on its own and does take time to learn. I first want to make a disclaimer, I am not an expert at writing reports I just want to share my view and when I have done reports the small things I try to include, is to make it readable and presentable to a client.

When writing reports I think it’s extremely important to have consistence. I think this gives it a professional look and it’s really annoying when you read something and it’s not the same thought-out it looks untidy and unprofessional. I have seen inconsistence happen in reports and it’s mainly happens when more than one pen tester will be working on the same job. A really good idea is to have a set of rules that every pen tester uses when writing reports, this will reduce inconsistency within the report.
The headings I tend to use for all my reports are as follows, again I’m not saying this is 100% right but fill free to use it.

Title Page
Document Information
Document Control
Contents
Executive Summary
Testing and Scope
Vulnerability Findings
Final Conclusion
Appendix

The Executive summary is the hardest part of the report, in this I try explaining the highest vulnerabilities in non-technical so no SQL injection or any other jargon, I also try not to use acronyms just because you know what a XSS mean does not mean anyone else does. I try keeping it down to what I done and how it can affect their business and I also like to have little info about who we are and why we are here.

Example:
The Team were asked by fake company to do a pen test on their internal network. The network range we will be testing is 192.168.1.1/25. The aim of this test was to make sure no authorised people could gain accesses and cause damage to the companies business and reputation.
A cool tip I picked up was, it is always nice to give the client a compliment before you tell them all the bad stuff. As no one likes to be told they are not doing as well as they expected. By paying them a compliment I just think it easies the pain, therefore it does not sounds like they are doing everything wrong. This can be anything like ‘you have implemented really good security here’ or ‘we found your network was robust and didn’t crash’

Bad Example: I found SQL injection that allowed me to use SQLmap to dump your MYSQL database and that’s bad.

Good Example: I was able to get your entire customer details, this has a high impact on your business as the information could be leaked and customers will lose faith in your company.
You can also add some charts to the Executive Summary to show vulnerabilities by ratings or any other information you think the executive may find useful.
The testing and scope section is where you write what has been agreed with the client, what IPs you can test and what IPs you should you avoid so on. The details from this will usually come from the TOR (Terms or Reference) this will be like a contract the client has signed saying what you can test, what types test you can’t run like DOS (Denial of service).

The next section is all about the issues you have found, this is usually read by the person or people fixing them which means it’s okay for you to talk techie here. The way I write the issue is to try and have a main heading that contains, type of vulnerability description again I try to have a pattern for each vulnerability heading. I then have HOST, URL, PORT and rating under the heading, I then have three sub headings which are findings, impact and recommendations. As well as that I try to keep each vulnerability on its own page, if I have lots of information for certain vulnerability then I tent to add this to the appendix and reference, it is so the client can view the appendix to find out more information. When writing the vulnerabilities it’s also good to add pictures as proof again, formatting of the picture is important to make sure it’s a good clean picture of what you are trying to show and not just a screen dump that has your desktop and all sorts of other stuff in it.
Finally I finish the report with a nice conclusion on my findings. Once I have written the report I then proof read it making sure everything looks good and makes sense with no spelling mistakes. Then I get someone else to read it, my last company had a department that just sat and read reports all day not the best job in the world but the reports at the end were perfect. I also recommend turning the report into PDF or any other file format and making sure it looks good, if you go to all this effort to convert the file to PDF send it to the client only to find the PDF didn’t convert it and your reports are unreadable.

The main reason behind this post is that I have recently see some reports that well to be honest if I was given them, I would never user that company again. I have covered the basic but obvious tips and hope that this might be useful for anyone who has never written a report before.

Black Box Testing

Black box testing know whats inside your networks.

I recently went to a small event, which was run by my company where a few of the pen testers were giving talks. This blog entry pretty much comes from one of the talks about black box testing.

Black box testing is any device that has the capabilities to run small OS devices like Printers, CCTV, Fridges and coffee machines are a small example of black box devices. They also cause a big problem for business, as most companies do not see these types of devices as a threat.

Businesses all over the world spend hundreds if not thousands on security, from firewall to security assessments each year. The biggest problem they face are devices that are being plugged into their networks by third party companies and no one is taking responsibility for these devices.

The IT department looks after computers and laptops making sure they are up to date with the latest software virus, scans have been run on them etc but they don’t looked after the CCTV or any other third part installing that is done, this means these devices sit in your network without being updated or looked after for month or even for years, this means they are a great target for hackers.

In todays World we have pones that are more powerful than PCs from 4 years ago, so printer and other black boxes devices are smarter and more powerful making them an ideal target to attack, as once you gain access you can then use these devices to install or upload custom tools. Just think if an attacker gained access to your coffee machine and was able to upload nmap they could scan your network from within your network.

A good example of this would be a recent vulnerability, which was found in TRENDnet webcams that allowed anyone to bypass the authentication and gain access. You can read more about this http://cryptogasm.com/2012/02/list-of-vulnerable-trendnet-webcams/ and you can see all the webcams here http://cryptogasm.com/webcams/

It is also worth mentioning that there are search engines that allow hackers as well as anyone to find devices like this on the Internet. http://www.shodanhq.com/

Basic privilege esculation for newbi

When we first gain access to a Linux box there is a good chance that we have gotten a low level account. The next step is usually to escalate our privileges (give us access to more than we have now) up so we can view things like the shadow file. Or maybe there are certain tool we want to run to attack another system and need to be root to run these tools.

I wanted to give some idea of commands we can run to get information that may help us to escalate our privileges and then give really basic example to show what I mean.

[b]Who are you?[/b]
Linux Command: id

[b]Where are you?[/b]
pwd

[b]What version of Linux is running?[/b]
uname -a

[b]What can you do?[/b]
sudo -l

[b]Find all files and directories that are owned by you[/b]
find / -user `whoami` -ls 2> /dev/null

[b]List (running) processes/cronjobs[/b]
ps aux
cat /etc/crontab
crontab -e
ls -R /etc/periodic/

[b]List Listeners/Sockets/Open files in general[/b]
lsof -i
netstat -an

[b]List users & groups[/b]
cat /etc/passwd
cat /etc/groups

[b]Find SUID/SGID binaries[/b]
find / \( -perm -2000 -or -perm -4000 \) -ls 2> /dev/null

[b]Find files that have been accessed/modified/changed recently (e.g. in past 60 Minutes)[/b]
find / -type f -amin 60 -ls 2> /dev/null
find / -type f -mmin 60 -ls 2> /dev/null
find / -type f -cmin 60 -ls 2> /dev/null

[b]List files in /tmp[/b]
ls -al /tmp/

[b]See logfiles in /var/log[/b]
ls -al /var/log

[b]Read other users’ bash history[/b]
cat /home/*/.bash_history

[b]Find files with interesting extensions[/b]
find / -name “*.cfg” -or -name “*.config” -or -name “*.txt” -ls 2> /dev/null

[b]Basic Example of usage:[/b]
We have been given a box to pen testing so we have taken the same process as most pen testing and done information gathering and run nmap scans.

[list]
[li]The only two ports that are open are 80 and 22 [/li]
[li]We use Firefox to see if there any web page.[/li]
[li]We find there is a pretty simple web page that contains some information including email address.[/li]
[li]We then take these email address and produce a user list to use with hydra to brute force the ssh.[/li]
[li]After around 5 mins we get the username as john and passwords as password123.[/li]
[li]We then ssh into the box as the john using his password.[/li]
[li]We now want to try escalate our privileges so we can dump the shadow file and try to crack the other users password.[/li]
[li]We start with our basic privilege list above until we run find / \( -perm -2000 -or -perm -4000 \) -ls 2> /dev/null this tells us that the find command is running at suid[/li]
[li]We can use this to get a root shell by running find . -exec /bin/sh\; this will give us a euid of 0 meaning root.[/li]
[li]We can now use this to cat the /etc/shadow or ant other root task we want to complete on the box.[/li]
[/list]

Please note this very basic example and depending on the system we may not want dump the hashes. I have just used this as its a very simple concept to explain.

Recommended Reading:
https://en.wikipedia.org/wiki/Setuid
https://en.wikipedia.org/wiki/User_identifier
http://g0tmi1k.blogspot.co.uk/2011/08/basic-linux-privilege-escalation.html

Web App for newbi PART 2

XSS (Cross site Scripting)
The first attack I intend to try is XSS. I look for both stored and reflected XSS. The way I like to test for XSS is using the tag I will place this into any form field and if there is a possible XSS it will break the page and turn the HTML into text. This means when you view the page instead of seeing a GUI you see the HTML. There are also lots of other ways to test for XSS. The paces you want to test XSS are post variables, get, cookies variables, and HTTP headers. XSS is mainly used for phishing attacks as well as stealing cookies and a cool tool to check out its beef project. A lot of site setup filtering to prevent this by replacing any dangerous characters, there are ways to get pass these filters depending on how they are setup. There are also lots of ways to bypass filters using encoding or different types of tags like HTML5 tags but this post as well as DOM based XSS attacks.

Example Get XSS with URL encoding:

http://testsite.com/page/sign-in?error=%3Cscript%3Ealert%28%22XSS%22%29%3C/script%3E

Additional Resources:
http://ha.ckers.org/xss.html
https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29
http://beefproject.com/
http://www.thespanner.co.uk/2009/12/06/html5-new-xss-vectors/
http://html5sec.org/

Broken Authentication
A great way to test broken authentication is to find out the URL for something you should only have access to if you were logged in. If you can then go straight to this page without signing in, this indicates broken authentication. Another problem with authentication is if you can guess the session ID you could potentially gain access by guessing or brute forcing the session ID.

Additional Resources:
https://www.owasp.org/index.php/Top_10_2010-A3

SQL Injections
SQL Injections is a massive subject in fact there are dedicated books on it. When testing the application I want to try to get, post, headers and cookies fields. If it’s running MYSQL I tend to just use a; or ‘to break the code, then I can build on this or use SQLMAP to try to exploit the database. This does depend on what database is being used. There are also two types of injection error based and blind, Error based is easy to exploit where blind does take a bit of skill. Error bases is easy to identify as you get some sort of MySQL error relating to the code you have now broken by placing a ‘into the query.

Example:
We have a box that allows us to supply a name we are going to supply a ‘ this will then be inserted into the query below.
Select name from table where name = “$name”;
What we do is break this query by supplying the ‘so it becomes Select name from the table where name = “’”; this should cause an error as this is not valid syntax.

This is a really basic example of SQL injections

Additional Resources:
http://www.unixwiz.net/techtips/sql-injection.html
http://sqlmap.org/
http://www.amazon.co.uk/Injection-Attacks-Defense-Justin-Clarke/dp/1597499633/ref=sr_1_1?ie=UTF8&qid=1344699444&sr=8-1
https://www.owasp.org/index.php/Blind_SQL_Injection
https://www.owasp.org/index.php/SQL_Injection

Storing Password
If we can we want to try to identify how the passwords or credit cards are being stored in the database. The simplest way to do this is if the application has reset password you can use this and see if you get your password back in plain text. If you do get your passwords in plain text this means they are being stored in plain text or they are using an encryption that is easy to reverse. This is more common than you think it should be. In fact a major retailer in the UK has just admitted they are storing passwords in plain text.

Additional Resources:
http://crackstation.net/hashing-security.htm

CLICK JACKING
I think every site I have tested is vulnerable to this attack method. The simplest way to explain this is overlaying a website on top of another website. This happens a lot on Facebook where users think they are clicking like but they really clicking the box behind that is sending a message to all of your friends.

Additional Resources:
https://www.owasp.org/index.php/Clickjacking
http://www.contextis.com/research/tools/clickjacking-tool/
http://javascript.info/tutorial/clickjacking

BRUTE FORCING
I have never really used brute forcing techniques when testing web applications. I always got told that if you need to brute force then you missed something. If I come across a login page I will maybe try a small amount of brute forcing like admin:admin, admin:password and administrator:sitename But no more than say around ten attempts. I also want to see if I get locked out at all, to see if I can’t login after a certain amount of times, as this would be an issue in some situations but most clients accept this as a small risk and don’t care about it.
You can use tools like Burpsuit for brute forcing as well as hydra most browser also have plugins that you can use to try and get access to the application.

Additional Resources:
http://www.thc.org/thc-hydra/
https://addons.mozilla.org/uk/firefox/addon/fireforce/

SSL
When testing a website we want to make sure that all sensitive data is sent using SSL. And it’s using a good chipher so anything above 128 would do. We also want to make sure that the certificate has not expired or there are any other issue with it.

Additional Resources:
http://sourceforge.net/projects/sslscan/

FILE UPLOADS
Sites that allow file uploads sometimes do not use filtering on the file type, this means that you can upload picture.php that contains a PHP backdoor. You can then view this page by going to www.exmaplesite.com/picture.php from here depending on your back door you can run commands on the box like cat /etc/shadow. There are many web backdoors contained in backtrack as well as a great site called pentestmonkey.co.uk. Another trick you can try is to rename the file, if the site has some sort of filtering in place, for example picture.jpg.php this is because most scripts will search the line for a .jpg extension. It will say does this line contact a .jpg and the answer is yes so this would let you upload the file and bypass any filter as if we tried to upload picture.php it would not find the .jpg and not allow us to upload the file.

CSRF Cross site request forgery
This is a bit of a tricky one to explain but let’s see if we can explain it as simple as possible. CSRF is when you are logged into one site for example Amazon and then you are using another website called eveilhcker.com. You click a button on this site that you think will register you to the site and it does but at the same time it makes a request to Amazon on your behalf telling Amazon that you want to buy a book, using the one click buy feature. So what’s happened now is that you’re registered to evilhacker.com but you also brought a book that you are totally unaware of as it’s all happened in the background.

NUESSES
The last stage of the test that I like to run is Nessus this just helps me to identify any other issues that I may have missed. Once this has been done I try and confirm any issues it has found before reporting them to the client.

CUSTOMER RECOMENNDATIONS
When we provide the report to the customer we want to make sure that all issues have a really good explanation on how to fix the problems. We also want to make some general recommendations, like making sure CMS are updated and you force the user to use strong passwords.

Other Attacks
There are lots of other attack vectors for application including session fixation, local file includes, remote file includes and Ajax attack to name a few. As this is not a step by step guide if you want to learn more about these types of attack I would recommend web applications the best book I think you can get is the Web Applications Hacker Hand book. If you really interested in learning more about web apps, a course I really recommend is elearnsecurity and their labs on web applications. The people behind the book above also offer a web course but this cost around $7 per hour.

Another really good resource is the OWASP web application security testing cheat sheet

https://www.owasp.org/index.php/Web_Application_Security_Testing_Cheat_Sheet

Web Apps for newbi PART 1

This guide is written with newbie’s in mind to show them some of the basic concepts when testing web applications and trying to bring them up to speed on testing web applications. It’s not designed to be a one stop solution but a way to explain some of the basic information and give them materials to go and find out more for themselves.

Setup
In order to test web applications there are three tools that I use every single time. I use Firefox as my testing browser with foxy proxy plugin, Burp suit as my proxy and Google chrome for searching browsers, as I don’t want any Google searches affecting what’s in burp suit as the client may wish to see the burp suit logs.

Starting the test
When testing a website I like to spend around 30 minutes just browsing the site as any user would, trying to identify the static pages from the dynamic pages and trying to identify which technologies are being used: PHP, ASP, JavaScript or even Perl. I usually do this process whilst using burp suit. If you have the pro version it will start to identify issues with the site, like XSS, http only cookies and so on. You can also try and force errors from the page; this may give away internal paths or version information. Version information can also usually be found in the headers. There are addition tools you can use like Hoppy or Nikto to help map the web application.

http://labs.portcullis.co.uk/application/hoppy/
http://cirt.net/nikto2/

Once I have good idea about the site I start by looking for default pages. For example if it’s a contents management site like Word press, Drupal or any other popular site, I tend to download the files and quickly set it up in a Lamp, WAMP or MAMP environment this way I can see what the default settings are as well as how the files are structured. This gives me a good idea of where to look in the application I am testing. Can I access an admin page? Or is there a backup of the default admin login detail? This all needs to be investigated to see what you can and cannot access and help map the application.

If the application is not using a CMS then I start by trying to access common files like robots.txt and then try to view any pages listed in that. If there are not any robots files, I then try default pages like admin.php, account.php so on. At this point you could use the spider feature in burp suit to try and get a much better idea of the application or use Dirbuster to try brute force on any hidden directories.

Once this has all been done you should have a really good understanding of the application. What it does, how it was build and maybe even some small issues to report like internal path, information disclosure etc. Having a good idea of how the application was built, this is an essential to understand as if you trying to exploit an SQL injection. If you know the developers have followed a certain naming pattern, you can take an educated guess they have done the same in their database this will make exploiting it easier if you find SQL injections on the site.

Starting the attack
We have a really good understanding of the site and the inner workings and so it’s time to start finding issues with the site.

Login Page
If the website has a login page then I first create an account, during this process I see if I can use a weak password like the character ‘A’. If I can then this is an issue and would report it to the client as they should be using at least 9-20 characters with a mixture of upper, lower, numbers and symbols for the password. After I have registered with the site I attempt to login to the site looking for any errors messages. I want to make sure that the errors are not given any information away like “This passwords does not match the username” As an attacker this then tells me that I have a valid username so I can enumerate user.

Injection
This is where you can inject into the page; you can find this with an error message, which is the most common place, just like the example below. The reason this is an issue is it lets anyone write anything on your site so it’s a great tool to use with social engineer. We could write a message encode it then send it to a customer, they would then ring the number and we could try to get account information from them.

Example Error injection
http://testsite.com/page/sign-in?error=Please call tech support 0800 000 000

Cracking Passwords

Cracking Password with John

We have all cracked some passwords with John before, but I just want to go over a methology I use to crack passwords. I am going to use the password dump for this demo just to show how it works.

The first thing you may want to do is make sure you are running John the jumbo pack. Once this has been installed you may want to install the linkedin plugin which can be found here. john patches

Applying the patch is pretty straight forward just patch -p1 < ../location of patch. Once this has been done you will need to do a clean build of John.

The first thing I like to do when getting a password dump or some hashes is to try and think who the user is, what Country they are in and where are they based in that Country. Then I think about sports teams in that area, famous dates and people in that area and also any special words they may say or spell in a different way; this all goes into a wordlist.

I tend to start just by running the wordlist to see how many hits I can get, once I have got all the hits from them I then run an English dictionary wordlist as well as any other Country wordlist then I will run the rockyou.txt password list. This is a really good list which can be download from here: skullsecurity

This should really start getting you a lot of hits but it may take a bit of time to finish.

The next thing to try is using rules with John the Ripper, this allows you to supply a wordlist and add to that wordlist. For example you may have a year rule that will go through the wordlist; adding a year to the end. The best rules are on the kore logic website Korelogic again these are pretty straight forward. To apply just download them
cat rules.txt >> john.conf This will appened the rules to the john.conf file.

On the website it also gives you a list of the rules and what they do so you have:

KoreLogicRulesAppendNumbers_and_Specials_Simple:
KoreLogicRulesPrependYears:
KoreLogicRulesAppend4Num:
KoreLogicRulesAppendJustNumbers:

So on……

In order to use the rule you just supply the rules options as the example below shows:

./john -w:Lastnames.dic –format:nt –rules:KoreLogicRulesAdd2010Everywhere pwdump.txt

Again this will take some time but should present you even more results.

If that fails to get all the passwords I then try another trick you need to download a file from korelogic website Korelogic Just scroll down to where it says John the Ripper and download the rockyou.chr this file was based on statistics from a large database dump recently so it is more up to date on how passwords are selected and user behaviour. As it stands John uses the all.chr but this is a pretty old file and based on passwords and user behaviour from around 2009.

With the rockyou.chr you don’t need to supply a wordlist so it’s just a case of

./john -i:rockyou.chr pwdump.txt

Geo Tagging

What is Geotagging?

“Geotagging (also written as GeoTagging) is the process of adding geographical identification metadata to various media such as a geotagged photograph or video, websites, SMS messages, QR Codes[1] or RSS feeds and is a form of geospatial metadata. This data usually consists of latitude and longitude coordinates, though they can also include altitude, bearing, distance, accuracy data, and place names.”

So in a nutshell this mean if you using a modern device that uses GPS your latitude and longitude coordinates could be stored in the picture that is taken.

From a security point of view this means if you upload a picture to Twitter from your phone, it could be possible for someone to find the location where that picture was taken, this was used recently to track down an anonymous hacker who posted a picture of his girlfriend online the FBI used the images latitude and longitude coordinates to locate where the picture was taken and a few days later he was arrested.

It just goes to show you should be careful when using smart devices and uploading images.

How to:
In order to get the information from the image here a quick and dirty PHP script:

$info = exif_read_data('picture.jpg');
var_dump($info);
?>

link to article
Link to article

Making a name for youself

One of the best ways to get noticed in this industry is to make a name for yourself and here are some tips on how to do this.

1) Attend conferences and network this is really easy to do depending on where you are in the World. There are loads of conferences in the USA and Europe, some are free and some require you to purchase a ticket. The great thing about conferences is that it’s full of security folks who love nothing more than talking about … that’s right SECURITY!!

2) Submit a talk to a conference. This is a great way to make a name for yourself, if you know a subject or find a bug in some software doing a talk at a conference about it really heightens your profile.

3) Write a tool that helps everyone in infosec it can be a simple tool or a really complex tool depending on how much time you have. The more useful the tool is the more your make a name for yourself. We are all lazy and love things that help make our lives and job easier so producing a tool that does this gets the thumbs up.

4) De-ice disks most of you should know about the De-Ice project for those of you who don’t.. shame on you. The De-Ice disk helps others like you train and learn cool new tricks, this is a great way to make some cool challenges and most people in security have used them or heard of them.

5) Last but not least, give back. This is the most important tip. If you achieve one of the above then you are giving back and you get a thumbs up. We would not have cool tools like metasploit and nmap to name some if people did not give up their time and effort to give back to everyone in security.