02-19-2013 07:48 PM - edited 03-18-2019 12:37 AM
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
02-19-2013 10:06 PM
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?
02-20-2013 02:20 PM
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
02-19-2013 10:56 PM
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
02-19-2013 11:13 PM
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.
Somebody needs to remove that tool from the VCS and check the security indeed....
02-20-2013 12:42 AM
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.
.
02-20-2013 02:26 AM
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.
02-20-2013 02:29 AM
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
02-20-2013 04:29 PM
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
02-21-2013 11:27 AM
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.
02-21-2013 12:06 PM
Recommendation:
- Have VCSE in DMZ
- Use allow list to block illegitimate registration
- Check credential on default subzone
- Review and fine tune your search rules
11-15-2013 09:39 AM
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?
11-15-2013 01:53 PM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide