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.
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.
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’
Loading ...
Recent Comments