This can be achieved easily by entering the following statement over an SSH session:
for i in 0 1 2 3 4; do for j in 0 1 2 3 4; do lcdwarn -c
"${i}" "${j}"; done; done
Tuesday, October 18, 2011
Clear F5 Bigip LCD warning from remote
Sometimes it may be desirable to clear the warning that appear on the F5 LCD panel from remote.
This can be achieved easily by entering the following statement over an SSH session:
This can be achieved easily by entering the following statement over an SSH session:
Monday, July 18, 2011
CUCM SIP Transparency and Normalization Lua scripting
Cisco Unified CM is a Business to Business User Application (B2BUA). Therefore, any SIP to SIP call consists of 2 SIP dialogs. It is often useful to pass information from one dialog to the other during the life of the dialogs. This includes call setup, mid call, and end of call messaging. Using the pass through object described, it is possible to trigger transparent pass through of information on from one SIP dialog (representing 1 of the call legs) to the other.
The snippet below is an example of a script I used in order to transparently pass through an arbitrary header ("Subject" in this case) in an INVITE message from the inbound call to the outbound call leg.
B = {}
function B.inbound_INVITE(msg)
local pt = msg:getPassThrough()
local Subject = msg:getHeader("Subject")
if pt and Subject
then
pt:addHeader("X-Subject", Subject)
end
end
function B.outbound_INVITE(msg)
local Subject = msg:getHeader("X-Subject")
if Subject
then
msg:addHeader("Subject", Subject)
msg:removeHeader("X-Subject")
end
end
return B
The snippet below is an example of a script I used in order to transparently pass through an arbitrary header ("Subject" in this case) in an INVITE message from the inbound call to the outbound call leg.
B = {}
function B.inbound_INVITE(msg)
local pt = msg:getPassThrough()
local Subject = msg:getHeader("Subject")
if pt and Subject
then
pt:addHeader("X-Subject", Subject)
end
end
function B.outbound_INVITE(msg)
local Subject = msg:getHeader("X-Subject")
if Subject
then
msg:addHeader("Subject", Subject)
msg:removeHeader("X-Subject")
end
end
return B
Sunday, April 10, 2011
Toll fraud with CDR field separator injection - part I
Overview
In case you ever worked with or for a service provider you probably know that CDR (Call Detail record) integrity is one of the most important issues.
The reason why CDR is so important is because it is the most common way for a provider to meter and record service consumption.
Normally, in post-paid billing scheme, when a subscriber places a call, the provider's switch generates a call record.
Most often the CDR file is a delimited flat file where each record in the file describes a single call (or call leg) and includes details such as - was the called answered or not, how much time did the call last, who was the calling party, what was the destination and lots of additional information regarding the call.
Periodically, the provider's billing system (directly or via a mediation system) parses the CDRs resulting in the charges associated with each record/call .
It is not hard to guess that if a call record for a specific call is missing or cannot be properly parsed by the billing system - the consuming entity (subscriber or peering partner) can avoid the charges associated with the call and the provider serving the call potentially loses revenue.
As previously mentioned, the CDR holds many details about the call. some of these details are actually taken from the signaling messages used throughout the call.
this is where it gets interesting - signaling messages may originate from possibly untrusted entities such as peering partner switches and subscribers. so it leads to the fact that potentially untrusted entities can affect the content of the most important information of a for-profit provider - the CDR.
Back in the old PSTN days this was less of a worry, ISDN Q.931 and SS7 ISUP were inherently limited in the information that could be injected into signaling messages. protocols were less extensible and specs were clearer and didn't update so often.
Going on to SIP, things are a bit easier for the malicious user - many fields in signaling messages can hold alphanumeric values, protocol specs tend to change frequently and when it comes to header field format validation in SIP stacks and application, well it nothing to write home about.
In part II I'll provide intimate details of a remote vulnerability I've discovered in known class 4 switch that allows a remote SIP peer to place international calls while avoiding termination charges by CDR corruption.
Note to blackhats and fraudsters - the vendor had been notified of this specific vulnerability, so don't hold your breath.
In case you ever worked with or for a service provider you probably know that CDR (Call Detail record) integrity is one of the most important issues.
The reason why CDR is so important is because it is the most common way for a provider to meter and record service consumption.
Normally, in post-paid billing scheme, when a subscriber places a call, the provider's switch generates a call record.
Most often the CDR file is a delimited flat file where each record in the file describes a single call (or call leg) and includes details such as - was the called answered or not, how much time did the call last, who was the calling party, what was the destination and lots of additional information regarding the call.
Periodically, the provider's billing system (directly or via a mediation system) parses the CDRs resulting in the charges associated with each record/call .
It is not hard to guess that if a call record for a specific call is missing or cannot be properly parsed by the billing system - the consuming entity (subscriber or peering partner) can avoid the charges associated with the call and the provider serving the call potentially loses revenue.
As previously mentioned, the CDR holds many details about the call. some of these details are actually taken from the signaling messages used throughout the call.
this is where it gets interesting - signaling messages may originate from possibly untrusted entities such as peering partner switches and subscribers. so it leads to the fact that potentially untrusted entities can affect the content of the most important information of a for-profit provider - the CDR.
Back in the old PSTN days this was less of a worry, ISDN Q.931 and SS7 ISUP were inherently limited in the information that could be injected into signaling messages. protocols were less extensible and specs were clearer and didn't update so often.
Going on to SIP, things are a bit easier for the malicious user - many fields in signaling messages can hold alphanumeric values, protocol specs tend to change frequently and when it comes to header field format validation in SIP stacks and application, well it nothing to write home about.
In part II I'll provide intimate details of a remote vulnerability I've discovered in known class 4 switch that allows a remote SIP peer to place international calls while avoiding termination charges by CDR corruption.
Note to blackhats and fraudsters - the vendor had been notified of this specific vulnerability, so don't hold your breath.
Saturday, January 29, 2011
Egypt unrest - network point of view
http://stat.ripe.net/egypt/
http://bgpmon.net/blog/?p=450
http://extraexploit.blogspot.com/2011/01/egypt-telecom-as-isolation-bgplay-show.html
http://asert.arbornetworks.com/2011/01/egypt-loses-the-internet/
http://www.renesys.com/blog/2011/01/egypt-leaves-the-internet.shtml
Subscribe to:
Posts (Atom)