Jan 19 2012

Cellcom login information revealed

Cellcom is a large cellular provider operating in Israel, but as it seems not a very secured one.

Today I went to one of Cellcom’s stores in order to upgrade myself to a brand new iPhone 4Gs (16GB). At first, the guy behind the counter told me that the price for the device is 3207.2 NIS before VAT (I’m a “business customer”). When I told him I wanted to pay using credit card he replied that I will need to pay 400 NIS more! The original price is only available for cash customers (I am really considering coming there tomorrow with a bag full of coins and watch them count…)

Anyway, while arguing, I wanted to check their website and see information about devices. I’ve launched Safari on my current iPhone, and surfed to “www.cellcom.co.il”. As expected, they have a completely different version for the website when you are surfing from a mobile device. I couldn’t find any information about devices nor prices, But I did find something else.

When I first opened their website I saw the following screen:

Cellcom Login Details

Translation: Your username is: … Your password is: …

Needless to say, that the information wasn’t censored on my phone. And just below this information box, was a login box asking me for username and password (yes, the same information they just gave me) inorder to login to my Cellcom profile.

It’s bad enough that they are saving my password in plain text, but inorder to make it even worse, they are displaying it to everyone who can get a hold on my phone.

When I got home and logged-in to Cellcom’s website from my PC, I saw that I can display my last invoice and even install/remove features on my line such as voice-mail, conference call, etc. There is even a phonebook on site, but in my case it was empty (I think it has something to do with a phonebook-backup-service Cellcom is offering, But I’m not sure).

So, If you are a Cellcom owner, And got a smartphone, just go to www.cellcom.co.il and see for yourself. And I don’t recommend you to give your phone to anyone who you don’t completely trust with access to your Cellcom’s login information.

No Cellcom, that doesn’t count as security. In fact, It’s the complete opposite!


Dec 2 2011

Cracking “Rav-Kav” (Part I)

Yesterday at the university, I’ve got my brand new “Rav-Kav” (רב-קו) card. I was really happy when I discovered that mine was one of those “smart card with the golden chip on it”. Because I’ve got a software on my computer at home, that uses smart-card as a dongle, therefore, I’ve got a smart-card reader back at home.

Rav-Kav card

My first task, was to find out how to communicate with the smart-card. A quick google search and I’ve found the wonderful python module pyscard which allows me to send and receive APDU commands to/from the smart card. My second task was to read a bit about smart cards, and the commands they use. Again, google came up handy, and I’ve found the following site which describing more-or-less every command and response you are likely to get from the little shiny card.

The first thing you need to understand, A smart-card is not a flash drive! A smart-card is a microprocessor, It has it’s own operating system, and it communicates with the device using it (my computer for example) using the T=0 protocol. Meaning: You can’t read and write whatever you want into it.

For those of you who reads this article only to get “free rides”: No, I don’t believe I’ll be able to add “free rides” to my “Rav-Kav” card, because those things are usually very protected (and even if I could, it will be illegal to use it and sharing the information), but it’s quite interesting to check what kind of information is stored in this little piece.

When I plugged the card and connected to it, the ATR was: “3B 6F 00 00 80 5A 0A 07 06 20 04 2C 02 63 EE FF 82 90 00”. But I’m not sure if that means anything….

The first thing I tried was to map all the command classes available for this card.
I’ve scanned the classes simply by trying a random command in all the possible classes (256 possibilities), and ignored all the classes that returned “0x6e – Class not supported“. I’ve found out that the only available classes are 0x80, 0x94. And that all the interesting commands shown on chapter 6 can be found on the 0x94 class.

The next thing I did was to “brute force” the file-system under the master-file using the SELECT command. And I got the following list:

0x0002
0x0003
0x2000
0x2001
0x2004
0x2010
0x2020
0x202a
0x202b
0x202c
0x202d
0x2030
0x2040
0x2050
0x2069
0x206a
0x20f0
0x2100
0x2101
0x2104
0x2110
0x2120
0x2140
0x2150
0x2169
0x21f0
0x2f10
0x3f04
0xfeff

