Black screen after logging in via remote desktop

I had an annoying issue a few minutes ago - I've initiated a remote desktop session from my home PC to a windows 7 PC at work.
I was presented with the usual login screen. however, after passing the login phase successfully, the only thing displayed on the remote desktop is a black screen.
I've tried to reopen the remote desktop client, change the RDP screen resolution, reboot the client PC, but the result was always the same - black screen.

Eventually what worked for me was to press the CTRL-ALT-END key combination and click on the "Start Task Manager" option. In this case, that was sufficient to eliminate the black screen issue. In other cases it might be required to terminate some running processes using the remote task manager.

Devil in human form

We have enslaved the rest of the animal creation, and have treated our distant cousins in fur and feathers so badly that beyond doubt, if they were able to formulate a religion, they would depict the Devil in human form.

William Ralph Inge (6 June 1860 – 26 February 1954) was an English author, Anglican priest, professor of divinity at Cambridge, and Dean of St Paul's Cathedral

Tao Te Ching and the art of counter-globalisation

Tao Te Ching, a classic Chinese text attributed to Laozi (老子) was written some 2,500 years ago. 

If a country is governed wisely,
its inhabitants will be content.
They enjoy the labor of their hands
and don't waste time inventing
labor-saving machines.
Since they dearly love their homes,
they aren't interested in travel.
There may be a few wagons and boats,
but these don't go anywhere.
There may be an arsenal of weapons,
but nobody ever uses them.
People enjoy their food,
take pleasure in being with their families,
spend weekends working in their gardens,
delight in the doings of the neighborhood.
And even though the next country is so close
that people can hear its roosters crowing and its dogs barking,
they are content to die of old age
without ever having gone to see it. 

 Quote from chapter 80, no need to add a single word.

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:

for i in 0 1 2 3 4; do for j in 0 1 2 3 4; do lcdwarn -c "${i}" "${j}"; done; done

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

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.

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