Just started blogging…actually getting pretty late into the blogging culture! Studying and doing projects to complete graduation at USC. My homepage is at http://www-scf.usc.edu/~swarup/.

One more in the list of technical posts! Yesterday was a day of 17 hrs in the lab (phew 🙂
So we were capturing packets but the packit tool did not randomize the source IPs enough so we were getting decent signatures for TCP traffic but not for ICMP! So looking at the signature generation I found that the checksum was also being used to get the hash value. But, when I stopped using the checksum values for generation of hash the signatures started coming properly. Antoine, somehow, thought that the IP addresses were affecting the has values that we got. But looking deeply into the code we saw that it was not the case. The conclusion (which is really surprising) is that packit was generating similar packets quite a few packets and that too from the same source IP (but they really should have been randomized!)…I don’t know whether this conclusion is correct??? May be some packit developers would be able to help me on this!
So now the challenge becomes to send those ICMP signatures across…but icmp_send() method requires skbuff structure…I looked at the net/ipv4/ipip.c file for the usage of icmp_send() methods but it is still not clear to me how it should be used!

-Rajat
Rajat’s Homepage

I’ll be attending the Shmoocon in Washington, DC from Feb 6th-8th. Hope to see all you h4X0rs out there!

Server-Side Request Forgery is a security issue in applications where an attacker is able to get a server to send some type of a request (these days mostly HTTP/s requests) that the server should not be able to send. This issue is the classic abuse of trust vulnerability – the server tends to sit in a “trusted” environment (e.g., DMZ, your cloud VPC, etc.) and the users of the application sit outside the trust boundary (e.g., mobile devices, cafe, home, corporate environments, API clients within and outside cloud).

A brief history
In this blog post though, I won’t be talking about all the fancy new things that have had SSRF issues – you can likely find a few hundreds of those anyway! I am going to be talking about a brief history of this issue and what happened before we gave this issue a “name” – SSRF. The earliest references to the name “SSRF” appear to come from a talk done in BlackHat US 2012, and wayback machine tells me that the CWE-918 page was authored sometime around 2013. If you look closely at the CWE-918 page though, you will find that there were old CVEs dating back to 2002, and 2004. There was a Shmoocon talk about it in 2008 too but the term SSRF was not established until 2012.

The Issue
I was working on a penetration test for a financial services firm in 2010 of a popular load balancer that offered a GTM (Global traffic manager) solution and that allowed folks to login and obtain restricted execution environments wherefrom certain applications could be exposed and that would allow remote workers or untrusted entities who you only want to expose certain applications could use. The issue was in a POST request post login and IIRC even pre-login (though my details on this are fuzzy). This might be circa 2010 timeframe and to my knowledge the issue was not issued a CVE and wasn’t associated with Knowledge base article – I may not know 100%. The guidance from the vendor was simple – update the software and move on. The issue was this – an authenticated or an unauthenticated user would send an HTTP POST request to a page with a base64 encoded parameter that included a hostname which would trigger a DNS request on the back end of the GTM site. The time it took for the response to get back would indicate whether the domain was legitimate or not. So I used the a popular dictionary and enumerate all the hostnames from that directory that were legitimate and the ones that were not sitting outside on the Internet and mapping the hosts on the internal network.

The backstory
What the vendor of the GTM software did not know was how critical this application was to the business of the customer. They seemed to be dragging their feet without updates and meanwhile the customer – a financial institution with lots at stake could not go live. The pressure mounted on the IT staff to fix the issue and the vendor while being responsive was unable to give a firm date quickly – remember this was 13-14 years ago prior to bug bounties and responsible disclosures still were quite clunky! And the customer was also advising me to push the software vendor so we could discuss. Thankfully, on the vendor side, there was a solid security person who understood the issue immediately and its impact and advised the software teams to do what was right. They made the process post authentication and they also added tokens, limits and constant time responses to fix the issue.

Fast forward
Today, obviously things are a lot better. And I wrote this blog post so the old me can look back and point to this in a meaningful way without forgetting the old experiences among the new.

Yesterday was a fantastic day trying to get the IP data field to be pointed to by in the skbuff structure. The documentation in the files did not help make things clearer.
The situation was where I was supposed to use the
unsigned char* data field in the skbuff structure to point to the IP data starting point.
Tried a lot of pointer math and the following finally worked:
IP Data pointer location:

unsigned char * ptr = sb->data +
sb->nh.iph->ihl*4;
int byte_size = ntohs(sb->nh.iph->tot_len) –
sb->nh.iph->ihl*4;

In fact, Vinay Reddy (vinayvinay@gmail.com) suggested something which I think was even better than the stuff that was working for me. He said the pointer value should be:

unsigned char * ptr = sb->nh.iph->raw + sb->nh.iph->ihl*4;

I think this actually grabs the gist of what I exactly want to do.
I *really* want to point with respect to the IP Header. I do not really care about where sb->data really points to so I guess Vinay’s method is much better. Haven’t implemented it so I really don’t know but sounds the most logical!

– Rajat
http://www-scf.usc.edu/~swarup/

SSH is an excellent piece of software which can help you do a lot of things such as have encrypted shells etc. But what makes SSH incredibly flexible is having tunnels.

A typical ssh tunnel works from the client to the ssh server and it forwards a local port on the client to the server seamlessly.

client ----> ssh_conn ----> ssh_server
client --> tunneled_port --> ssh_server

ssh -L 10000:localhost:10000 username@ssh_server

This connection creates a tunneled port on client:10000 i.e., anything sent to this port appears as if it’s automatically sent to ssh_server on port 10000. The localhost here is confusing, but think of it as….”what is localhost for ssh_server?”. It would be the ssh_server itself, right?
If you do a netstat on the client, you see a listener on the port 10000/tcp.

Now comes the more interesting reverse tunnel. The reverse tunnel is different in that, you have a tunnel being initiated by the client that says to the ssh server, “Hey, I’m initiating this connection that will allow you to automatically access a port on *me* after *I* initiate the connection?” (confused!!?!)

client ---> ssh_connection ---> server  ---+
                                           |
client <-- tunneled_port  <----- server ---+

ssh -NR 10000:localhost:10000 user@ssh_server

Here the meaning of localhost is slightly different, though.  The “localhost” means what is localhost for the client (and not on the server as in the previous case)!   So what you’re saying is, “Hey SSH server, I’m initiating this connection to you but if you connect to your port 10000 you will get a tunnel to *my* port 10000.”  If you do a netstat on the server you see a listener on port 10000. Isn’t it great that you can make the server listen to a port which acts as a tunnel to you…so anyone on the server can seamlessly connect to you even though technically you were the client!

An interesting incident happened this past week to a friend – he had his identity stolen. More specifically, someone got a hold of his social security number (SSN), his date of birth (apparently) and his address. What the scammers or their “mules” (a term used to describe criminals who act on behalf of the actual criminal at their behest) did was that they went to the bank and requested to wire a huge sum of money to an account. The neat trick they played was before actually going to the bank they called the Verizon helpdesk and suspended my friend’s phone service. When they reached the bank and showed the bank agent the ID (some sort of a non-standard / fake ID) and gave the SSN to the bank agent, he/she grew suspicious and tried to contact my friend. However, due to Verizon suspending his phone service, the bank agent couldn’t get a hold of my friend. Luckily, the bank agent also sent my friend an email to which he responded promptly. The culprits were arrested and the investigation is still on.
What was quite interesting was, the modus operandi where the criminals know that banks rely on calling the customers if they suspect fraud and they had this covered. Quite intelligent.
So, you know what you need to do if your phone suddenly stops working – check if ID thieves have had a run on you, change all your passwords including email, change your credit card accounts and bank accounts and PINs and place a hold on your credit history with the credit reporting agencies such as Experian, Equifax and TransUnion.