Search the Community

Salutare! Dacă o ardeți pe freelancereală și le aveți cu Ionic/Firebase sau React Native/Xamarin și/sau alte combinații de stack-uri în special pe tehnologii mobile hibride și vreți să colaborăm, dați-mi un PM. Mulțam!

Custom rom sau stock? Firmware schimbat? Overclock? Ce launchere/gadgets folositi? Un screenshot la ecran? Sau dati voi alte detalii intr-un reply. Incep eu. HTC ONE M8, custom rom de pe xda, fara oc, fara laucher de pe playstore (Love HTC UI), niciun gadget, ss n-are rost ca n-am nimic special facut pe ecran si cam atat.

Asadar dispun de 500 Lei si as vrea sa-mi cumpar un telefon. M-am uitat un pic pe OLX si Okazii dupa un Iphone 5s si am gasit ceva pana in 5 milioane. M-am uitat dupa Iphone 5s deoarece am avut anul trecut unul primit de la cineva apropiat doar ca nu am apucat sa ma bucur de el decat o luna deoarece mi-a fost furat . Sincer am ramas un pic fascinat de telefon si mi-a placut destul de mult de asta as alege tot IOS. (Sunt un pic dezamagit de durata bateriei) Ma gandesc si la Android deoarece ai mai multa libertate si sincer pana acum nu cred ca am avut o versiune de android mai mare de 4 . Dar daca aleg Android ce sa-mi iau ? HTC ? Samsung ? Ce vreau de la telefonul pe care o sa-l aleg ? -Sa ma tina bateria. Asta e cel mai important. -Sa se auda bine ( pentru muzica, presupun ca asta tine mai mult de casti) -Sa aibe un design placut. -Sa se vada clar. -Macar 10 gb memorie interna. Presupun ca daca o sa iau Android o sa ma pot uita si la un film pe el... de asta am spus ca vreau sa ma tina bateria ceva mai mult deoarece la Iphone daca ascultam muzica vreo 4 5 ore se ducea pe 0 bateria. Sincer vreau sa fiu un pic convins ca merita Android peste IOS. Daca as dispune de vreo 500 euro in loc de 500 Lei sunt sigur ca as merge pe IOS doar ca in limita banilor pe care ii am cred ca o sa aleg un Android. Nu prea sunt la curent cu performanta acestor smartphone-uri intrucat nu prea m-a interesant si de aceea cer ajutorul vostru. Daca mai sunt si alte sisteme de operare care exceleaza pe piata la ora actuala si exista smartphone-uri pe care ruleaza si chiar sunt bune, imi puteti recomanda!

Cum vshare nu mai functioneaza de cateva zile am inceput sa caut alternative pentru unjailbreak. 25pp nu mai functioneaza, si am mai incercat cateva siteuri de genul... Are idee cineva, daca mai exista vreunul functional? Ma intereseaza cel mai mult Navigon.