I’m not sure yet which one of those is an EF (normal file) and which one if a DF (a directory). But I’ll find those out next time. Stay tuned.


Oct 20 2011

Researching UnrealIRCd

When I was a teenager I remember using IRC a lot. I remember a short period of time that I wanted to have my own IRC server, So I looked for an IRCd and found UnrealIRCd. I’ve quickly installed it on my computer, and start sharing my brand new IRC server with friends (So what if I only had 56k connection?).

Today, I’m a bit older, And I’m no longer interested in owning the greatest IRC server of all times (It could be nice though). But still, I’ve decided to grab a look on that old open source project, security wise.

After a quick look, I’ve found a local stack overflow vulnerability while parsing the configuration file.

The bug

Apparently, when UnrealIRCd writes configuration error to the log file, it doesn’t check the length of the message. The vulnerable function is:

void config_error(char *format, ...)
{
	va_list		ap;
	char		buffer[1024];
	char		*ptr;

	va_start(ap, format);
	vsprintf(buffer, format, ap);
	va_end(ap);
	if ((ptr = strchr(buffer, '\n')) != NULL)
		*ptr = '\0';
	if (!loop.ircd_booted)
#ifndef _WIN32
		fprintf(stderr, "[error] %s\n", buffer);
#else
		win_log("[error] %s", buffer);
#endif
	else
		ircd_log(LOG_ERROR, "config error: %s", buffer);
	sendto_realops("error: %s", buffer);
	/* We cannot live with this */
	config_error_flag = 1;
}

As you can see in line 8, the unsafe function vsprintf is being called with an output buffer of 1024 bytes. And we all know what will happen if the output message will be long longer than 1024 bytes… STACK OVERFLOW!

But can we control the log message? Yes we can.

How to exploit?

At first, we need to find a message in which we can control the whole message / part of the message.

After installing and running of UnrealIRCd, I’ve found out that the example configuration file throws several errors (I’ve downloaded the version with no SSL, and the example configuration uses SSL). So I got a nice message telling me one of the links (indicating the link name) got an error. I’ve decided to remove the SSL option from the link information and add a new option named “DiGMi”. Meaning, now in my configuration I’ve got a section which looks like this:

link            DiGMi.org
{
	username	*;
	hostname 	1.2.3.4;
	bind-ip 	*;
	port 		7029;
	hub             *;
	password-connect "LiNk";
	password-receive "LiNk";
	class           servers;
		options {
			/* Note: You should not use autoconnect when linking services */
			autoconnect;
			DiGMi;
			zip;
		};
};

After running the server, I got the following error message:

[error] unrealircd.conf:324: Unknown link option 'DiGMi'

So, we can even control the message, lets try to overflow!

Instead of DiGMi I’ve written a lot of “A”s (like every good hacker does) and started debugging the server using OllyDbg. Sadly, I’ve found out that the server was compiled with security cookies so such a simple method for exploitation won’t work.

Overriding the SEH

Because I couldn’t just change the return address on the stack, I had to find another way to set the EIP register. A good way to do so in windows is overriding the SEH (Structured Exception Handler).

The SEH is located on the stack and it’s functionality is to tell the OS which code to run in case of exception. I’ve scrolled all the way down in the stack view in OllyDbg and found the SEH just sitting there, few thousands of bytes away, waiting to be override.

Can we override so much? – Why not? What’s limiting us?

So I’ve again added a lot of “A”s to my newly made option, and after 2266 of them I was just about to override the exception handler address, so instead of “A”s I switched to “B”s (just to mark the location.

But its not enough. We only changed the exception handler, but if no exception is thrown it won’t do us any good. so we need to throw an exception, how can we do that?

That’s right, Just keep on overriding until we fill the whole stack. And so I did. After overriding enough bytes OllyDbg finally gave me the wonderful message telling me:Look at that EIP...

(Remember thos 4 “B”s?)

Meaning now I can control EIP…

At that point I’ve stopped working on it because the next steps are a bit boring, and it should be easy enough to inject my own code to the software. Because it’s not a remote exploitation, it is just not interesting enough to continue looking into it.