There is a bunch of vulnerabilities that some still is and some was useful that you can or could use on the website but I haven't seen any that can actually gain admin rights on the server, the ssh port 22 is open but what are the odds of cracking in there unless you know the username of the ssh server that is a valid admin/root user. There should be ways and if there isn't yet then there will eventually be, but those methods will just be countered with security patches and stuff like that.
Why would you even run a port scan on facebook? I hope you went through a proxy. I don't think this is what the original post was about. It was about a "hack" to be able to see who viewed your profile.
I did not use a proxy as there is no need, and facebook hack can mean anything from hacking the actual server or the website. I prefer to play around with the server but as I said the only possible way I can see that a person will successfully gain access to the server is called smashing the stack. About seeing who checked your profile and how often I don't believe there is a app for that, so if your thoughts for that is huh? then go do some reading. I was only discussing it more in depth.
First, there is a need for a proxy, even if you don't intend to break in. Think of it like you going to your local government branch after closing and trying all the doors and rattling all the windows. It doesn't matter if you don't intend to get in, the people watching the security tapes will still take you for a thief. lol the terminology of "smashing the stack" isn't used much except in literature, like the original publication that first notified the public of the concept, titled "Smashing the Stack for Fun and Profit". Most hackers just call it a buffer overflow. And no, not all exploits/vulnerabilities depend on buffer overflows. Many don't. nice way to talk to the admin. There can't be an app unless facebook admins grant it access to their logs.
Fisrt off, I wasnt talikng to the admin as I have great respect for shabbir, secondly buffer overflow or smashing the stack causes a program to crash or operate incorrectly, the aim is then to inject executable code into the running program and then to try and take control of the process. It is a very old method but it still works on some systems. All I meant by that is to try that with the facebook server which is very dangerous in my eyes as you are very likely to get caught. I hope you understand me now?
i've haerd some XSS bug which was fixed real quick by facebook guyz, it was the same bug found in orkut it was something as follows: inserting malicious javascript into the "captions" of your pitcure
:p The aim isn't to inject executable code into the program. It's to overwrite a pointer/return address on the runtime stack so that it points to the memory address where your instructions are stored, so when the program pops its last method/function off the stack, it returns to your instructions and executes them instead of returning to where the method was called from. Most buffer overflows are used for local privilege escalation, but every now and then they can be exploited remotely on web applications (like what you're talking about) or other connected programs (like p2p clients or internet browsers). They mostly work on programs that were coded in c/c++. You don't try them on servers themselves. You look for them in applications/OS's the servers are running. Finding a site that uses a web application that is vulnerable to buffer overflow is pretty rare, so if you meant hack facebook by buffer overflow on a web application, you can pretty much forget about it. They'll have all their applications updated. If you meant root their server with a buffer overflow, that's more possible, but incredibly stupid to try without taking many precautions first, and not worth the trouble just to see who viewed your profile. The best way to hack a social networking site is by using xss/js injections in vectors they haven't thought to filter or social engineer/keylog an admin. @indiansword, I remember hearing about that. If I'm correct, it was not even a matter of days before it was fixed, but several hundred thousand accounts were still compromised because of it. I wonder how long it would have gone undetected if whoever found it hadn't made it so obvious.
the person who found i think was probably new to XSS so experienced users understood it so quickly. The founder directly put the script to steal the cookies, instead of that he should have injected an IFRAME and hide the script and steal the cookies with it. If he'd have done as i said then he'd have got chance to hack many more accounts and facebook people wouldnt even come to know about it.
i read at this link http://en.wikipedia.org/wiki/Stack_buffer_overflow that its possible to inject executable code with stack buffer overflow... I also heard about that XSS thing and I think it was possible to use greasemonkey in mozilla.
I don't see the idea of injecting executable code anywhere in that article. It just says you inject code that is designed to execute code, which is what I said above.
this is what I qoute from that article: "inject executable code into the running program" now I see that as injecting executable code, maybe I have it wrong... Help me on the right path as to what that means please. Don't get me wrong as I came to this site for the purpose of learning.
I think as far as facebook is concerned there is one more vulnerability in while adding some user as a friend to inject XSS into it. I am not really sure but i think there is some. I m in office so cant open facebook right now.
I see what you mean. The difference is that while injecting executable code by way of writing past an array can be done, it is not essential to the process, and you still need to overwrite the return address of the current method to point back to that executable code in order for it to run. In general, all you need to do in order to declare a buffer overflow is overwrite that address to point to whatever you want. For instance, you can make it point to code or a shell script you've got somewhere else on the box (assuming the vulnerable program is written in a language like C so it can access any memory address it's pointed to) and you'll still have a working bof exploit. That's why I said injecting executable code wasn't the goal of a buffer overflow. It's just a way of using a buffer overflow, not an essential component of one. Sorry if I wasn't very clear earlier.
I found something new just now, you can read about it at http://infosecurity.us/?p=4928 don't know if the vulnerability has been fixed....
Nice find. December of 08? Not valid anymore. Facebook usually fixes holes within a few days of their discovery.