The hacker says this demonstrates that when organizations make hacking tools, those techniques will eventually find their way to the public. In January, Motherboard reported that a hacker had stolen 900GB of data from mobile phone forensics company Cellebrite. The data suggested that Cellebrite had sold its phone cracking technology to oppressive regimes such as Turkey, the United Arab Emirates, and Russia. Now the hacker responsible has publicly released a cache of files allegedly stolen from Cellebrite relating to Android and BlackBerry devices, and older iPhones, some of which may have been copied from publicly available phone cracking tools. "The debate around backdoors is not going to go away, rather, its is almost certainly going to get more intense as we lurch toward a more authoritarian society," the hacker told Motherboard in an online chat. "It's important to demonstrate that when you create these tools, they will make it out. History should make that clear," they continued. Cellebrite is an Israeli firm which specializes in extracting data from mobile phones for law enforcement agencies. The company's flagship product, the Universal Forensic Extraction Device (UFED), typically comes as a small, laptop-sized device, and can pull SMS messages, emails, and more from thousands of different mobile phone models. The investigator needs to have physical access to the phone to analyze it. A Motherboard investigation found that US state police and highway patrol agencies have collectively spent millions of dollars on Cellebrite technology. The hacker claimed to have taken the newly released data from a remote Cellebrite server, and said they had extracted them from UFED images. They told Motherboard that the files were encrypted, likely in an attempt to protect Cellebrite's intellectual property, but that they managed to bypass the protections. The hacker's ASCII art, which reads "backdoorz." "The ripped, decrypted and fully functioning Python script set to utilize the exploits is also included within," the hacker wrote in a README file accompanying the data dump. The hacker posted links to the data on Pastebin. It's not clear when any of this code was used in the UFED. Many of the directory names start with "ufed" followed by a different type of phone, such as BlackBerry or Samsung. In their README, the hacker notes much of the iOS-related code is very similar to that used in the jailbreaking scene—a community of iPhone hackers that typically breaks into iOS devices and release its code publicly for free. Jonathan Zdziarski, a forensic scientist, agreed that some of the iOS files were nearly identical to tools created and used by the jailbreaking community, including patched versions of Apple's firmware designed to break security mechanisms on older iPhones. A number of the configuration files also reference "limera1n," the name of a piece of jailbreaking software created by infamous iPhone hacker Geohot. He said he wouldn't call the released files "exploits" however. Zdziarski also said that other parts of the code were similar to a jailbreaking project called QuickPwn, but that the code had seemingly been adapted for forensic purposes. For example, some of the code in the dump was designed to brute force PIN numbers, which may be unusual for a normal jailbreaking piece of software. "If, and it's a big if, they used this in UFED or other products, it would indicate they ripped off software verbatim from the jailbreak community and used forensically unsound and experimental software in their supposedly scientific and forensically validated products," Zdziarski continued. A spokesperson for Cellebrite told Motherboard in an email: "The files referenced here are part of the distribution package of our application and are available to our customers. They do not include any source code." He added that the company monitors new research from academia and the information security community, including "newly published forensic methods, research tools and publicly documented issues, including "jailbreaks," which enable platform research." Cellebrite develops methods for gaining access to phones that do not change or alter data on the device, the spokesperson continued. He wrote that Cellebrite's technology is used to combat child trafficking and exploitation, sexual assault, murder, and drug and gang crime. In its statement released in response to the initial data breach, Cellebrite only mentioned that "basic contact information" of its customers had been stolen. But as Motherboard reported at the time, the cache of data included much more. In early 2016, the Department of Justice and Apple entered a fierce legal battle, in which the department tried to legally compel Apple to build a custom operating system that would allow investigators to bypass security protections on an iPhone. A concern at the time was that, if such an operating system was created, it could leak and become public. Although these dumped tools may not be the most sensitive—Cellebrite keeps its techniques for cracking more recent iPhones inhouse—they do demonstrate that those worries were justified. Researchers will likely now dig through the content for any interesting attacks or findings. "@FBI Be careful in what you wish for," the hacker's message reads, before signing off with a piece of ASCII art, which says "Backdoorz." https://motherboard.vice.com/en_us/article/hacker-dumps-ios-cracking-tools-allegedly-stolen-from-cellebrite

