Here’s a presentation, “Learning Program Behavior Profiles for Intrusion Detection“, intended to talk about a few neural network approaches to the problem of detecting anomalous behavior in a network setting. The material is taken from a 1999 paper, of the same name as the post, by Anup Ghosh, Aaron Schwartzbard, et al. from Reliable Software Technologies Corp., under Usenix. The truth is there are many other alternate machine learning approaches alive and well out there not covered in this paper that have more mathematically dependable results, while neural nets work almost magically without too many people understanding why, lacking the sufficient proofs. However, I think there is still value in understanding older methods even though a decade has been enough to cover the nets in dust. Another point is that though this group does present well above average results in its paper which demonstrate that the method can be used for less critical networks, they are not acceptable for companies and orgs that don’t have room for errors.
The original paper can be found listed under Usenix.
If one were the administrator/developer of a service that requires users to supply credentials, can you picture the amount of data one will receive if you:
- Use an email as the username.
- Provide tight restrictions on the password creation (Decent minimum length, requirements of alpha+digits)
- Log unsuccessful logins and password changes
I’m sure you can see where I’m going with this, but if the service is popular the users will always first try their other common passwords until they list their entire mental list of every password they generally use (which most likely do not match the ones they came up with to register with the site), thus collecting credentials of other services the users are members of (A few google searches of their emails, or just the user-name part of the email will reveal most services they are members of.)
I am going on the basis of the idea that most people (or the ones I’ve spoken to) believe that some data like failed authentication attempts, passwords that were changed, and accounts that were removed are erased from existence after the event, but in today’s world of virtually limitless storage and facile logging mechanisms, why wouldn’t administrators log everything that goes through their systems?
I have never heard of such a harvest vector and was thinking of ways to protect from this. Using a password manager like PassSafe can reduce failed attempts and randomly generate a fresh password, but careful attention has to be paid to keep that database secure. Whichever method you use, the goal is to not supply data to a third (or second) party without them needing-to-know.
(edit: I have been known to be crazy in the past, this may have been one of those times)
This is the 2nd part in a multipart series on Privacy. Part 1 is here.
In Part 2 of my series on Privacy, I’ll talk about an issue that’s just a tad bit scary to me. Without introducing it just yet, let’s take a look at some of the current issues with identity theft and what Mike’s solution in the last article solves and what it doesn’t.
Continue reading ‘Solving Privacy in the Information Age, Part 2′
A mailing list for our re group was created. If you are truly serious about joining, please write to me (yan@isis.poly.edu) and I will add you. The list is meant to exchange ideas, topics, materials, and post challenges for other subscribers (along with tips).
The list is going to be informal and of average volume.
One of the large internet service providers has a new commercial advertising its broadband product which now comes with “FREE SECURITY.” Finally, an end to our concerns about computer security and identity theft! The product includes a firewall, anti-virus, anti-spam, and pop-up blocker but most importantly, peace of mind. Keeping information private on the internet is no longer something to concern yourself with, or at least that is the idea they are trying to sell.
Apparently, ISP’s have completely given up on educating users. While teaching people how to use their computer safely does seem like an impossible task I believe selling this idea of ’security in a box’ actually does more harm than good. Although, I hate the idea of spreading fear, a little dose of paranoia would at least keep everyone mindful of what information they distribute.
Continue reading ‘Free Security’
Suppose you have an email that claims to be from a particular web destination (”Chase Bank”, “eBay”, “Middle of Nowhere Bank”, etc.) and directs you to a url purportedly at that location. Suppose further that you possess the capability of extracting both these pieces of information from any email if the email falls into said category. So you have
A. Purported Web Destination of Email
B. URL Email is Instructing you to Follow
So here is an open-ended question: how can you use existing network services to determine that B is an authentic location in A? A subset of existing spam filtering heuristics work quite well towards this end (visible text of html link does not match actual url, href attribute is expressed as IP address, etc.), but using network services opens of a new dimension of validation, one in which the data gathered for heuristic application are outside the control of the email’s sender. So post any ideas you have. Kurt asked a similar question at an SFS meeting last semester pertaining to the parasitic storage project. Whereas his aim was using network services for caching, my aim is using them for source authentication. Thanks and please keep the discussion focused, at least primarily, on this particular method.
I just learned from the Matasano guys that NYSec 5 will be on February 19. Mark your calendars!
NYSEC 5 is Feb 19th, 2007. A Monday. 6:30PM. We’ll stay until people get tired of hanging out. We’re guessing 2-3 hours. Located at Pound and Pence. That’s downtown Manhattan, on the corner of Liberty and Nassau. If you don’t like it, show up and suggest somewhere else!
We are usually upstairs by the pool table.
For the uninitiated, NYSec is a casual get together of a bunch of InfoSec people that happens as often as they feel like it. I wasn’t able to make the first 4 gatherings (grrrr) but I’m definitely going to this one! See you there!
Over at Mokka mit Schlag Elliotte Rusty Harold (he teaches Java/XML at Poly) is asking whether SQL is the only language with injection attack vector? What about XML/ XPath, JSON, etc. Is there a comprehensive attack-tree for injection attacks? See if you can answer some of these questions.
Given that we are a group of students that want to be actively engaged in “security research”, I often ponder: What does the term “security research” mean to you? Some of us are into reverse engineering, some of us are into language-level security, some of us are into network-level detection and prevention. When I speak to anyone working in any of these fields, they will usually light up and go off on how the problem they are working on is a major component in solving problem X and problem X is one of the top reasons why the state of security is as poor as it is. Success is no longer protecting C, I, and A, but making executables with randomized address spaces, but creating IPS that block anything suspicious, or virtual machines that sandbox as much as possible.
I guess what I am trying to say is people sometimes lose track of the larger picture while working on specific problems. While specifics are arguably most important in correcting problems, people should not loose track of the larger picture.
Comments?
I will try to keep this to the point. Auto-completion on the terminal is something we all love and it makes using a UNIX system and running commands far more pleasant. Most shells can auto-complete path names, binary names, and built in commands. Bash goes further and supports auto-completing user names, hosts and a few other trivial things. No shell that I know of has ever attempted to auto-complete the arguments that the binaries take. Leaving out support for this makes sense, as there is no common way for a binary to store the arguments it can take inside the program binary, and it is bound to be a porting nightmare.
Keeping this in mind, I realized that almost every single UNIX binary gets its arguments from the shell in a standard, POSIX-compliant way. The getopt libc function call parses the input from the shell in to usable internal flags. If one were to peek inside what each binary gives to getopt(), one would find out all arguments it is expecting to take and provide more insight about the executable! This is what I have done and what the remainder of the post is about.
This is what my previous post related to. Now I realize this is a slightly silly goal. My primary reason for doing this is to learn the techniques I’ve used to get there, which I simply could not learn without experimentation and a concrete goal in mind. The way this problem was attacked as follows:
Continue reading ‘Prodding programs’
In the last few weeks, I have been needing to understand a lot of existing source code. People, including myself, often try to reverse-engineer binaries and not pay much attention to reverse-engineering available code, if that’s the proper way to call it. While not reverse-engineering in its core, analyzing source code tends to tickle similar parts of the brain as when reverse-engineering binaries. This post is a short description of the tools and techniques I’ve been using and hope to receive suggestions to techniques I have been missing.
The tool in question is ltrace, which I believe is a doing of mostly the Debian project (I can be wrong), with a port to FreeBSD which is what I have been using. I have spent enough hours trying to just read source code, using grep to look for where to look for my next step.
Read on for descriptions!
Continue reading ‘Tools for implicit code understanding’
I think one of the biggest problems to privacy is dumpster diving. Sure enough you are suppose to use a crosscutting shredder to shred the paper before you throw it out and everything but… have you ever received these address stickers from– who are they: Solon Cancer Society– or others? (I am all for supporting the development of a cure for cancer and everything but let’s stick to the moral of the story here, shall we?). Have you ever tried running those address labels though a crosscutting shredder? That’s right, the sticky labels will jam up your shredder until it smokes to death.
What I think would be a useful public policy is to mandate the junk mailers to put all personal information on a single, easily identifiable paper (I would go as far as to suggest use fading ink that will disappear after a certain date, but I am not going to go that far today) so that it is easy for us, the general public, to destroy our private information, which you have gathered without our permission in the first place. Why can’t SFS/ISIS send out a letter to our State Senators about this? Isn’t it worth it?
The UbuCon is an unconference for Ubuntu users, developers, and sysadmins taking place on February 16th at the new Google offices in Manhattan. A few people from ISIS will be there to represent the interest of security in Ubuntu’s future development and hopefully moving improvements like GCC proactive security measures, encrypted LUKS partitions, and main inclusions of Seahorse and gaim-otr up to a higher development priority. If you’d like to join us add your name to the RSVP list and we’ll see you there (it’s free!).
This is a little late (registration is over), but no less than 7 of us are going to ShmooCon in Washington DC this March 23-25. If you were lucky (and smart!) enough to get a ticket, we’ll see you there!
(edit: I have been known to be crazy in the past, this may have been one of those times)
Nitesh recently gave a presentation on his concerns that the privacy of our personal information and the privacy of the data that we generate on the web (google search for example) is not being adequately protected and that he has been spending a small amount of time researching technical innovations which could help balance this deficiency.
If you are in that small minority of people who know who data brokers are, who know how private investigators are able to perform their jobs, or who know the exact wordings and loopholes and the laws supposedly protecting our privacy, then you are no doubt worried that the abstract feeling you call “privacy” may have gotten left behind in the 20th century, never to return. If you’re one of the people in our ISIS lab like Nitesh, you’re probably dying to come up with a brilliant solution that will solve this problem like every other that you come across and conquer.
But is it possible to use technology to solve the existence of an industry or solve the already widely spread personal information flowing through companies databases?
Continue reading ‘Solving Privacy in the Information Age, Part 1′
Loading ...
Recent Comments