 All right, I think it's about four o'clock or so. So I'm going to start talking. This is identity management. If this is not what you were expecting, yeah, I'm not sure why all of you are here, but why not? So can we talk a little bit about identity management? Yeah, this should be fun. I was going to do the whole Johnny Long intro, but I'm not as cool as he is. So who I am is not really relevant. Yeah, you guys. So we're talking about identity management. Hopefully a few of you guys know what identity management is. Let's go for a raise of hands identity management suite. How many of you guys actually use some sort of identity management in your organization suite? And how many of you guys use Novel Identity Manager? Wow. All right, so this is going to be pretty centric around Novel Identity Manager because that is what I used to do a lot of consulting on. And I know it pretty well. Knew some of the ins and outs of it and found some ugly things while I was using it. And I'm going to talk about those. So what this talk is not, is there anyone from Novel here? Sweet. So if Novel happens to be downloading this talk later, what's that? Is there any press here? Is that what you mean? I'm sure there's press here, and so I'm, oh well. So if Novel happens to take a look at this talk anytime in the future, this is not a fix-it list. Like I'm going to talk about some specific things that I see as issues, you guys can decide. Maybe there are issues, maybe they're not. But this is not like a fix-it list for Novel. I'm sure there are other things that I have not found that Novel should address. And so I really hope that Novel takes just a serious look at their Identity Management scheme, their architecture, kind of what they're doing in that space. Since it is built as a security tool very often, I would prefer that they go and look at it as a security tool and kind of look at some of the security implications of that, do some documentation around how to not set it up insecurely. Just got my picture taken, so they now know where to find me. I do have very high respect for the people at Novel. Crispin, go to his talk tomorrow night. He's very smart. He's a great guy. And Ed Reid, who was formerly there, great guy. So Novel has some great security people. I just think that they have pushed out some of Identity Management pieces a little faster than their security could keep up. So what is this talk? Basically an attempt to convince you that Identity Management is basically just another asset on your network. It needs to be protected just like any other asset. Most of you should be aware of that for the not quite white hat side of the crowd. Hopefully you'll see some things here to take an interest in. And yeah, I'd like for people to go out and start doing research in how to evaluate the security of Identity Management systems as they are becoming a lot more prevalent in corporate environments, as we saw by the show of hands. All this information is pulled directly from public resources straight from websites. So nothing I'm saying here is acquired in any way that's not public. So this is all public knowledge. OK, so Identity Management, most of you seemed like you knew what it was. So basically what is it? Or actually, let's start with what's being said about it. This came out, I think, yesterday or the day before. ISC sent this little quote around. It's a front burner issue for lots of organizations. Basically it's becoming a big security issue. People in the security space are starting to look at Identity Management as a security tool, which is great. It's very useful as a tool. But like any tool on your network, it has some liabilities. And so that's basically what I'm trying to raise awareness about. Theory of IDM, basically you have two systems, generic systems, basically that hold user identities and are connected in some way by some meta-system. And that's your Identity Management system. The Identity Management system continuously manages your identity throughout the whole lifecycle of that identity, provisioning, updating your authentication tokens, granting you authorization within those applications or systems. And it should all be done with the audit and proof repeatable. That's basically what IDM is. Specific products should all be familiar with them. Who's right in Identity Management? This is just Novell's customer list off of their publicly-facing website. So there's a few of them, universities, banks, hospitals. Lots of people are using it. You had to do a search on Identity Management on the RFPs. Lots of government entities are using it. So worst common configurations, typically when you think of Identity Management, a lot of times people will think of an HR system connected to some sort of enterprise directory, which is then connected to other systems. And it's all automatically provisioning identities, controlling where there are. So HR database, going into your directory. These are some of the common ones that Novell pushes. And they are kind of important, as we'll see later. Because it really does depend on how you set up these things as to how secure they are. So what are the issues? When we look at Identity Management system, kind of what are the issues that come up with regards to security? Complexity. Bruce Schneider said yesterday, hey, complexity is the enemy of security or something like that. Don't quote me directly. But I think that's what he said. But basically, if you have any big complex system, it's going to be pretty difficult to secure it. And Identity Management systems are usually very complex. You look at Novell's Identity Manager, for instance. You've got lots of pieces within the system itself. By definition, you're talking about at least two systems. Entire server stacks. It might be a Windows stack and a Linux stack. It might be on the same server, but a database system and an operating system, or a database server and a directory. But basically, you have at least two systems, because obviously you wouldn't be using Identity Manager if you're not trying to manage two systems. You also have management tools, because you probably want to manage the system somehow. So in the Novell space, that's designer, iManager, formerly console one. You have different ways of doing this. User-facing applications, very, very commonly, you see Identity Management being used to connect into some sort of user-facing application, some sort of portal, user-self service, what have you. Very complex systems in and of themselves. And then you add on to this in Identity Management framework, and it becomes even more complex. And usually you have auditing systems in all this. We're dealing with identities. So naturally, they are going to be fairly high value, because this is usernames, passwords, or other authentication tokens. If you're synchronizing certificates, this is where your authentication tokens reside. This is where they're being synchronized. So to break into the system, or any of these systems, is going to be a high value target. It also deals with authorization. So I want to make the distinction there. But these systems are automatically, based on business rules, determining what you as a user are authorized to do within a system. So if I can grant myself full access rights, then that's cool. I can break the system by doing that. And of course, you're also very commonly dealing with HR systems, which contain things like social security numbers and other good things like that. So high value targets, very complex. And to be quite honest, a lot of administrators just kind of go, oh, it's Novella Secure. Oh, it's Novella Security System. Therefore, it is in of itself secure. And they don't really take a step back and say, hey, how secure is it as an application, as a tool on our network? How secure is it? Best practices are out there for securing identity management. You can go download that off of Novella's website. Sometimes they conflict, and oftentimes they're very incomplete. I've noticed, as I've gone around set up systems and as people have downloaded the best practices. So a lot of times people just don't really lock these down very well. So basically all I'm saying is it's a liability on your network, not a control. So let's look at the security of it. High target for attack. So, okay, so if we're actually going to exploit this, by the way, I should say I'm trying to get through all the talking about things in about 20 minutes and then well about 30 minutes of some demos. And then we'll be done with it. So just some theory of exploiting it. Basically, how do you leverage complexity? Or I'm sorry. In a complex system, you want to leverage that to your advantage. If you have lots of systems, these are usually in very large environments with very strict change control. So really the defender is at the disadvantage. The attacker is obviously at the advantage. Nothing new here. It was very much, or I didn't imagine it very much is kind of a hot topic right now. I think last couple of years has been kind of one of the emerging technologies. And therefore it's been rushed out by companies like Novell. I'm picking on Novell, but honestly, go and look at any of the other ones. They're just as bad, if not worse. Actually some of them are much worse. So yes, I'm picking on Novell and yes, Novell rushed out their product a couple of years ago. They've done a lot of fixes to it, but it's still, you can definitely tell the code quality is not there. Or at least it's not where it should be in my opinion. When we look at an identity management system, we can attack it at a bunch of different layers. Obviously, most of the time you're gonna be having a network in between your systems. Sometimes you'll be doing all this on one box, but I'm not really sure why you would do that in too many cases. So most of the time you have a network layer, you can attack that. You have the connected systems. Basically, you have one of your systems might be a Windows system. So you have the entire Windows stack you can attack. Might be a Linux system. You have the entire Linux stack you can attack. Database, directories, what have you. At the application layer. So the actual identity management engine that's gonna be running all this. The engine's just code. It has vulnerabilities. It has bugs in it. So do all the agents that run all these connected systems. And the management tools themselves also have a lot of bugs. So you can attack it a lot of places in the actual system itself. And then the next layer down, the rules themselves. So someone has come in and said, hey, here are the business rules for this organization. We need to codify them. You've then coded them into some sort of logic that the identity management system can understand. And often these can be exploited. We'll show you some examples of that. So, now I'm gonna start picking on Novell, because they're what I know. But again, I do wanna be very clear. Novell is a great product. I do actually like a lot of their products. I'm running Cecil Linux right here. Microsoft's identity management is nightmare. Anyway, we won't even go there. So anyway, I pick it on them, but these are just some examples. And I really do want Novell especially to better their security. So that's why I'm picking on them. Why am I presenting this stuff? Basically, I think Novell has made a few poor decisions in their architecture. Whatever. They made some decisions that aren't really clearly documented. I find a lot of people, a lot of customers will go, they'll implement the system as they think is best. And they don't really have any instructions on how to set up things securely. There's very few best practices. And so they end up just setting it up horribly insecure as a result. And even when they do follow best practices, there are still a lot of ways that the system can be exploited, whether or not the best practices have been used. So we'll look at a couple of those. So, minimal Novell identity manager system. You have e-directory, you have the meta-directory engine, which is a big piece of code. I think I'd go into that, yeah. So I'm gonna cover all these more in depth. Meta-directory engine is basically a set of Java libraries or a native code libraries, depending on the exact platform. E-directory loads them in and it does a bunch of rule processing and stuff for you. Within the identity management engine, there's the concept of drivers, which are pieces of rules. There's XML rules, along with a native code component that translates the output of these rules to native code or a native application calls. And as I said, the driver rules and a shim, which is basically a Java class, which has a publisher and subscriber. All right, remote loader, because it is running our remote system, it does have a lot of interesting characteristics. So the remote loader is basically a miniaturized, actually it's not a miniaturized engine, it's an application that loads the shim in so that it takes XML and translates it to native application protocols. And basically it connects to the IDM engine through over the network. Password authentication for it. It uses an XML-ish protocol to communicate with the engine. So hopefully as you're sitting there, you're kind of getting an idea of how complex these systems are if you weren't aware of it. So how are these systems typically used? Basically, you kind of your standard HR database, off and running on a Windows platform or an Oracle platform, something like that. Usually has a remote loader out there, which is basically second things out of HR. Putting that into some sort of enterprise directory, or putting it into your e-directory in Novell's case. And from there you're synchronizing out to different directories, different applications, that sort of thing. And there's usually this flow from HR to the identity vault, and then you synchronize from there, which has its own security implications. I mean, the spot where your security concerns would be. Another common configuration, basically you have Novell admins that do all their work in your legacy NDS tree, that gets synchronized to a meta directory, and then that gets synchronized out to some sort of self-service portal, what have you. This is a fun one, bringing Novell into an active directory environment. Some CTO says, hey, we're gonna start doing Novell stuff. And so the Windows admins keep doing everything in active directory, and it automatically synchronizes over to your Novell directory. But this has some common, I mean, there's some problems with this, right? Because is active directory and e-directory equally secure? They can be. I think there are ways that you can set up active directory to be secure. I was back when I was working for a consulting company. We went to a bank where it had this exact setup we didn't know at the time. It took us about 45 minutes to compromise active directory, get an admin there. That's cause, 45 minutes, cause I had my firewall on on my TFTP server. Took us about half an hour to figure that out. So we got domain admin on active directory, couldn't figure out how to get into e-directory. We're sitting there banging on it. So we tried the admin user that we created in active directory. We thought, hey, why not, let's give it a try. And lo and behold, it was there. Automatically synchronized across. So we actually had an admin user in e-directory as well as an admin user in active directory because identity management system had very nicely synchronized that all across. So that's just something you have to keep in mind of, when you further upstream you're going with your identities, the more carefully you need to be about how the systems are gonna be broken into and protect them better. Or put in business rules to protect yourself when they do get broken into. So choosing your targets, obviously, aim high in the identity flow because you're gonna have better payoff. You compromise the HR database, then you can basically create any user you want in the system. Whereas if you're just compromising one way down at the end, who knows, maybe it might synchronize back up, might not. But this is gonna be different from every environment. So I'm not saying, I'm not making any blanket statements about how you need to set out your network. But you just need to make those decisions, keep those security implications in mind as you're laying out your network. Just real quick, I wanted to go over the security best practices from Novell. There are some really good ideas here, things you really need to do. And some things that really don't help you at all. So their number one thing, use SSL. Absolutely, use SSL. It makes it a little bit harder to do certain types of attacks. It makes it impossible to do other types of attacks. And yeah, it's a good idea. It protects the confidentiality for someone just sniffing your network. Modern control access to your driver sets in your tree, obviously by default, very few permissions on those objects, so you should monitor them. Don't allow too much information in your password hints. If you're doing password self-service, force password changes. Follow industry best practices for security measures, such as blocking unused ports on the servers. Wow, that's a nice statement there. Designer, if you're using Novell's designer, which is kind of their design tool as well as a management tool. In that case, you should limit your consultant's rights in your tree. Not sure why you only do that with a designer, but that's where the best practices stay. Control your project files. Basically, this is a fake application running on your consultant's laptop. It stores the passwords, we'll cover that later. And don't use encrypted attributes because designer can't understand them. There's a great security best practice. Track and changes to sense of information, basically audit things well. All right, so that covers the theory exactly 20 minutes. Let's talk about how we would actually go about doing some bad things to one of these systems. What would be the goals that we're trying to do? I mean, we talk about exploiting a system. What are we actually trying to do? Someone yesterday was talking about how the goal of your exploit is the data. I think it was H.D. Moore's talk, excellent. The goal really is your data. I mean, it's whatever data you're trying to get at within the system. But to get at that, you need identities, you need authorization, and that's what you're gonna be attacking the identity management system to get. So, one goal is to just gain an identity. If you can create your own user, great. If you can get a user created in one of the connected systems, great, not as much access with air, but you still have access. Exceeding your authorization. If you're an employee, the identity management system says, hey, you're supposed to have access to these files. If you can escalate that up and exceed what your authorization is based on system rules, great. Stealing someone else's identity. If you can steal their authentication tokens, you can become them on the network. Not that difficult to do. And basically violating the integrity of the identity system. So, that's our goal. You come into a network, how are you gonna actually find out whether or not it's running identity manager? Maybe some of you guys work at companies and you don't know actually if you're running identity management at your company. Or you've broken in over the internet and you don't know if this network has identity manager installed. First thing you're gonna look for is if you can publicly browse the LDAP directory. You can search for the object class. Object class is by default, readable by anonymous. So, anyone can anonymously connect to your LDAP ports and look for object class equals direct smell driver. That's a dead giveaway. If you come up to an iManager server, there are a bunch of web pages that you can look at. If they don't have identity manager, which formerly direct smell, they don't have that installed. They don't have the plugins to manage their identity management system installed on that version of iManager. Then these will come back with 404s. If they do have the plugins installed to manage identity manager, you get 200 coming back. Easy way to find it. Remote loader. You're remote loaders, so there's little applications that are basically just translating XML to native code. By default, they run on port 8090. That's kind of the default start one. And then if multiple remote loaders are running on a system, it'll just increment up the ports. So, looking for open ports on 8090 and above is cool. But they are only open when a remote loader is listening for a connection, but the engine has not actually initiated that connection. Once it does that, then the remote loader only talks to the engine. And it doesn't listen to the network. And that does not return, it returns a closed port, in that case. Lastly, file system. I don't know how many people have access to their Linux servers that are running directories, but if you do, userlib.directs.mil or cnovell remote loader, just two of the places you can look to find the installation. So, these are complex systems, lots of systems involved. Obviously, you can do Windows exploits. I mean, name an exploit, and you can probably exploit a component of an identity management system. But nothing new there. Exploits in the actual identity management system itself. In the actual code that manages the identities. That was interesting to me. Saw some things that looked a little bit ugly. As I mentioned, code quality looked a little bit poor to me. So it was something I kind of took a look into. So again, you have med directory engine, you have some shims, you have a remote loader. Lots of good stuff to, lots of good targets to look at. So, three slides back, I kind of mentioned a very trivial denial of service, which, very simple, basically, we have remote loaders running on a remote system, listens to the network. But as soon as someone connects it to it, it turns off. So, you know what? Netcat, great denial of service tool. Just connect it to the port if you see it open. And it, basically your engine can no longer connect in. As long as you don't send it anything, it will hold that port open for forever, just waiting for you to initiate with your password. So, if you open the port, basically the whole system can never, can't talk to the engine. Why is that a problem? Obviously, if you're, you know, gonna be deleted from a system and you know that, running a denial of service is pretty critical, because if you can deny service on that connected system, then obviously you can't be deprovisioned, you can't have your authorization changed, and you know, whatever access you have on that system, you're gonna maintain, because you can't get updated. I was gonna demonstrate that, but yeah, oh well. Ranifuzzer on this, you know, we're connected over a network. Let's look at some fuzzing statistics. Basically, it took about a minute to five minutes till you crashed your remote loader. When we were doing a pure Java remote loader, so the remote loader was pulling in a pure Java library, basically Java would just get so confused and couldn't tell, you know, one side thought it was open, the other side would try to connect, and it was closed, and all sorts of confusion there, and basically we'd just come to a halt, not be able to resolve itself after about five minutes. If you're loading an actual native code, like the Active Directory driver, you actually crash the application in about one minute. I do have dumps if anyone knows how to write good exploits, talk to me. And about 20 minutes to crash the engine. Basically if you're fuzzing the engine side, it took about 20 minutes for the engine to just go to all weird. Again, very heavy use of Java, so I don't think any of them can be used for a remote exploit, but you can definitely throw into weird states where it just doesn't know what it's doing. And I did not get around to fuzzing the XML definitions that are actually held up in the directory, so directory objects that contain all these XML files. Been trying to do that, but I have to write my own fuzzer for that, and haven't gotten around to it yet. Oh, DX command, which is kind of the command line utility that uses NCP to control the driver functionality. Yeah, it basically choked on the first packet that got fuzzed, so it would just quit with the Java dump. So not real reliable. For something that's really managing all your identities, not all that reliable. So, let's say we can't fuzz things. If we own one of the systems, if we actually control your identity management, control the meta directory, so the e-directory, we can just go and change business rules pretty much any time we want. Of course, if you're an attacker, you go in and change the rules, that's pretty obvious, and you have to have admin in any directory. So, not too useful, but obviously, someone who's attacking your identity management system, they can do this, and what controls do you have in place to prevent someone from doing that? That's a question you can answer. Modifying the system libraries and the applications that are up there. On a Linux stack, running my demo system, I'm running OES here with e-directory. Good default permissions in the directory, great file permissions are very tight. We then go over to Windows side, and full control is granted to everyone by default after a default install. So, I had a little fun with that. Basically, I thought, hey, if I can create my own shim without anyone noticing, since full control is given to everyone, so me being everyone, I could just log in and change out the shim. Why not? So, in our test tree here, basically we have a remote loader, remote console here, which is just controlling the connections to our different remote loaders that are running here. One of them is a completely named driver to be Trojan, which is just a little mid-text driver. It's up there in our tree, I can, wrong way. So it's just a driver running in my tree. So, what do we do? Basically, when the remote loader starts up, it reads the novell remote loader lib directory, pulls in every single jar file, uses that as your class path. And then, if you look back at any of your, the properties of any of your remote loaders, the Java class that's supposed to be called to initiate this shim, it's listed right there. So, two things we need to do, we either need to swap out what that class points to within this directory, which is a little bit difficult. You get some files being locked and stuff when you try to swap that out, or you just change them all. So, that's, you know, just wanted to demo that real quick in case someone doesn't quite believe me. Basically, it went and downloaded the driver SDK from novell, compiled my own driver, added in a little bit of code that wrote a file to a, writes out a file to the C, you know, the root directory. I'm not a Windows person, so if I talk a little bit, UNXE, sorry. So basically, it writes a file out to your C directory, and then starts up like a normal driver. So, we'll just, you know, copy that over since we have full control on the lib directory. That's cool. So now we have to make sure that when the driver starts up next time, it points to the right class, it points to our hostile class. So, we'll go conveniently, our remote loader told us what the config file name is, which was config. So, there is our class. Just swap that out real quick, because that's fun. We'll save that. And obviously this is loading memory, so, you know, it's not looking at the config file right now. Like I said, you know, after I fuzz this a few times, you know, it's not that easy or not that difficult to crash one of these drivers. So, you know, causing a denial of service on these is far too, far too easy. So, but for demonstration's sake, I'm just gonna stop it. So, for our C drive, you know, no weird files there. So, let's start up a driver and demo gods do not. There we go. So, woohoo. Basically what it did, start the driver, driver, my custom driver, write out a file to the C drive. And it's running as local system, so basically you can do whatever you want. And, you know, some admin actually going to notice this, you know, they would get in their log files that, you know, hey, maybe the through-mode loader restarted. That's about it. So, that was fun. Go build your own by go downloading the SDK, just use ant to build the default examples there, and add in wherever you want. So, we wrote our own shim. Can we write our own remote loader? You know, that might be possible. I looked at that, said, you know, hey, basically, the engine is going there. It's, you know, it's given the IP address or, you know, the DNS name of the remote side. Can we write our own? That's gonna mimic that and do some password stealing. I tried it out. One of the things I'd overcome was, you know, basically they recommend that you use SSL on this, but kind of get to that, they use it in kind of a weird way that basically SSL is used to authenticate the engine, but it's never used to authenticate the remote loader. So even if we're using SSL, we can get around that because it's not cryptographically protected. It's just authenticated by password. And there's basically two different passwords that are used, your driver object password and your remote loader password. And your remote loader password is actually used in two different ways. One for the command, the little command window that actually controls the driver, and it's also used for the engine connecting in. So, pictorially, hey, your remote loader's there. Listen to the network, cool. Password authentication, when the command piece goes in and tries to connect to your remote loader, it does this great cryptographic challenge response. It takes a timestamp and it hashes it a couple times, verifies it both sides and know the password without ever passing the password over the network. Beautiful, that's how it should be done. When we're talking about the connection between the engine and the remote loader, your passwords get sent in clear text. I don't know why. But anyway, they do. Because of that, we can write our own little trojan. One thing I just want to point out. Many people use the same password for these multiple passwords, and nowhere in the Novell documentation does it say, hey, use different passwords for these. So, every Novell training you go to, most Novell consultants I've talked to, they always use the same password for the driver object and the remote loader. Bad idea, because your engine is saying, hi, here's my password, now authenticate to me. And if you're coming back with the same exact password, that's just too easy. So, it's easy. So, because it's easy, I decided to write a little tool to do it for me. Have a little server, I'm gonna start up. And then the other thing I need to do is basically, there are many different ways of ARP spoofing DNS redirection, plenty of ways. You can get redirect where this engine is talking to. For demo sake, because the demo gods hate me, I'm just gonna go in and change the IP address if it ever decides to load. So, formally we're connected to our remote loader directly, I'm just going to change that to go to my server, which, and so as soon as you make a change, it's gonna restart the driver, woohoo. And let's go see what we got. We didn't get anything, there we go. So, basically we was just listening to the network, the engine said, hey, here's my remote loader password and please authenticate me and start talking to me. I basically said, great, thank you for that password. I'm gonna turn around and use that, just try and use that for my driver object password. And so I passed it back using the right protocol and it gave me a success message so I know now that my passwords are the same and it prints out here. This little tool here will be up on, or will be pointed to, I haven't quite figured out a good place to host it yet, but I hate novell.blogger.com. I'll put it up there. SSL, again, I'm just gonna mention, novell does some great things with cryptography and then every once in a while you just wonder what were they thinking. So they've made it very, very difficult to talk to remote loader as a fake dry smell engine, but it's really easy to talk to it as a fake remote loader because there's no cryptographic authentication of the remote loader. It's physically impossible to load a certificate up on the engine side. And so, that makes it all possible. However, you do use a really funky version of TLS so I'm still kind of working out that to get this tool to run under SSL, but it should not be a problem. Like I said, it is possible. Okay, using the rules. Basically, to actually figure out how you're gonna use rules to your advantage, you have to know what rules are up there. Fortunately, you can just do an LDAP search anonymously on your directory tree and by default you can get back the names of all the drivers because it's in your CN, it's in your RDN. So, pretty much anyone can go there and read what rules you have defined for your RDN installation and they can compare those to the default rules because most people go, they download the drivers from Novell, they use most of the default rules, they change a few and so people can basically read what your business logic is based off of just an anonymous search of your tree unless you turn that off, which I highly recommend. So, for example, if I go up and read that you have an Active Directory driver up there and I know that Active Directory driver by default matches on full name and I can troll one side and obviously I can start exploiting that by exploiting the default business logic that Novell gave you. And obviously if you have some custom logic in there, I'm not gonna know that as an anonymous attacker but as a reasonably tech savvy person in your corporation, I can probably make some good guesses at it. Exploiting the rule processing. This is another fun one. Basically your shim is taking XML code, translated over to native application calls and different drivers handle it differently every single one of these shims is written by a different person, you have vastly different code quality. I happen to have done a lot of work with the JDBC and doing database connections, so I had some fun with it and yeah, basically by default, if you just do a default install the JDBC driver, this nice little rule comes in there where it takes your common name and uses it in an update statement on your SQL server running as DBO. So hopefully most of you get where I'm going with this and within the next 10 minutes, we will quickly demonstrate a SQL injection in direct-small processing. So have a little table here. This is my default database. Basically just a default install of the database straight from Novell so you can go and duplicate this yourself. I added in this little table for my little proof of concept. I'm now going to add in a user, there we go, to my directory. That one guy had a few special things added to him. And let's see, so got a few errors. And in this table, hello Defcon, yes we have SQL injection in your driver. This is default driver from Novell. So anyone using the default driver from Novell should check up on this. SQL injections, last one, passwords. A couple of places that we deal with passwords, obviously a lot of people use identity management for passwords. Don't use passwords. Okay, I can't say it enough, do not use passwords. They are the weakest form of authentication, but unfortunately a lot of you have to use them so you don't have a choice. Let's be careful, at least know where your passwords are going. Using identity management for Active Directory on the window side you're gonna have a password filter which is basically just a little DLL that you've put in Active Directory which says, hey every time someone changes their password in Active Directory, write it out to this registry key. It does encrypt it, so if you go and look at it, Novell has not, I couldn't find out from Novell publicly how that encryption worked, so all I can say is it is encrypted. Go and look at those keys yourself if you can find a way to decrypt it. Cool, write a utility for it. Universal passwords, so this is actually where my dislike of Novell started and I have a rocky history with them as a result. But basically they decided as a company to go with this whole idea of universal password which was, hey let's store our passwords in E-Directory instead of using this great hashing function that NDS has been using for years, let's store them just encrypted with triple des. Okay, we're also storing the key to decrypt it on the server, so that's a problem if you're storing the encrypted version along with the key, is that really encrypted? We can debate that. But for the most part it works pretty well. Basically access into those passwords is controlled by a couple factors. You have to be an admin, you have to have rights to that directory object which is by default only given to admin. You have to access it over SSL, if you're accessing it in clear text it won't give it back to you. And there's password policies that govern whether or not admin can read the password. Of course admin owns these policies and admin can change the policies whenever they want. That was kind of my reason for thinking this was kind of a bad scheme. So as a result, yes it is possible. You have your password policies, so as admin I can just go in them and change them to say hey, let me read them. I can then basically just go and ask the directory say hey, give me everyone's password and I have them. Yes, this is what you're forced to use if you're using password synchronization with Identity Manager 3.0 or later. You have to use universal password and universal passwords are just encrypted passwords and encrypted passwords can be decrypted. I think I've hammered it enough. So that's, yeah, speaking of passwords, I mentioned designer which is that nice little management tool has a encoded password and they do warn you about this if you read the documentation it says do not store your admin password in here. I was gonna put up, I couldn't find my pearl script to decrypt it, but basically it's base64 encoded and you take the, it's basically base64 encoded string and you take the first character of every three characters and move it to the last one and then you just base64 decoded and you have the password back. It's those kind of things that just annoy me because I'm a crypto guy and you can encrypt things so easily why would you base64 encode something and then do some transposition to encrypt it? I don't know, but those are types of things I get mad about. So coming up on the end of this talk I just wanted to say River wrote the art of fuzzing. Your proxy fuzzer is my friend. I found that tool, I love it. Great tool, little nice little Python script. Does great for fuzzing network connections. While I was in here doing this presentation I wrote a little pro script to go in and bulk update every attribute to a fixed string on your user, test user and your database. I recommend people doing this with things like common SQL injections, cross-site scripting. I didn't get to it because I don't have time but yeah, do some cross-site scripting and then try and view your user with iManager. You get some great results. But I'll have that script up on the website as well or link to it somewhere so they figure out how to do that. And fake remote loader, yeah, I'll throw that up there as well. Just go for it, use it. Like I mentioned, yeah, there's several places where iManager just chokes when you rewrite people's attributes. It's pretty ugly. Novell audit, another good application in theory, bad in implementation. Sorry, there's just been lots of bugs in implementation. And fortunately it's been replaced by Novell Sentinel. So, cool stuff. Really easy to fingerprint your drivers. User application, this is a huge application. It's your Linux server running in JBoss with this entire portal application on top of it. It's kind of the new iManager 3 if you're familiar with Novell. It was one of the big selling features of IDM3. And basically, again, it was just not the highest code quality. Lots of ugly things in there in the whole implementation and I don't even have time to do all the write-ups on those, but maybe next year. And then designer, I haven't even started looking at designer yet other than the little password thing. So, lots of work to be done. Basically, I can't find anyone else there out here who is doing research on the security of identity management systems. So, if you're out there, please talk to me because I'd love to thank some ideas off you. But yeah, I'm out there doing it by myself at the moment and would love some help. We don't really have much time, but basically, whatever background you come from, you guys might think I'm crazy. Maybe I am crazy. Maybe I just think this is bad design is some personal flaw, but I don't know. Maybe I'm way off. Maybe I'm right. Who knows? You guys can make up your own mind. So, conclusion. Hopefully, all you guys can raise your hands saying you're running Novell Identity Manager. You're aware of some ways people might exploit your system. Maybe you can go back and, you know, just put on your security hat, take a look at your system and remember it's not invulnerable. Yeah, I hope Novell takes a look at their own stuff and I really do hope someone out there sees it and I have one minute and someone else comes, joins me, doing some fun stuff. That's it. I have some more stuff I skipped, but that's what the Q&A room is for afterwards. So, thank you.