Reflecting on Recent iOS and Android Security Updates By zLabs Friday, Feb 12 2016 at 04:00 By: Zuk Avraham, Joshua Drake, Nikias Bassen from ZimperiumzLabs The last thirty days proven to be yet another exciting time for the mobile security ecosystem. Apple and Google released updates for their respective mobile operating systems that fix several critical issues — including some in the kernel that may be exploited remotely. Last Monday, Google released its monthly Nexus security bulletin. We are thrilled to see that the tradition that started after Stagefright’s discovery is a monthly routine now and other vendors are following suit (including Samsung). Blackberry indicated that they are very serious about security issues as well. We welcome Android vendors to reply to the ZHA thread to update the carriers on their plans to release an update addressing the February fixes by Google. We’ll take a closer look at the bulletin and some of the issues fixed later in this post. iOS 9.2.1 In the recent iOS update (9.2.1 – published on January 19th), Apple patched what we initially classified as 7 critical, 3 high, and 2 moderate severity vulnerabilities. These include at least five remotely exploitable vulnerabilities (CVE-2016-1723 through CVE-2016-1727) and at least one critical local kernel vulnerability triggerable from userland with low privileges (CVE-2016-1719). CVE-2015-7995 also appears to be exposed remotely, but determining exploitability will require further investigation. The following graph and table summarize the mentioned issues. CVE Component Impact Severity CVE-2016-1717 DiskImage Kernel Code Execution High CVE-2016-1719 IOHIDFamily Kernel Code Execution Critical CVE-2016-1720 IOKit Kernel Code Execution High CVE-2016-1721 Kernel Kernel Code Execution High CVE-2015-7995 libxslt Remote Code Execution Critical CVE-2016-1722 syslogd Code Execution w/EOP High CVE-2016-1723, CVE-2016-1724, CVE-2016-1725, CVE-2016-1726, CVE-2016-1727 WebKit Remote Code Execution Critical CVE-2016-1728 WebKit CSS Privacy Leak Moderate CVE-2016-1730 WebSheet Privacy Leak Moderate Android The February Nexus Security Bulletin encompasses 10 security issues including 5 critical, 4 high, and 1 moderate severity vulnerabilities. This includes 2 remotely exploitable kernel code execution vulnerabilities (CVE-2016-0801, CVE-2016-0802) and 2 remotely exploitable vulnerabilities exposed through Android’s mediaserver (CVE-2016-0803 in Stagefright, CVE-2016-0804). You can see the bulletin in its entirety here, but the following graph and table summarize the disclosed issues. CVE Component Impact Severity CVE-2016-0801 CVE-2016-0802 Broadcom Wi-Fi Driver Remote Code Execution Critical CVE-2016-0803 CVE-2016-0804 Mediaserver Remote Code Execution Critical CVE-2016-0805 Qualcomm Performance Module Elevation of Privilege Critical CVE-2016-0806 Qualcomm Wi-Fi Driver Elevation of Privilege Critical CVE-2016-0807 Debugger Daemon Elevation of Privilege Critical CVE-2016-0808 Minikin Denial of Service High CVE-2016-0809 Wi-Fi Elevation of Privilege High CVE-2016-0810 Mediaserver Elevation of Privilege High CVE-2016-0811 libmediaplayerservice Information Disclosure High CVE-2016-0812 CVE-2016-0813 Setup Wizard Elevation of Privilege Moderate While privilege escalation issues can be used by local apps or by remote exploits, attackers still need to gain initial code execution on the device to exploit those. With SELinux being enforced more strictly, kernel vulnerabilities are becoming more important (see our 2016 predictions []). Fortunately for the attackers (and unfortunately for us), we suspect that several additional security bugs lurk within Android device specific drivers and kernels. Further, the value of information disclosure vulnerabilities should not be underestimated. For example, CVE-2016-0811 may help attackers defeat security mitigations such as ASLR by leaking address space layout details. Combining several less severe issues together in a chain allows attackers to accomplish full compromise reliably. We expect this practice to remain a trend for the foreseeable future. As promised, Google updated the advisory within 48 hours with links to the AOSP commits that fixed the issues. It’s Interesting that several issues correspond to commits first released to the public in January. Unfortunately, this form of partial disclosure tends to give attackers that monitor code pushes a head start — especially when targeting 3rd party Android devices. On the bright side, that means up-to-date Nexus users were protected for an extra month before the official public disclosure. Let’s take a closer look at the relevant code changes for each issue. Analyzing the bugs The Broadcom Wi-Fi Driver remote kernel code execution vulnerabilities are the most interesting bugs disclosed this month. Although Google did not link to any commits for these two vulnerabilities, the Linux kernel is released under the GNU Public License which requires that source code be made available publicly. Shortly after the release, Security Researcher Ralf Philipp-Weinmann what we believe to be the related commits. The changes most relevant to CVE-2016-0801 and CVE-2016-0802 follow. We performed a cursory analysis of CVE-2016-0802 (full diffhere) and determined that several new validations were added checking packet lengths. However, we were unable to confirm that any ill effects would result from using nefarious values for the now-validated parameters. CVE-2016-0801 tells a different — and quite scary — story. See the following commit details. As you can see, the committer himself declared these issuesexploitable buffer overflows straight away. Looking at the code sheds additional light on the subject. drivers/net/wireless/bcmdhd/wl_cfg80211.c [diff]: In both cases, validation is added to prevent copying more data than the size of the destination buffer. Further, both destination buffers are located on the kernel stack. Because the stack contains crucial items such as the return address and — in the case of the kernel — the thread_info structure, exploiting such overflows is thought to be much easier. The next logical question is if and how these areas of code can be reached by an attacker. The bulletin states, “These vulnerabilities can be triggered when the attacker and the victim are associated with the same network.” However, our quick analysis of the code suggests (unconfirmed) that it may be possible to trigger these vulnerabilities without being associated at all. The following code is responsible for initializing a table of handlers that is used when various events occur. ==== 9765 static void wl_init_event_handler(struct bcm_cfg80211 *cfg) … 9781 cfg->evt_handler[WLC_E_ACTION_FRAME_RX] = wl_notify_rx_mgmt_frame; 9782 cfg->evt_handler[WLC_E_PROBREQ_MSG] = wl_notify_rx_mgmt_frame; 9783 cfg->evt_handler[WLC_E_P2P_PROBREQ_MSG] = wl_notify_rx_mgmt_frame; … 9790 cfg->evt_handler[WLC_E_PFN_NET_FOUND] = wl_notify_pfn_status; ==== The first three presented entries correspond with the first change in the diff. The wl_notify_rx_mgmt_frame function callswl_validate_wps_ie, which contains the buffer overflow. (and also has other callers that have not been investigated). The event IDs (the part in brackets) include probe requests and action frames. This is quite interesting because probe requests are one of the very first packets sent during association. If an Android device enabled the portable hotspot feature, this vulnerability could potentially be exposed to everyone within range of the Wi-Fi radio. The final presented event handler entry deals with scheduled scans. The wl_notify_pfn_status function callswl_notify_sched_scan_results, which contains the buffer overflow. Although we are still investigating, this functionality also sounds a lot like it could expose the vulnerability to any attacker within Wi-Fi range of a vulnerable device. After the Broadcom Wi-Fi driver, the next most interesting vulnerabilities in the bulletin relate to a subject near and dear to our hearts — Android’s media processing. CVE-2016-0803 fixes two integer overflows in libstagefright that were classified as critical RCE. The bugs existed within the SOFTMPEG4Encoder and functions. In both cases, the issue is an integer overflow occurring when dealing with multiplication involving the mWidth and mHeight parameters. This overflow was patched with two commits [] [2] that add a sanitization check prior to allocating 1.5 x mWidth x mHeight bytes in the process’ heap. The relevant changes follow. CVE-2016-0803 affect devices running: Android 4.4.4, 5.0, 5.1.1, 6.0 and 6.0.1 This issue is not without caveats, however. Since it exists within a codec, the victim would need to play back a malicious media file for an attacker trigger the vulnerability. While not all possible ways of accessing media have been investigated, Google Chrome on Android blocks automatic playback of HTML5 video by default (see here). As with most things Android, your mileage may vary depending on the specific device or application dealing with rich media. We encourage developers (especially those working on devices and browsers) to investigate and reconsider the decision to enable auto-play functionality. Another quirk with this vulnerability is that it appears to live within encoder functionality. It’s not presently clear how an attacker would exercise an encoder remotely, but we can’t rule it out either. The other critical RCE, vulnerability in mediaserver that is not related to libstagefright is CVE-2016-0804. It affects devices running Android 5.0, 5.1.1, 6.0 and 6.0.1. It was fixed by re-initializing the mDrmManagerClient member variable to NULL when cleaning up withinNuPlayer::GenericSource::notifyPreparedAndCleanup as shown below. frameworks/av / media/libmediaplayerservice/nuplayer/GenericSource.cpp Fixes of this nature often prevent using stale data later in the lifetime of the process. One of the security researchers on the team of people that reported the issue that this issue was a use-after-free problem triggered when processing a DRM-protected media file. Presumably the attack vector here is media within the browser. It’s not clear if playback is required here, but given the name of the vulnerable function it’s probably not. Conclusions To summarize, both iOS and Android are improving their security from month to month but both OSes still expose users to remotely exploitable bugs. It wouldn’t come as a surprise if more such vulnerabilities were discovered already or in the future. From a preliminary analysis of the bugs, the security of most available devices not running the latest version is alarming. Determined attackers such as professional malware authors and nation states couldn’t be happier with smartphones’ lack of updates and the amount of remotely exploitable vulnerabilities. Sursa: https://blog.zimperium.com/reflecting-on-recent-ios-and-android-security-updates/

Salut , tocmai am cumparat un iphone 4S si fostul propietar a uitat sa isi scoata contul de icloud , ma gandesc ca trebuie sa existe vreo metoda prin care sa pot sterge contul lui de icloud ca sa il pot adauga pe al meu , precizez faptul ca nu mai reusesc nicidecum sa dau de fostul propietar ca sa isi scoata contul si versiunea iOS instalata este 9.1. Se poate cu un program sa sterg contul de icloud sau sa ii fac un update/downgrade la iOS ca sa sterg contul ?

Cum de pana acuma nu a aparut nicio sectiune sau vreun sub-forum dedicat sectorului de Android / IOS Development and Programming ? @quadxenon Done

Remote code execution for some, denial of service for the rest of us Cisco has issued a string of patches for 16 faults including a fix for a possible remote code execution in its IOS and IOS XE routing software. The patches address a generous dollop of security conditions caused by faulty queued packets. One flaw, rated severity 8.3, allows attackers to gain remote code execution in IOS XE by sending a crafted packet that allows code to run on affected boxes. Attackers could also send crafted packets to trigger denial of service. "A vulnerability in the AppNav component of Cisco IOS XE Software could allow an unauthenticated, remote attacker to cause an affected device to reload and may allow arbitrary code execution on the affected system," Cisco says in its advisory. "The vulnerability is due to improper processing of crafted TCP packets. An attacker could exploit this vulnerability by sending a crafted TCP packet that needs to be processed by the AppNav component configured on an affected device. An exploit could allow the attacker to cause an affected device to reload or execute arbitrary code in the forwarding engine." Another fix addresses flaws that allow attackers to spoof Autonomic Networking Registration Authority response thanks to lax message validation "A successful exploit could allow an attacker to bootstrap a device into an untrusted autonomic domain, gaining limited command and control of the AN node, causing a denial of service condition and disrupting access to the legitimate autonomic domain," Cisco says . Further vulnerabilities coupled in that advisory lead to denial of service conditions. The Borg also closed off a medium-severity vulnerability (CVE-2015-0769) in the IOS XR carrier software rated 5 can be easily exploited by attackers sending a packet that would thanks to IPv6 extension headers trigger denial of service. It says this occurs because the headers are not typical of normal operation and says there are no work-arounds for the flaw meaning affected systems will require the patch. "A vulnerability in the IP version 6 processing code of Cisco IOS XR Software for Cisco CRS-3 Carrier Routing System could allow an unauthenticated, remote attacker to trigger an ASIC scan of the Network Processor Unit and a reload of the line card processing an IPv6 packet," it says in an advisory. "The vulnerability is due to incorrect processing of an IPv6 packet carrying IPv6 extension headers that are valid but unlikely to be seen during normal operation. "An attacker could exploit this vulnerability by sending such an IPv6 packet to an affected device that is configured to process IPv6 traffic." That exploit can cause a reload of the line card triggering repeated denial of service through transit traffic or data destined for the device. Affected Cisco IOS XR versions include 4.0.1; 40.2; 4.0.3; 4.0.4; 4.1.0; 4.1.1; 4.1.2, and 4.2.0. IOS XR Release 4.2.1 and later are not affected. Source

Document Title: =============== iClassSchedule 1.6 iOS & Android - Persistent UI Vulnerability References (Source): ==================== http://www.vulnerability-lab.com/get_content.php?id=1494 Release Date: ============= 2015-05-13 Vulnerability Laboratory ID (VL-ID): ==================================== 1494 Common Vulnerability Scoring System: ==================================== 3.4 Product & Service Introduction: =============================== Couldn`t you remember your lesson time? If you are a high-school student or a university one, you will be able easily to consult your weekly guide, using this App on your iPhone. You could choose your sujects following your plan and give them a colour for marking them at the end of the week. (Copy of the Homepage: https://play.google.com/store/apps/details?id=com.idalmedia.android.timetable&hl=it & https://itunes.apple.com/en/app/orariolezioni/id542313616) Abstract Advisory Information: ============================== The Vulnerability Laboratory Research Team discovered a persistent input validation vulnerability in the official iClassSchedule v1.6 iOS & Android mobile web-application. Vulnerability Disclosure Timeline: ================================== 2015-05-13: Public Disclosure (Vulnerability Laboratory) Discovery Status: ================= Published Affected Product(s): ==================== Tel.Net srl Product: iClassSchedule - iOS & Android Mobile Web Application 1.6 iOS and 4.6 Android Exploitation Technique: ======================= Remote Severity Level: =============== Medium Technical Details & Description: ================================ An application-side validation vulnerability has been discovered in the official iClassSchedule v1.6 iOS & Android mobile web-application. The vulnerability allows an attacker to inject own script code as payload to the application-side of the vulnerable service function or module. The vulnerability is located in the `Aula (name input)` values of the vulnerable `iClass Calender` module. Local attackers are able to manipulate the `Aula name` input to compromise the `Calender Index` module. The execution point of the script code occurs on the application-side in the listing module by the manipulated name context field. The Apple iOS and Google Android mobile application versions are affected by the vulnerability. The security risk of the application-side web vulnerability is estimated as medium with a cvss (common vulnerability scoring system) count of 3.4. Exploitation of the application-side web vulnerability requires a privileged web-application user account and low or medium user interaction. Successful exploitation of the vulnerabilities result in persistent phishing mails, session hijacking, persistent external redirect to malicious sources and application-side manipulation of affected or connected module context. Vulnerable Module(s): [+] Aula Vulnerable Parameter(s): [+] name Affected Module(s): [+] iClass Calender Events Context (App Index) Proof of Concept (PoC): ======================= The persistent input validation web vulnerability can be exploited by local attackers with physical device access and with low user interaction. For security demonstration or to reproduce the security vulnerability follow the provided information and steps below to continue. 1. Install the mobile application to your iOS or Android device 2. Open the application and add a new entry to the iclass calender index 3. Inject to the Aula name value your own script code (payload) for testings 4. Save the entry and move back to the iclass calender index of the app 5. The code executes because of the wrong encoding in the calender itself. Note: Export and Exchange of malicious context is possible! 6. Successful reproduce of the security vulnerability! Solution - Fix & Patch: ======================= The vulnerability can be patched by a secure parse and encode of the vulnerable name value in the iclass calender module. Restrict the name input and disallow usage of special chars to prevent persistent cross site scripting attacks. Security Risk: ============== The security risk of the persistent input validation web vulnerability in the name value is estimated as medium. (CVSS 3.4) Credits & Authors: ================== Vulnerability Laboratory [Research Team] - Katharin S. L. (CH) (research@vulnerability-lab.com) [www.vulnerability-lab.com] Disclaimer & Information: ========================= The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties, either expressed or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab or its suppliers are not liable in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. We do not approve or encourage anybody to break any vendor licenses, policies, deface websites, hack into databases or trade with fraud/stolen material. Domains: www.vulnerability-lab.com - www.vuln-lab.com - www.evolution-sec.com Contact: admin@vulnerability-lab.com - research@vulnerability-lab.com - admin@evolution-sec.com Section: magazine.vulnerability-db.com - vulnerability-lab.com/contact.php - evolution-sec.com/contact Social: twitter.com/#!/vuln_lab - facebook.com/VulnerabilityLab - youtube.com/user/vulnerability0lab Feeds: vulnerability-lab.com/rss/rss.php - vulnerability-lab.com/rss/rss_upcoming.php - vulnerability-lab.com/rss/rss_news.php Programs: vulnerability-lab.com/submit.php - vulnerability-lab.com/list-of-bug-bounty-programs.php - vulnerability-lab.com/register/ Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and other information on this website is trademark of vulnerability-lab team & the specific authors or managers. To record, list (feed), modify, use or edit our material contact (admin@vulnerability-lab.com or research@vulnerability-lab.com) to get a permission. Copyright © 2015 | Vulnerability Laboratory - [Evolution Security GmbH]™ -- VULNERABILITY LABORATORY - RESEARCH TEAM SERVICE: www.vulnerability-lab.com CONTACT: research@vulnerability-lab.com PGP KEY: http://www.vulnerability-lab.com/keys/admin@vulnerability-lab.com%280x198E9928%29.txt Source

