cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3812
Views
5
Helpful
12
Replies

VCS SIP abuse reported

rfrome
Level 1
Level 1

I have a customer that was contacted by a third party with a complain about their VCS Expressway.

Below is what the third party provided my customer. (I've masked the customers IP address 205.x.x.x)

Has anyone seen anything such as this? I do not understand how a VCS would be transmitting out in this fashion.

Note: Local timezone is +0100 (CET)

Feb 15 02:01:41 nl-gw snort[817]: [1:2008578:6] ET SCAN Sipvicious Scan [Classification: Attempted Information Leak] [Priority: 2] {UDP} 205.x.x.x:5061 -> 62.97.226.34:5060

Feb 15 02:01:41 nl-gw snort[817]: [1:2011716:4] ET SCAN Sipvicious User-Agent Detected (friendly-scanner) [Classification: Attempted Information Leak] [Priority: 2] {UDP} 205.x.x.x:5061 -> 62.97.226.34:5060

thx,

rf

12 Replies 12

Danny De Ridder
Cisco Employee
Cisco Employee

Hello,

I have seen endpoints being under attack of this Sipvicious "tool". SIPVicious suite is a set of tools that can be used to audit SIP based VoIP systems.

http://code.google.com/p/sipvicious/

These are python scripts. Did somebody install this on the VCS?

Can you check the processes running on the VCS using root account?

E.g. netstat -apn | grep snort

I assume snort [817] is the process with PID 817.

I am not a VCS expert, but if VCS runs linux, can I have root access to your device to check/look for this port scanning software?

Running this: netstat -apn | grep snort

does not return any results, so I assume this is not on this VCSe.

The defualt subzone does allow unauthenticated registrations, (hey, I didn't deploy it) but I only see devices belonging to this customer registered to the VCSe.

Thanks for the input everybody.

rf

gubadman
Level 3
Level 3

That looks like snort is running on the third parties network and detected SIP vicious traffic from 205.x.x.x

I would guess the customer hasn't secured their VCS Expressway very well - firewalls, non-standard, complex passwords etc. for root and user accounts, and someone has got in and installed the software on it.

Sent from Cisco Technical Support iPhone App

Hello,

thanks for clarifying. So this snort tool us running on the attacked system, NOT on the VCS. The snort tool detected attack from the VCS. So somebody started Sipvicious python scripts on the VCS.

http://www.snort.org/

Somebody needs to remove that tool from the VCS and check the security indeed....

ahmashar
Level 4
Level 4

it's more like VCSE is hacked and software installed on it, if the customer's IP address 205.x.x.x sending out packet to 62.97.226.34. Check the processes on VCSE for snort application.

As mentioned earlier the customer should secure its VCSE before putting out on the internet.

.

Ahmad,

Snort is intrusion detection software, it is most likely that this is running on the 3rd parties incoming gateway, and detected the bad traffic from the customers VCS.

awinter2
Level 7
Level 7

These Snort log entries do not necessarily have to mean that the VCS has been "hacked".

Since the VCS is both a SIP proxy and registrar, it could simply mean that this VCS is configured to allow unauthenticated registrations (Meaning that the Default Subzone has an authentication configuration of 'Do not check credentials' or 'Treat as authenticated'), and that the SIPVicious script has registered an AOR onto the VCS and is attempting to dial out on for instance PSTN through this SIP registration.

I have seen exactly this occur before in customer deployments, and in those cases the VCS had not been hacked/cracked in any way, but was simply not configured to require authentication for SIP registrations, meaning that anyone knowing the VCS IP address could freely register onto this VCS-E, and thus place outbound SIP call attempts via that VCS-E.

- Andreas

Martin Koch
VIP Alumni
VIP Alumni

I remember that there was an other post mentioning the same,  especially the combination 5061 as source and 5060 as the destination.

What would surprise me a bit is the combination of 5061 and 5060 and the usage of UDP,

at least that could point out that some unwanted process might be run on the VCS, as this

should not be a proper port for the vcs to use.

It can be mutliple things, it can be a hack of the VCS where the sipvicious scripts are run on the VCS,

but as its UDP it can also be a spoofed address from somewhere else.

And like Andreas also said, if the VCS is not configured correctly it can also be missused as an

open sip proxy / h323-bk/gk

What I would recomend is to try to figure out what happened, it might be easier actually if

its a problem and if it still exists so you can capture it with a network monitor port or do some

forensics on the VCS.

Please remember to rate helpful responses and identify

A quick check from root on VCS could be :

~ # find / -name *.py -print | xargs grep -i sipvicious                          

~ # find / -name sv*.py -print 

One can indeed re-use the VCS address to spoof the attack comes from the VCS.

ahmashar
Level 4
Level 4

Recommendation:

- Have VCSE in DMZ

- Use allow list to block illegitimate registration

- Check credential on default subzone

- Review and fine tune your search rules

Ahmad,

I'm new to video and had a few questions as I'm having this issue too.

You say to have an allow lise to block illegimate registrations, is this under

vcs -> registration -> allow list?

equinox198 wrote:

is this under

vcs -> registration -> allow list?

Yes, either use it as "allow", where you enter the details of the particular systems you wish to allow to register, or use "deny" where you enter the addresses of the particular systems you want to block.

/jens

Please rate replies and mark question(s) as "answered" if applicable.

Please rate replies and mark question(s) as "answered" if applicable.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: