I hate to keep beating a dead horse here, but I want to get my point across concerning wireless networking. Sans has now issued a paper about the basic insecurities of wireless. Check it out and at least use this paper as input for threat modeling your networks and wireless applications.
.NET Code Access Security – The fast version
I spoke at this months GSP Developers Guild meeting as the “short presenter”. We typically have two presentations each month — one is a short presentation and one is a long presentation. I had to cut my Code Camp slides in half, but I managed to only overrun a 30 minute presentation by say, 15 minutes 🙂 Glen Gordon was our “long presenter” today. He gave a great presentation on ASP.NET Mobile Controls. I knew the presentation material, but its always great to see people respond to the technology like they did. Glen is a beast — he gave a 4 hour long presentation at the Greenville MSDN event today too. From 1pm to 5pm today he discussed Web Services, SQL Server 2005 with end point registration, Infopath consumption of the web services and end points, ClickOnce deployment and more. He then took a quick drive over to the guild meeting to give another hour-long talk on mobile web development. It was a geek decathalon!
Thanks for the great day guys. I had a blast giving my presentation again. And I really enjoyed watching your presentations again Glen.
Friends Don’t Let Friends Use Wireless
It will never cease to amaze me how much people implicitly trust wireless connections. I see businesses from coffee shops to book stores offering free wireless connectivity in the hopes that people will stick around and spend money. This is a great idea for businesses, and the concept does work. However, I often wonder why you would so willingly trust this free service.
Imagine this scenario. You walk into your favorite Barnes & Noble book store to sip some coffee, eat some eclairs, and surf a bit. While surfing, you decide you want to check your hotmail account. You type in your usual “http://www.hotmail.com” as you always do. You then enter your username and password as you always do. “Login Failed? Huh?” You type it again “Username: eye_me_leet | password: h4x0r2u”… ” and just as quickly as the first response occurs, the same response comes back “Login Failed”. Thinking this may be a cache problem or just a bug with IE, you close your browser or perhaps reboot all together. You type in the site again aych-tee-tee-pee collon-slash-slash dub-dub-dub-dot-hotmail-dot-com [Enter]. But to your horror, as the pixels on the page change, they don’t turn to the standard looking hotmail screen, instead, these pixels spell words only a truly 1334 r00t *** would put on a site — “U’V b33n pwnt !”. What happened, other than some really bad clichC) leet-speak?
When you connected to the first access point, you didn’t realize you were connecting to someone else in the same room as you. They set up their very own wireless access point that acted as a proxy for the internet. This user was running Ethereal to sniff packets, but more importantly, he set up his own machine as the authority for hotmail.com. In doing so, you were directed to his mock site that simulated the look and feel of Hotmail. When you typed in your username and password, it didn’t go to hotmail to authenticate. Instead, it was captured by the “hacker” who immediately used your information to log into the real hotmail site and change your credentials. This hacker was at least kind enough to tell you that you were “had”. Your username and password may likely be the same across multiple services too. That same one you used for hotmail is most likely similar, if not the same as the one you are using on your windows machine. So the user then connects to your machine’s IP address and types in the same username / password information to gain access to administrative shares, read your documents or infect you with viruses. Alternatively, the hacker could read and send email from your box and perhaps use it to gain more information about where you do business, who you talk to and what kind of work (or play) you engage in. The possibilities are limitless and terrifying.
Remember this the next time you blindly walk into a business and connect to their network.
Time Warner’s (un)Security
I wanted to make people fully aware of a problem I encountered today with Time Warner Telecom because it flies in the face of good privacy and security practices.
So here’s the background. I paid my cable bill online through Time Warner the other day. I typically pay through their web interface rather than use ebills like I do for everyone else. However, something happened this time, evidently, and my payment didn’t get processed.
Because my bill was now late, Time Warner gave me a “courtesy call” to tell me. Here’s how the conversation went (not exact, obviously, but this is the gist):
Me: "Hello, this is Tobin."
Time Warner: "Yes, is Mr Titus in?"
Me: "That's me, how can I help you?"
Time Warner: "We were calling to tell you that you are now
past due on your cable bill."
Me: "Really? I paid you the other day online."
Time Warner: "On our website?"
Me: "Yes, ma'am. Let me check my bank account to see
if it processed."
::I then checked online ::
Me: "You are absolutely right, it didn't get processed.
I'll go ahead and try to pay it online again."
Time Warner: "Sir, you don't have to do that. We can accept your
credit card payment over the phone right now."
Me: "I don't make a habit of giving my credit cards over
the phone, particularly when someone calls me."
The fact that these guys offered to take my payment over the phone is bad enough. It should be the policy of every company to NOT accept payments when THEY call YOU because that opens up the door to fraud. If everyone knew that a company would not call you to ask you for your credit card information, there would be less Phishing attacks. This is why AOL specifically puts notices in their IM and Mail windows that says they will NEVER ask for your credit card information through those means.
So offering to take my payment right then and there is a huge problem already, but
here is where it get’s more interesting.
Time Warner: "Sir, we can prove we are who we say we are. We have
your last four digits of your social, your address,
your phone number, etc"
!?!?!?!?!?!! WTF !!??!?!?!!!?
Me: "So do all of my creditors. With all of the recent
ID theft lately, my informaiton is all over the
place. Anyone could have that. But do you mean to
tell me that you would give me the last four digits
of my social and my address to verify that you are
who you say you are? How do you know that I'm really
Tobin and you wouldn't be giving that information
out to just anyone??"
I could hear this representatives wheels turning in her head. She finally tried to back track.
Time Warner: "No, uhh, I , umm, I meant that you could give me
your social and we could tell you if that's right
or not."
Me: "How would that prove anything to me. You'd say 'ok,
what's your social?', I'd say '1234' and you'd say
'yep, that's it, now give me your credit card number!'?"
Time Warner: "No sir, that's not what I meant."
Me: "You were going to read my social to me--a guy who you
can't prove is Tobin Titus."
Time Warner: "No sir, we didn't read your social security number."
Me: "But you were going to!"
Time Warner: "No sir."
Me: "Either you were going to read my social or I was going
to blindly give it to you which would have proved nothing
to me. Which is it?"
At this point, I finally told the lady “nevermind”and asked for her supervisor’s name. This was unreal. I can’t believe in this day and age people non-challantly ask for or provide information like this over the phone with untrusted and unverified individuals. It affects anyone that uses Time Warner and I feel if they don’t see the problems associated with this practice, then their customers need to know that their personal data is in the hands of bumbling idiots.
So how can companies solve this problem? Its fairly simple and I have some rules I think should be implemented by every company that keeps private data. They are as follows.
- Never ask for data when you contact a customer – This is just common sense. Hundreds of thousands of people have been suckered into giving up personal information in so-called phishing scams. If companies, as a general rule don’t ask for information when they contact you, people would be more sensative to thistype of attack.
- Never display sensative personal information to CSRs. – 80% of all “hacks” come from inside a company according to the 2003 CSI/FBI Computer Security Survey. If the CSR is to validate information, it should be typed in. For instance, instead of seeing the full address on the screen, a CSR should be prompted to type in the street number for the address. If the data matches that stored in the database, then and only then should the CSR get to read any of the account information.
- Never use a social security number as an identifier! – This is a pie-in-the-sky sort of request, but it is ultimately necessary if we are ever going to fix identity theft. Anyone who’s been alive since the original Andy Griffeth was on the air should know that Social Security numbers were never meant to be used as identifiers for ANYTHING other than for the social security program. The problem is that this has now become the closest thing to a federal ID we have. Sure its convenient, but this is the direct cause of so much identity theft. I have an entire post dedicated to how we can fix this later, but its out of place here. More to come…
- Hire competent people – Information is only as secure as the people who have access to it. If you are hiring the cheapest labor you can find (and that includes outsourcing your records off-shore — YIKES!), you are sure to have chinks in your armor. Case and point. if Time Warner had competent employees, they would think to themselves “Hmm, maybe I shouldn’t offer to give out this man’s personal data so he knows who we are.” In retrospect, I wonder what this employee would have done had I asked her to prove they were Time Warner by giving me her social security number.
Again, I have more to come, but this should cover the basics. Keep your data on a short leash. If someone asks for data you don’t think is appropriate to give out (particularly on applications), then don’t give it out. Verify the need for the data as well as the intent of use of the data before giving it out to anyone.
Exploit using System.String? Not Really
I’ve been playing around in the CLR for some time just playing with quirks and oddities. I noted some time ago that non-printable characters were easily stored in strings. This really wasn’t a suprise except that a null character (“ ”) could be stored and appropriately retrieved from a string. If I embedded a null character in a string, it didn’t cause the string to truncate when I read it back. This made me wonder just how the string class knew how large its buffer was. How did it know which null character was it’s terminator?
Since my upcoming book deals, in part, with Reflection, I decided to try some playing around with the string object using MemberInfo. I found something rather interesting. The string class keeps track of how large its buffer is in a member variable called m_stringLength. So I started to wonder, what would happen if I created a string and then used reflection to change the length?
I decided to make this interesting. I first created an example class that would represent a class handling sensitive data. My code was simple and was as follows:
using System;
namespace CodeWithSecrets {
// Lets assume this is a class that handles connection strings
// or other sensative data.
class ConnectionStringGuardian {
public ConnectionStringGuardian() {
connect = "uid=sa;pwd=LoveSexSecretGod";
}
}
}
I put this class in its own class library assembly named “CodeWithSecrets”. Then came the code that I would use to exploit the “ConnectionStringGuardian” class.
using System;
using System.Reflection;
using CodeWithSecrets;
namespace MalCode{
class Malware {
[STAThread]
static void Main(string[] args) {
ReadPastBuffer();
}
private static void ReadPastBuffer() {
// Storing some variable
String stringObj = "12345";
// Store an object with private data in it
ConnectionStringGuardian obj = new ConnectionStringGuardian();
// Getting the String Type
Type stringType = Type.GetType("System.String");
// Getting a reference to the private field in System.String
FieldInfo fi = stringType.GetField( "m_stringLength",
BindingFlags.Instance|BindingFlags.NonPublic);
// Read the string object
Console.WriteLine( "Reflected String: '{0}'", stringObj );
// Set the private variable that keeps track of string length;
Object parameter = 255;
fi.SetValue( stringObj, parameter );
// Read the reflected string
Console.WriteLine( "Expanded Buffer: '{0}'", stringObj );
Console.ReadLine();
}
}
}
To explain what I’ve done here, I created a typical string holding an arbitrary value. I then create an instance of my class that holds secret data. Using reflection, I then access the private m_stringLength member to increase the size of the string’s buffer to 255. Finally, I output my string to the console to see if I can read past my buffer in a managed string. As you’ll notice, I write the string’s value to the console before increasing the buffer size, and then I write the strings value to the console again after modifying the buffer size. The following screen shot depicts the results:
Notice that I was able to read past the buffer and into the memory where the sensitive data was stored. (First person to name the movie the sample password comes from gets a free Apress t-shirt if you send me your address.)
Now this is not really an exploit other than the fact that I can read memory to possibly sensitive data. I tried to do other things to the memory such as stomp on it by calling the private “NullTerminate()” method that I found using reflection as well. NullTerminate writes a null terminator at the end of a buffer using the m_stringLength value to determine just where to put that value. This, unfortunately, did not overwrite the data in memory as I was expecting. Ultimately, I was thinking that I might be able to break the type safety of an assembly by stomping on memory belonging to an instance.
The problem with this code (or perhaps the good thing to note if you are an MS security expert) is that I have to use reflection to pull this off. I wouldn’t be able to execute this in a partial trust environment. If I downloaded this code in the internet zone, the reflection permission is not permitted by default. This severely cripples my attempts to make this tidbit worthwhile. As Michael Howard responded to me: “fully trusted code is fully trusted code.” True enough.
In any case, I hope this serves as some sort of education in some more internals of the string class. Let me know what you think.
(P.S. No need to make the obvious statement that sensitive data shouldn’t be stored in classes.)
Old News, But Blog-worthy
There was an old article posted some time ago by James Gosling at Sun. I’ve been meaning to post about it but every time I had a spare moment, someone yanked it from me. In any case, in this article Gosling was shouting some ideas that Microsoft was breaking their Trustworty Computing Initiative’s rules by allowing C++ and C into the .NET family of developer products. Gosling was quoted as saying:
“If you look at the security model in Java and the reliability model, and a lot of things in the exception handling, they depend really critically on the fact that there is some integrity to the properties of objects. So if somebody gives you an object and says ‘This is an image’, then it is an image. It’s not like a pointer to a stream, where it just casts an image,”
Basically, Gosling wants people to feel that as soon as these products were made a part of the .NET product line, they made all other .NET code insecure due to violations of type safety.
Mr Gosling evidently hasn’t studied code access security 101. When an assembly is loaded in .NET it is verified by the CLR before it is allowed to execute. Verification is pretty extensive.
In brief, let’s consider what all happens when an assembly is loaded and executed. First off, the portable executable is validated to make sure it conforms to the PE/COEFF standard. Secondly, all the metadata is validated , making sure that all pointers have valid destinations. A symantec check looks for any sort of shinanigins such as circular inheritance. Next, the IL is verified to be valid and well-formed. As each method is JITed the code is verified to be memory type safe — looking for unsafe casts and attempts to access array indexes that are out of bounds. It probes for buffer overruns and underruns.
There is one caveat to all of this. C++ indeed cannot generally be verified. There is (currently) no way to verify type safety of code written in C++. So does this make Mr Gosling right about his statements? NO. He’s absolutely wrong — and I don’t just say that because I like pretending I know more than the CTO of a multi-national corporation. I say this because security policy in .NET by default rejects any code that cannot pass all of these verifications. To get .NET to run assemblies compiled in C++, it must have the permission to skip verification. If we look at the permission viewere in the .NET configuration tool, we can view any permission set that has the security permission selected. If we double click on the Security permission, there are several sub-permissions available to us. The one we are concerned with is the Skip verification permission. The diagram below depicts this setting in case you don’t feel like looking at this yourself.
This isn’t to say that Mr Gosling wasn’t right at all, but it does put a rather large kink in his argument that there is a HUGE security hole in .NET. Code that executes on the local machine will have this permission because by default all code running in the MyComputer zone runs with FullTrust. Full Trust includes all permissions — including the SkipVerification permission. Yes, if I’m honest with myself I have to say that is a problem, but not in the sense that someone will download code or execute something from the internet that will automatically wreck havoc on the entire type safety system. If I had one wish from he security team at Microsoft it would be to turn this feature off by default.
.NET Security No No
OK. I’m going to cover this one time for guys in the peanut gallery.
Microsoft wised up some time ago and started shipping their Windows Server 2003 product with nearly every feature, apart from logging in, turned off. This was in response to the many-fold accussations that Microsoft was more concerned with functionality than security. (one could argue that they STILL are more concerned with features, but now consider security to be one of those features). In any case, today, when you install a Microsoft server product, it will have limited features, and this is a good thing.
What isn’t good is that developers and administrators keep bypassing this security by elevating priviledges for their code. They somehow feel that its appropriate to strong name their assemblies, and then grant full trust to any code with that strong name. This is an absolute NO NO!
Lets consider this scenario.If your house had priceless valuables stored in it, you would want the best security you could afford. You would remove the standard key/lock system, and replace it with biometric readers, voice print recognition systems, and panic button fail-safes. You might place further restrictions on rooms that contain your most prized possessions in case you have a dinner party — you wouldn’t want just anyone wandering into those rooms without your permission.
The same goes for your code. Think of permissions as the valuables to your code’s household. Grant permissions only when necessary, and only when all appropriate evidence has been supplied. Put fail-safes on your code by denying access to it by any callers that have elevated privileges. When clients access your application, don’t assume they should have access to all your code. If there are portions of your code that perform priviledged operations, require the client to provide additional evidence.
You need a layered approach to security. Granting Full Trust to your strong-named code will definitely help it run whatever you want it to, but you’ll also open the doors to anyone else that finds your valuable resources of interest.
DoS through TCP sequence number vulnerability
SecurityFocus is reporting that multiple vendors are affected by a newly found design flaw in common TCP implementations. The flaw allows remote attackers to effectively end a TCP session by sending an RST or SYN packet with an approximated TCP sequence number and a forged source IP address. This would reset the TCP connection and effectively cause a denial of service attack. Microsoft is one of a long list of vendors on the affected list so you can bet the eggheads at SlashNot are going to highlight their name among them all.
Googling for web.config and other source code
I don’t remember which blogger pointed this out to me, but I wont take credit for the means of searching google in this fashion. However, there are some seriously misguided folks out there that obviously don’t know the first thing about security. Google allows you to search for pages with specific information in the title of the page as well as in the text of the page. Since many directory browsable websites have the word “Index of” in the title , it’s fairly easy to search for sites that are directory browsable. What’s more interesting is that you can then add an “in text” search that searches for specific files in those directory-browsable sites. This could be potentially dangerous if the wrong file were browsable. Take a look at the following search:
http://www.google.com/search?hl=en&lr=&q=intext%3Aweb.config+intitle%3A%22index+of%22+&btnG=Search
These are some of the very folks that want to blame Microsoft for all of their security and virus problems. Seems to me I saw some *cough* Apache servers serving up some of those pages. When will you people get the point that you are only as secure as you want to be and you can’t blame any one vendor for not doing all of your work for you?