Apple uses iOS (operating system) to power many of its mobile devices such as iPhone, iPad and so on. From the beginning, security has been placed at the core of iOS. There are many inherent features that secure the device and its resources at different levels. This article aims to provide answers to questions such as the following: What really happens when an iPhone is powered on? How is data at rest secured by iOS? If the device is lost or stolen, can the attacker view or modify my personal data? How are privacy controls enforced? For ease of understanding, we wil deal with each of these topics in separate sections. Let’s begin! Boot level security mechanism In the desktop computer world, an attacker can access the data present on the hard disk even without knowledge of the password of that system. For instance, he can remove the hard disk and plug it to a different system and read the data, or he can boot the system into a different OS by using a live CD. But do you think it’s possible in the case of an iPhone? I.e., Can an attacker who has access to an iPhone remove the chip and read its data or sideload another OS to access data? Not really under normal circumstances! This is because iOS devices don’t load firmware that is not signed by Apple. Taking a look at the boot level security mechanism would help us to understand this in a better fashion. So what really happens when you power on your iPhone? When an iOS device is turned on, the processor immediately executes code known as the boot ROM. This boot ROM code is something that is designed during chip fabrication and is implicitly trusted. This boot ROM also contains root certificates of Apple which will be used to signature check the loading of the next stages. LLB (Low Level Boot loader) is the next thing that will be loaded after the signature check. LLB finishes its task and loads next stage boot loader iBoot after verifying its signature. iBoot verifies and runs iOS kernel. Thus, as shown in the following figure, at each stage a signature check is done before loading the next step. This is called “Chain of Trust”. Hence, under normal circumstances, this chain of trust ensures iOS runs on valid devices only and also verifies that the phone is not booted into another operating system. Can this signature check be bypassed so that we can flash our own boot loader? Yes it can be. Several vulnerabilities have been identified in boot ROM code which can be exploited to not only flash our own boot loader but also to bypass the signature checks of every stage. Remember that if one link is compromised, it would ultimately lead to compromise of all the other links that follow. How this can be done will be discussed in a separate post. Secure Enclave You must have heard about the finger print sensor introduced in iPhone 5S. Apple says this finger print information is encrypted and stored in a ‘Secure Enclave’ inside the phone and is never backed up to iCloud or any Apple servers. So what is this Secure Enclave and how does it work? Secure Enclave is a coprocessor created inside Apple A7 processor. All the cryptographics required for data protection are handled by this. It has a secure boot and updates which are separate from the main processor. Secure Enclave is a concept that is similar to ARM’s Trust zone technology. Following is a sample depiction of hardware architecture of trust zones. As shown above, a new mode called ‘secure mode’ is added to the processor. In simple terms, it kind of creates two-world architecture on the same device. The first world that runs normal iOS apps (user mode) and the second world that runs only trusted code (secure mode). Data written to the RAM when in secure monitor mode cannot be accessed when in user mode. The following steps compiled from iPhone5S: Inside the Secure Enclave | Fortinet Blog explain how Secure Enclave works while validating the fingerprint in iPhone 5S: User enters his fingerprint Locking service calls an API present in secure world Processor switches to secure world The bits which characterize the fingerprint move from sensor to processor This data cannot be eavesdropped or modified by any app because this process is running in secure mode which is different from user mode Necessary cryptographic verifications are done & access granted. Apple thus argues that even if the kernel is compromised, the integrity of data protection will be maintained. As per Apple’s documentation, “Each Secure Enclave is provisioned during fabrication with its own UID (Unique ID) that is not accessible to other parts of the system and is not known to Apple. When the device starts up, an ephemeral key is created, entangled with its UID, and used to encrypt the Secure Enclave’s portion of the device’s memory space”. Code Signing Apps have today become critical components of any mobile operating system. Apple believes enforcing strict security at the application level is important to ensure overall security of the device. Apple has gone to great extent to make this happen, and code signing is one step in that direction. To put it simply, Apple does not allow running any app which is not approved by it! To ensure that all apps are from a trusted and approved source and have not been tampered with, iOS requires all apps to be signed by Apple. Default apps like Safari are signed by Apple. Other third party apps are also to be verified and signed by Apple. In other words, the above discussed chain of trust principle continues from boot loader to OS to apps. But how does this actually work? Does this mean I cannot run an app developed by me if it’s not signed by Apple? In order to develop and install apps on iOS devices, developers must register with Apple and join the iOS Developer Program. The real-world identity of each developer, whether an individual or a business, is verified by Apple before their certificate is issued. This certificate enables developers to sign apps and submit them to the App Store for distribution. As a result, all apps in the App Store have been submitted by an identifiable person or organization, serving as a deterrent to the creation of malicious apps. These apps are further reviewed by Apple to ensure they operate as described and don’t contain obvious bugs or other problems. Apple believes this process would give customers more confidence in the quality of apps they buy. If corporate companies want to use in house apps for their internal purpose, they need to apply for iOS Developer Enterprise program (iDEP). Apple approves applicants after verifying their identity and eligibility. Once an organization becomes a member of iDEP, it can register to obtain a Provisioning Profile. This is the one that permits in-house apps to run on devices it authorizes. Users must have the Provisioning Profile installed in order to run the in-house apps. This ensures that only the organization’s intended users are able to load the apps onto their iOS devices. In-house apps also check to ensure the signature is valid at runtime. Apps with an expired or revoked certificate will not run. This code signing process is depicted in the following figure. Thus we have explored three major security features in iOS – secure boot process, Secure Enclave, and application signing in this article. In the next part, we will look into other security features such as data protection, encryption and so on. ‘Til then, Happy Hacking! Source

