 by changing where you'd want to put in grep-i anonymous, you do grep-i failed or refused, you can hook up any failed or refused login attempts to the FTP server. So basically you can just filter your logs like that. It's a little bit easier for some people who might be new to the OS 10 environment and not who aren't used to using Linux or Linux or Unix environment in terms of checking their logs and everything. Basically you could also modify the script further to perhaps beep or send out an email alert if you have multiple login failures, stuff like that just for basic system maintenance. As far as AppleScript goes for an attack tool, it can be used, definitely used for attack means on a Macintosh system, excuse me. Basically over the past few years there've been a couple AppleScript Trojans or viruses, but they mainly only do one of two things. They either take a look at the system and just mess around with files, delete stuff, or else they exploit a scriptable application where a scriptable application would be any application on the system that accepts Apple events and thus AppleScripts. Basically in terms of some different attack methods that could be used, the Mac.Simpsons AppleScript form that was released about a year ago, I believe, basically duped global users into downloading and executing the AppleScript which was included as an email attachment. Once it had done that, it popped open a Simpsons webpage and went from there to open up Outlook and send itself out to everybody in the address book just like any typical Microsoft worm does these days. So that was exploiting Outlook's scriptability in terms of the Macintosh there with the AppleScript. In this case, or pardon me, another similar case there was Udora had a similar exploit a few years ago where basically it accepted AppleScripts and then could be used to send email out without the user knowing, of course. Luckily, there was no malicious payload included in either of those basically worms that I just described there, but it would have been very easy for them to modify the AppleScript a bit to say delete documents or something like that while the AppleScript is running. In OS 10, especially with the Unix commands, that can be particularly destructive and I will demonstrate that right now. Basically I'm going to take, open up my system here real quick and open up documents. Let's see here, okay, we have some basic stuff in here. We'll duplicate this copy of my speech here and save the real one since I don't wanna lose it and we'll duplicate this iTunes folder right here. So basically we have some stuff sitting in my documents folder right now. If we go ahead and run an AppleScript, again using shell commands, basically we're going to clear everything out in there. So rm-rf and then tealday slash documents which will remove everything in my documents folder. And if you take a look then, there is no documents folder period. That could be especially destructive if somebody went ahead and made another scriptable worm that exploited even mail or something like that in the OS 10 environment, it could easily be put to use in terms of destroying files on the computer or even worse downloading the various password files, anything like that. As far as going ahead and exploiting a scriptable application goes, it's very easy to do. It's as easy as going up to file when you're inside the script editor and you go to open dictionary just like this and as soon as my G3 here catches up, maybe. Oh anyway, we'll bring up a list of dictionaries and these are all the applications on your system that could be scriptable. So you go ahead and you pick one, let's just say internet explorer and open up a dictionary for that. You probably can't read very well but it basically gives you a list of things you can do with this, you could open up a URL, you can close all windows, activate it, all these things. And if you go through different scriptable applications you will find ones that you could exploit possibly sending out mail, going to a webpage with some malicious Java but something like that. So that's a very easy way to go ahead and just find out what applications you can script and that gives you the whole dictionary you need there. As far as OS9 is concerned, going back a minute there, OS9 had some pretty scary scriptable applications. The Keychain Manager, for those of you who do use it, it's basically you take a key which is your password and you put on the Keychain and you lock the Keychain with one other password. All the passwords that are on it are encrypted. The thing is, it's not necessarily locked and if it's unlocked, anybody can go with Apple Script and delete all your keys, download your keys with your passwords, anything like that. The Keychain Manager is present in OS10 but it is not scriptable as of yet. So personally, my opinion on that is that it's better for any method where you just encrypt your passwords. Someday the encryption's gonna be broken. To my opinion, it's best to keep your passwords where you know they'll be safe, which is in your head. If you continue on with permissions of OS10, they play a big role in exploiting any of these scriptable applications. For example, the permissions with NetInfo Manager by default are those that you can get basically the password list of all the users in the system. So we're gonna do another shell script here, network info manager dump and then we're gonna dump the password file here and when we do that, you can't really see that, but we have the list of password hashes for root as well as other users on the system that were enabled and those would be crackable than if you used crack or anything else. You could very easily incorporate this Apple Script into a small Trojan and have it send the password file remotely for cracking on your own system or an enemy system and then go ahead and log in remotely. In this sense, you could access the NetInfo Manager information there if you have local access and a shell access on the machine, but sometimes you do not have that and that would be possible then to go ahead and get into a system. I do have that as proof of concept script that I flushed out from this. Unfortunately, due to time constraints, I didn't get on the CD in time, but I will have it available for anybody who'd like it. Otherwise it would be on the DEF CON network for the whole weekend. Moving onward, Apple Script can be used as a defense tool. Basically, Apple Script can be used to check and kill processes running in OS 10. So if you notice a process that shouldn't be running, you can go ahead and again, using terminal application and I don't have anything running, but if I had had anything running, you can go ahead and kill it by just typing kill and then the process ID in an Apple Script. You can also do this to list applications that are running. This is a non-terminal one again. So this is going to be, let me see what I have here. We're gonna tell the finder to list all of the applications that are running right now. And here we have a list of basically everything that's running on the system right now and you can go ahead and get the process ID then and cause any of those to quit. So basically you can keep up with what's running on your system, again with Apple Script showing its robustness in this. You can just play a list of users just by using the normal finger command in a Unix shell, so you can do with Apple Script of course. I basically, I realize that these are all Unix commands that can really easily be done in the terminal, but when combined with Apple Scripts and may put into a nice GUI, they do turn into quite a nice little program that you can just do one click, check your system. It's also good for people who are new to OS 10 and anybody who's really migrated just over from OS 9 without any Unix background. It does help them get a little bit more accustomed to it. As far as Apple Script security practices go, a general rule of thumb is not to run compiled Apple Scripts on your system and tell your positive if you know what they do. For the most part, you know that that sounds like it'd be something that you normally do. You just check the source code if you can, verify that it's legit and then go ahead and compile on it yourself. So this is not so obvious though that a downloaded script is, or downloaded program file, whatever is not an Apple Script or another malicious application for that matter. In that case, a malicious person could just change the icon of the item and make it look like a text file. In OS 10, you could easily go ahead and make that Apple Script open up a text file, have, pardon me, text edit, have some text listed on the screen and go ahead and delete everything in the background. This is basically the way the Mac.Simpson's worm functioned. By displaying the Simpsons website, the user didn't realize that it was sending out the email in the background. So a script can be more than meets the eye there. To verify the validity of a downloaded file, just use the get info command in the finder. It's supposed to do that right now. We'll just open up this defcon speech that I had before and get info and it's listed as a rich text format document under the kind. I just want to make sure that it wouldn't say, you know, application or compiled script. If it looks like a text file, you know you should be fine if it's a text file. Other than that, you can go on that if you are going to run a compiled script that you know is a compiled script, think twice before running it. Just make sure you know who sent it to you. Just because it can do some nasty stuff now in OS 10. Another good idea is to change the permissions on files and applications in OS 10 that you wouldn't want other users to be able to access. Just use the chmod command there. As far as looking towards the future goes, as OS 10 matures, Apple script is sure to enjoy an even tighter integration into the OS than it has already. And there's more and more software companies make their programs scriptable. The more possible exploits they'll be. As far as Apple script, it can be powerful for good reasons or bad reasons, just like anything else. So in my opinion for this speech, I just kind of want to make sure people realize that Apple script is a very powerful tool. It can be very good on the network, but it also can definitely have some bad consequences if you run scripts that really shouldn't be run. Right now I'm going to just demo a couple of things with these scripts that I showed you before. Let me just kind of fix the font thing real quick. Okay, going back, Apple script can also be used to run shell scripts. It can execute basically any application and cause it to open. So if you wanted to with that password dump before, you could take it, get the password dump file and then go ahead and send it to crack to start cracking password files. I was going to do that, but I do not have the copy of crack in my system right now, so I can't exactly show you that. Overall, basically, I guess it's just mainly a concept of just making sure when you're programming, if you program for Macintosh, just make sure you think before you put in scriptable parts of your application. It definitely helps for those of us who do programming on Apple script, but just make sure it doesn't do anything that could lead to a compromise in the system, especially mail programs. They do tend to have issues like that. Basically right now I've got, it's going to take a little bit of a break. I've got some books, Cara Freaky from Freaks Mac Archive and SecureMac.com that he got from O'Reilly. I definitely do recommend O'Reilly's books. I guess I'd use this one, as you can see, quite a bit for Apple script. It's a pretty good book. Not much in OS X though, but I've got a couple books that they gave him. So okay, we've got Mac OS X pocket reference. Anybody want this? All right, I'm going to throw this out. I hope I won't break anything this year. Okay, throw another one. Oh, those things can go far. Okay, throw one over here now. It's like a baseball game. Okay, we've also got a few Unix for Mac OS X. All right, I knew that one would drop some. Okay, where should I throw this one? We'll throw one over there. And that one, oh, that's just those stupid little postcards. All right, we got one more. Okay, I hope I don't hit the projector over there. All right, one more. All right. I'm also supposed to give away these. I believe it's a tape drive, I think. Okay, I'm not going to throw one of these, so, hmm. Okay, we'll see. We'll do some question and answer stuff right now. So if anybody has any questions, if you have a decent question that I like answering, then I'll give you one of these things. Okay, anybody have any questions? You can go ahead with the dictionary and let me just show you real quick. If you don't see anything that's listed there, these are the ones that actually tell OS X that yes, I have a dictionary. You can go ahead and you can browse the system yourself. Okay, the question was, okay, I see what the question was. It's, if you're inside an application, you see where it says what it does. You want to know if you can add more to that. Without having the source code to the program, that's not really possible, because it's just what, when you program a Macintosh program there, you'd need to say, okay, when you receive this Apple script, do this. And if you don't have the source code to that program to add that code, you can't do that on your own. The company or person who programmed the self originally could though. As far as if you were making your own program though, you could feel free to, you know, add it whenever you wanted to, in terms of that. So if you want to come up here, you can have one of these tape drives if you'd like. Any other questions? Basically in the OS X server version, there is a lot that's still with Apple script. I mean, if you have it enabled in your system, it can still cause damage. If somebody runs it maliciously, I guess the only thing to really do is if you are running the server, you know, just make sure you know what you're running. For the most part, Macs are still secure enough that you can't just break into one without doing something like, you know, throwing a charge on the system first, or having some services running that, you know, really. I mean, as far as Unix goes, yeah, if you run services, you might get hacked, but if you're smart about it and you have your last patches and everything, it should really shouldn't cause you any trouble there. If you want a tape drive, you can have one too. All right, unfortunately, I don't have anything else to give out, but I can take more questions. Actually, I really can't hear you. Do you want to come up here with one of the Macs? The fans up here are kind of noisy. Okay, the question was, can you give Apple scripts? I believe compiled scripts you're talking about there. Okay, basically, can you give them an extension like .log or anything like that? You could, but the way OS X operates is for the most part, it will try and open it then as if it was, you know, a text file or whatever. It will not run the script, especially to get a bunch of gibberish. It's the way it works for most of OS X in terms of changing the names and stuff. Any other questions? You have the way around for getting, sorry. My hearing's horrible, so. So you showed how to get to the command line from Apple Script, how about the other way around? All right, the question was that I showed how to get to the command line from Apple Script and he was asking how about the other way around. Yes, you can. You can write scripts in the terminal. You can also just go directly from the terminal. I believe, let's just open that up here. Not Internet Explorer. CPT is the extension for Apple Script, is what he said there. Basically, I believe it's the OSA line, if I remember correctly, that lists the normal scripts that are listed, what you can use for the scripting system, Apple Script and generic scripting system. You can compile scripts in the terminal, although I will admit that I have not really messed around that myself too much. I do prefer the Apple Editor, Script Editor program just because I usually suck at typing, so I make lots of mistakes. But it is possible to go back to back, you know, compile something in the editor that can execute terminal commands. Pardon me, that's something that terminal I can do Apple Scripts. So that is what I can do that. Any other questions? Pardon me. OSA script. Yes, any other questions? In terms of accessing, okay, the question is accessing applications. Okay, there's actually a lot of different general commands that a lot of the applications hold, so when you go to open up something, let's just go back to, let's say I choose this. In this dictionary that comes up, we basically have a list of the subset of the standard commands which are basically the same for the whole system. Then each one has its own separate ones that might not be the same on all systems, specifically Apple System Profilers, the report one on here. But you can access a number of general ones that are the same for the whole system. Is that pretty much what you're wondering about? Okay, in terms of security, accessing between two applications, you can use it to access different applications, causing them to run whatever you want, unless the permissions are such that the user that's logged in and running the Apple Script cannot run that. So for the most part it is open that you could run between two applications and that does have some security issues and inherent to that. I think. Yes, you can run Scripts as different users. You can, right now the terminal commands are a little shoddy still in OS 10, just the shell that you get that Apple Script executes with is not, you know, it's not gonna be a full-fledged command of the system. There are ways I believe, I'm not positive on this, to pass the password along with the shell commands, you can change, you know, switch users and execute something like sudo or whatever you wanna do there, so you could execute something as root yes. Any other questions? They're very far. Okay, he was asking, do you have to set an implicit quit at the end when you'd like, say, open up the Apple remote or the Apple system profile over there. When it accesses it, for the most part, because I was accessing it for its dictionary, it opened it up. If you're running a program that would access it and just get some information of it, sometimes it won't even open up the program unless it needs to actually access something in terms of opening, probably it's got lost there. Basically what you do there is, yes, sometimes you do need an implicit quit if you're going to want the program to close, but there are, I believe, a number of scripts that you can run for the most part where it would not even open that application, it would just pass that argument right through to wherever you want it to be sent to. Any other questions? Okay, over there. The question is, can you embed Apple script into an email? You can attach Apple script, but as of now, even with the mail program, you can't actually embed something in the email that would run. You can, however, have an Apple script that, say, would find a certain email. You could have it be pulling the mailbox or it sees that email code execute then. So if something on the system already could have something along those lines, yes. Anybody else? Back there. The question was, are there any known experts for Apple scripts with Apple events? You said? Okay, I actually didn't catch that last part there. Okay, remote Apple events. Right now there's none that I know of, although if you're wanting remote access to your system in any case, there are definitely some security issues there. What he's talking about there, I'll just show you real quick, is under the network, no, pardon me, not network users. Oh, I'm not confusing myself now. Sharon, okay, yes, it's been a long day, I drove for 33 hours to get out here. Okay, you can allow remote login as well as allow remote Apple events. And allow users to send to Apple rest your computer. Yes, that could be a security issue because you could send anything from a shutdown command. Your core of Apple script is Apple events, which, so basically any Apple script you could do, you could do with an Apple event. It's a little bit low level in terms of the programming for that. But yes, that would definitely be a security issue. I do not know if any experts per se know that are out for that. Okay, anybody else have any questions? Or are we all ready to go drink and party tonight? All right, well, I'll let this out, but I am moving to be available for any questions if anybody has any. I'll be around here all weekend. I'll probably just be going over to the seller's area right now, vendor's area, just.