juan@hotmail.com:juan Captured Keys: <------------> Renewal Date: December 24 2014 Use On: Windows OSX iOS Android

Until yesterday, a popular networking library for iOS and OS X used in apps such as Pinterest and Simple was susceptible to SSL man-in-the-middle (MiTM) attacks. The developer behind the framework AFNetworking on Thursday pushed a fix for the issue, a logic flaw. The flaw had lingered in the wild for more than two months but it took some repeated poking from Github users and two researchers, Simone Bovi and Mauro Gentile at the software security firm Minded Security, for the developer to finally address it. Bovi and Gentile stumbled upon the issue while doing mobile application security analysis for one of their clients in early March. After combing through the application’s source code the researchers found that the library’s SSL certification validation and its trust evaluation had been disabled, something that could have allowed any SSL traffic to be intercepted via a proxy service such as Burp Suite. “After a few minutes, we figured out that there was a logical bug while evaluating trust for SSL certificates, whose consequence was to completely disable SSL certificate validation,” Bovi wrote in a blog post yesterday, shortly before the issue was fixed. Bovi and Gentile found the issue had previously been brought up in a Github forum post in early February and that the flaw appeared to stem from a problem with version 2.5.1 of the library, introduced in late January. An additional, and more thorough post on Github 15 days ago helped the issue gain some visibility as well. “I have verified that a malicious proxy server can sniff all the contents of HTTPS communication in this case,” Github user duttski, who created a patch as a temporary workaround until the issue was fixed, warned at the time. iOS developer Mattt Thompson, who created and maintains AFNetworking, pushed Version 2.5.1 of the project live yesterday and fixed the issue by adding test and implementation of strict default validation, according to the library’s release notes. The library is a key part of popular social media applications like Vine and Pinterest on OS X and iOS. The framework also figures into apps and services primarily used by app and UX developers like Heroku and Parse. Source

// nah

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

Dear, I want to share you a profession wordpress theme, you can download and use it for create a app store like google play, itune store. Screenshot I Hope this share will help some body need it. Theme Features Itune Affiliate Integration Import Genres As Category Easy Features Category Automatic Import App Target Import App Mobile Ready Custom Background Unlimit Sidebars Compatible with all browsers. Themed Login & Signup Pages Google Analytics Tracking Code Easy change layout Search Engine Optimized Ease change Logo, favicon Auto-Updates Easy Description Page Options Easy Sidebar Control Unlimited Font HTML5 / CSS3 DEMO: Top App for iPhone, IPad - IOS App Store - Top App for iPhone, IPad - IOS App Store Theme Page: Filip - IOS App Store - SuuPress.com Download: suuappstore-v2.0.1000

Care sistem este mai cautat android sau ios? Ce cunostinte necesita pentru a crea o aplicatie pentru Android? Ce cunostinte necesita pentru a crea o aplicatie pentru IOS?

Damn Vulnerable iOS App (DVIA) is an iOS application that is damn vulnerable. Its main goal is to provide a platform to mobile security enthusiasts/professionals or students to test their iOS penetration testing skills in a legal environment. Download: Downloads - DVIA (Damn Vulnerable iOS App)

iGoat is a learning tool for iOS developers (iPhone, iPad, etc.). It was inspired by the WebGoat project, and has a similar conceptual flow to it. As such, iGoat is a safe environment where iOS developers can learn about the major security pitfalls they face as well as how to avoid them. It is made up of a series of lessons that each teach a single (but vital) security lesson. iGoat is free software, released under the GPLv3 license. Download: https://code.google.com/p/owasp-igoat/wiki/NewDownloads

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

Sunt dispus sa lucrez la o aplicatie opensource, care sa _fie folositoare_ utilizatorilor acestui forum. Va invit la postat. - The red.

Pangu download link: https://mega.co.nz/#!F0oEXLza!AfY88FazEyeQUnRQoghshmdrf0gz2vjInc6uqni tVBo sau oficial website --> http://pangu.io/ Se necesita iTunes instalat. Momentan disponibil doar pentru windows. *Testat pe iPad 2 v7.1.1*

A Hacker Is Remotely Locking iPhones, iPads and Macs, Wants Ransom to Unlock Them What would your first thoughts be if you turned on your iPhone today and saw this message awaiting you: "Device hacked by Oleg Pliss"? Then, Oleg Pliss tells you that the only way to unlock your phone is to send him $50 through PayPal. Day ruined, amirite? Well, many people in Australia woke up to that and similar messages this morning after hackers used the Find My Device feature on iPhones, iPads and Macs to lock down the device and send the messages. Word started to spread as people went to Apple support forums and reported their problem. While some users have been able to gain back access to their devices without giving the hacker their lunch money for the week, others are waiting for Apple to find a solution. It isn't clear how the hackers were able to pull this off, but it's thought that they may be using leaked email addresses and passwords from somewhere, and are attacking the people who use the same email and password for their AppleID. While this hasn't affected anyone in the States yet, this is a good reminder to change your passwords if you use the same one for more than one website. Sursa: A Hacker Is Remotely Locking iPhones, iPads and Macs, Asks for Ransom to Unlock Them | Complex Via: Apple iPhones, iPads, Macs Hacked and Held For Ransom - TIME

LinkedIn's iOS application is prone to a vulnerability that may permit remote attackers to execute arbitrary code. Security Researcher Zouheir Abdallah has disclosed HTML parsing vulnerability in LinkedIn iOS an app, that can be used to phish for credentials or be escalated into a full blown attack. LinkedIn's vulnerability occurs when the messaging feature of LinkedIn's mobile app parses invalid HTML and an attacker can exploit this vulnerability remotely from his/her account, which could have serious impact on LinkedIn's users. He created Proof of concept of the flaw and submitted it to the LinkedIn Security team in September 2013. Later in October 2013, the vulnerable application was patched. One of the possible attack vector is that, using this vulnerability attacker can easily phish LinkedIn user on iOS app. As shown in the screenshot, POC message says: The iOS app will display the url without the hyperlink embedded in the HTML a href , and the receiver of the message will not even know that he is being redirected to a malicious site. The phishing site can be a replica of LinkedIn and tricks the victim into giving out his username and password. This attack can also be used against LinkedIn users by claiming that, they have to re-authenticate to view some article on LinkedIn. The Same attack could also work on different devices such as Android and Blackberry, but he couldn’t test as he didn’t have other handsets at hand. LinkedIn doesn't have a Bug Bounty program neither a Hall of Fame, nevertheless he received a symbolic token of a Shirt, Mug, and a thank you note from LinkedIn's security team. Zouheir is known for reporting a serious vulnerability in DropBox's 2 Factor Authentication back in July 2013. Source: LinkedIn iOS app HTML Message Parsing Vulnerability

Dat fiind faptul c? Apple timp de 6 luni a ignorat eroarea raportat?, un utilizator a hot?rât s? fac? public? o secven?? de caractere arabe, care provoac? o eroare fatal? ce duce la încetarea for?at? a oric?rei aplica?ii ce folose?te WebKit. Vulnerabile fiind doar sistemele de operare: Mac OS 10.8 (Mountain Lion) ?i iOS 6. Versiunile iOS < 6 ?i 7 beta, Mac OS < 10.8 ?i 10.9 beta nu sunt afectate de aceast? problem?. Folosind acest bug, atacul DoS poate fi efectuat folosind urm?toarele metode: Trimiterea unui simplu SMS (dup? deschiderea mesajului, aceast? aplica?ie nu mai poate fi deschis?); Deschiderea unei pagini WEB (browser-ul Safari se va închide ?i o va face de fiecare dat? dac? nu este ?ters istoricul); Trimiterea unui mesaj folosind iMessage pentru iOS sau desktop Messages pentru Mac OS (aplica?ia se va închide ?i nu va mai putea fi deschis?); Crearea unui hotspot WiFi indicând „caracterele arabe” pentru numele re?elei (eroarea va ap?rea în timpul scan?rii re?elelor WiFi); Deci, exploit-ul propriu-zis: ???????????? ???? ???? ???? ??????? ????