Android App Permissions – Android P

Ever wondered what are App Permissions in Android 6.0 and above? Its simple. When an App needs to interact with data on your phone that it does not own for a predefined functionality, it prompts the User seeking permission for it to access the same.

So Users think twice before tapping the “Allow” button on your Android Screen while using a 3rd party app!

Be extra careful while giving the permissions for Apps seeking for the following areas on your phone:

  1. Location
  2. Telephone
  3. Contacts
  4. SMS
  5. Camera
  6. Microphone

Lets try understanding each and every permission group mentioned above:


Location

This permission provides and app to use the GPS (Global Positioning System Chip) on your phone which can help the app by letting it know your position in GPS Coordinates.

Generally this feature is used by an app to make it deliver results which are location perfect, Example: “Hire a Cab”  app. It shall require your exact location on map so that the cab can reach you and pick you up.

So whats so bad in this? Lets consider a scenario where a MALICIOUS APP has been given a Location Permission. That means that the app can detect your exact location at any given point whenever required and even send that details to a hacker sitting somewhere out there in the wild and watching your movements. I think now you have an idea how the Hero in Spy Movies keeps a track of his assets 🙂


Telephone

This permissions allows an app to place a call. Every app can launch the default dialer and even fill in the number, but unless this permission is granted you have to press the call button.

As well when an app is granted this permission, it can even read your current phone status i.e. if you are on an ongoing call. For example, “TrueCaller” does have a feature to tell others if you are on a call. The setting can be turned off if you want to keep that info private but by default,”TrueCaller” knows if you are idle or busy on another call


Contacts

This permission allows an app to read/ write to your contacts. Remember those crowdsourcing apps which provided the identity of unknown numbers? It did use this feature on the phones to upload the contacts from individual phones to build their database.

How sure are y0u to provide this permission to any app thats installed on your phone?

Please note that Android does not give us the visibility to know which contact was accessed by the app that was granted this access.

So users, be choosy!


SMS

An app with this permission, can READ ALL your SMS messages. One of the most known use cases is autofill One Time Passwords(OTP) for shopping/ banking apps.

Although this is known to be one of the features designed for user convenience, lets give it a thought once. Do we get to know which app is reading which SMS, and is the app reading only the SMS intended for it? Not sure because Android does not give us the ability of auditing that activity of an app.

Misuses: In our experience, we have seen apps use this feature for competitive intelligence. For example there are 2 apps who are direct competitors of each other and lets say there is a user who uses both of them. When the user uses one of these 2 apps and of there is a related SMS like a delivery notification, the second app which also has SMS permission, can peep into this one and hence after a period of time, the second app can strategise their next marketing move! Interesting isn’t it?

Think about this once again!


Camera

An app with this permission gets to use the cameras present on the phone. Straight forward isn’t it? Not really! Did you think of background apps? What if there is a malicious app that runs in background and starts accessing the camera to take pictures in stealth?

Let me explain this in a little more detail. The camera output that we see on our screen when the camera app is launched is the last step in the process called as “FEEDBACK”. The first thing that happens is that camera starts grabbing images/ video, then processes it and the last one is to display it on our screen. Now what if the feedback is not provided or the app simply runs in the background, keeps grabbing pictures/ videos and does not show them on the screen? Please go through this post, a little dated one but interesting one. Summarising the post, By shrinking a camera app’s viewfinder to 1px, which made it virtually invisible, Mr. Sidor was able to gain access to a Nexus 5‘s camera without alerting users to the app’s activities—even when the app was running in the background and the phone’s screen was switched off.


Microphone

An app with this permission can use the mic on the phone. Ideally we grant this permission to all those apps which need to record or listen to the sounds around the phone like the Dialer app, Shazam app(Music Recognising app by sample recording) etc.

Misuses: An app running in the background does always have the ability to start recording the sounds around it? Privacy is a huge myth !!! Remember your google assistant is always listening to you and quickly gets activated when you say the Magic word “Hey Google!”


Good News ! ! ! Android P******

Android P”  New rule-sets will PREVENT idling background apps from accessing the camera. This will ensure that malicious apps running in the background when your screen is off can’t take potentially compromising pictures of you or your loved ones for blackmail.

The rule change targets apps’ UIDs (User IDs), the identifiers Android assigns each application at install time. They’re unique to each app, and they don’t change—as long as an app remains installed on your phone or tablet, it’ll retain the same app ID.

In Android P, when the camera service detects that a UID is “idle”—that is to say, when the device is in the idle Doze state and background apps’ access to CPU and network-intensive services is restricted—Android will generate an error and close access to the camera. Subsequent camera requests from the inactive UID will immediately generate an error.

 


 

 

Share it on your Social Network !

Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Hits: 114

CVE-2018-6389 Zero Day – WordPress Remote DoS – Parameter Resource Consumption

On Monday, February 5, 2018, a zero-day vulnerability in WordPress core was disclosed CVE-2018-6389, which allows an attacker to perform a denial of service (DoS) attack against a vulnerable application. The vulnerability exists in the modules used to load JS and CSS files. These modules were designed to decrease page-loading time, but have effectively rendered the WordPress core susceptible to DoS attacks.

WordPress holds a market share of more than 29 percent of internet websites and 60 percent of content management systems (CMS) worldwide, turning any vulnerability in the WordPress core into a potentially large-scale exploit.

The vulnerability exists due to a flaw in the server-side static file loading mechanism. The parameter “load” in the vulnerable modules “load-styles.php” and “load-scripts.php”, which reside under the “/wp-admin/” path, accepts an array of JS/CSS files to fetch while the page is loading. The vulnerable modules are usually used only in pages accessible by authenticated users, with an exception being the login page, which exposes said modules to unauthenticated users as well. Thus, a malicious user can repeatedly request an excessive list of JS/CSS files, causing the server to retrieve vast amounts of data — and in so — render it unresponsive.

Some JS files appearing in “script-loader.php” can be retrieved using the load parameter, causing increased resource consumption.

Although the load parameter can accept all 181 JS files that appear in the “script-loader.php” module. Our analysis has shown that, in fact, the server doesn’t retrieve any data when calling JS files that are pulled from an external source such as https://ajax.googleapis.com . Hence, appending these JS files to the requested list is useless from an attacker’s perspective.

Due to the simplicity of this attack, a low skill attacker can utilize the existing public exploit to take down virtually any unprotected WordPress site. Because the vulnerable modules are essential, a blacklist isn’t recommended and a simple authentication-based whitelist will not work either because it may break the login page.

WordPress did not patch this vulnerability because they view it as an extensive resource exhaustion attack, and as such should be mitigated by a network firewall / web application firewall. This may, of course, change, and WordPress webmasters should (as always) stay tuned for new patches and versions.

It is advised to set access restrictions to the “load-styles.php” and “load-scripts.php” modules by only allowing trusted IPs to access these resources or by enabling two-factor authentication on the wp-admin directory. Another solution is to set rate limits to these resources.

Vulnerability discoverer Barak Tawily released the following Bash script that patches the exploit by essentially allowing only admins to send requests to the vulnerable modules, and removes the requests to the modules from the login page. The script also removes most of the code from the “noop.php” module due to “re-declaration errors”.

We did not extensively test this patch in our lab, and as of today, it wasn’t integrated into the main WordPress repository. Thus, we cannot recommend this solution, as it deviates from the WordPress core source and may cause compatibility issues.

Share it on your Social Network !

Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Hits: 65

Apple iBoot – iOS 9- Source Code Leaked !

Apple source code for a core component of iPhone’s operating system has purportedly been leaked on GitHub, that could allow hackers and researchers to discover currently unknown zero-day vulnerabilities to develop persistent malware and iPhone jailbreaks.

The source code appears to be for iBoot—the critical part of the iOS operating system that’s responsible for all security checks and ensures a trusted version of iOS is loaded.

In other words, it’s like the BIOS of an iPhone which makes sure that the kernel and other system files being booted whenever you turn on your iPhone are adequately signed by Apple and are not modified anyhow.

The iBoot code was initially shared online several months back on Reddit, but it just resurfaced today on GitHub (repository now unavailable due to DMCA takedown). Motherboard consulted some security experts who have confirmed the legitimacy of the code.

Latest Update: Around 21 hours ago (at the time of publishing this post), after DMCA taking the Original GitHub Profile of the author ZioShiba down, the same author seems to have cloned the repo to a different Git found here

However, at this moment, it is unclear if the iBoot source code is completely authentic, who is behind this significant leak, and how the leaker managed to get his/her hands on the code in the first place.The leaked iBoot code appears to be from a version of iOS 9, which signifies that the code is not entirely relevant to the latest iOS 11.2.5 operating system, but some parts of the code from iOS 9 are likely still used by Apple in iOS 11.

“This is the SRC for 9.x. Even though you can’t compile it due to missing files, you can mess with the source code and find vulnerabilities as a security researcher. It also contains the bootrom source code for certain devices…,” a security expert said on Twitter.

The leaked source code is being cited as “the biggest leak in history” by Jonathan Levin, the author of a number of books on iOS and macOS internals. He says the leaked code seems to be the real iBoot code as it matches with the code he reverse-engineered himself.

Apple has open sourced some portions of macOS and iOS in recent years, but the iBoot code has been carefully kept private.

As Motherboard points out, the company treats iBoot as integral to the iOS security system and classifies secure boot components as a top-tier vulnerability in its bug bounty program, offering $200,000 for each reported vulnerability.

Therefore, the leaked iBoot code can pose a serious security risk, allowing hackers and security researchers to dig into the code to hunt for undisclosed vulnerabilities and write persistent malware exploits like rootkits and bootkits.

Moreover, jailbreakers could find something useful from the iBoot source code to jailbreak iOS and come up with a tethered jailbreak for iOS 11.2 and later.

It is worth noting that newer iPhones and other iOS devices ship with Secure Enclave, which protects against some of the potential issues that come with the leaked iBoot source code. So, I really doubt that the leaked code will be of much help.

Apple has yet to comment on the recent leak, though Github has already disabled the repository that was hosting the iBoot code after the company issued a DMCA takedown notice. However, the code is already out there.

Share it on your Social Network !

Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Hits: 41

OWASP Top 10 – 2017 – 13Years of Awareness !

OWASP Top 10 – 2017

The Ten Most Critical Web Application Security Risks

What changed from 2013 to 2017?

Change has accelerated over the last four years, and the OWASP Top 10 needed to change. The OWASP Team has completely refactored the OWASP Top 10, revamped the methodology, utilized a new data call process, worked with the community, re-ordered the risks, rewritten each risk from the ground up, and added references to frameworks and languages that are now commonly used.

Over the last few years, the fundamental technology and architecture of applications has changed significantly:

  • Microservices written in node.js and Spring Boot are replacing traditional monolithic applications. Microservices come with their own security challenges including establishing trust between microservices, containers, secret management, etc. Old code never expected to be accessible from the Internet is now sitting behind an API or RESTful web service to be consumed by Single Page Applications (SPAs) and mobile applications. Architectural assumptions by the code, such as trusted callers, are no longer valid.
  • Single page applications, written in JavaScript frameworks such as Angular and React, allow the creation of highly modular feature-rich front ends. Client-side functionality that has traditionally been delivered server-side brings its own security challenges.
  • JavaScript is now the primary language of the web with node.js running server side and modern web frameworks such as Bootstrap, Electron, Angular, and React running on the client.
  • New issues, supported by data:
    • A4:2017-XML External Entities (XXE) is a new category primarily supported by source code analysis security testing tools (SAST) data sets.
  • New issues, supported by the community: The community has provided the insights into two forward looking weakness categories. After over 500 peer submissions, and removing issues that were already supported by data (such as Sensitive Data Exposure and XXE), the two new issues are:
    • A8:2017-Insecure Deserialization, which permits remote code execution or sensitive object manipulation on affected platforms.
    • A10:2017-Insufficient Logging and Monitoring, the lack of which can prevent or significantly delay malicious activity and breach detection, incident response, and digital forensics.
  • Merged or retired, but not forgotten:
    • A4-Insecure Direct Object References and A7-Missing Function Level Access Control merged into A5:2017-Broken Access Control.
    • A8-Cross-Site Request Forgery (CSRF), as many frameworks include CSRF defenses, it was found in only 5% of applications.
    • A10-Unvalidated Redirects and Forwards, while found in approximately 8% of applications, it was edged out overall by XXE.

What changed from 2004 till 2017?

Lets take a look at the the OWASP Top 10 Categories starting from the year 2004. There have been publications in the years 2004, 2007, 2010, 2013 and the latest 2017 which is the 5 generations of OWASP Top 10 evolution.

20172013201020072004
InjectionInjectionInjectionCross-Site Scripting (XSS)Unvalidated Input
Broken AuthenticationBroken Authentication and Session ManagementCross-Site Scripting (XSS)Injection FlawsBroken Access Control
Sensitive Data ExposureCross-Site Scripting (XSS)Broken Authentication and Session ManagementMalicious File ExecutionBroken Authentication and Session Management
XML External Entities (XXE)Insecure Direct Object ReferencesInsecure Direct Object ReferencesInsecure Direct Object ReferenceCross-Site Scripting (XSS)
Broken Access ControlSecurity MisconfigurationCross-Site Request Forgery (CSRF)Cross-Site Request Forgery (CSRF)Buffer Overflow
Security MisconfigurationSensitive Data ExposureSecurity MisconfigurationInformation Leakage and Improper Error HandlingInjection Flaws
Cross-Site Scripting (XSS)Missing Function Level Access ControlInsecure Cryptographic StorageBroken Authentication and Session ManagementImproper Error Handling
Insecure DeserializationCross-Site Request Forgery (CSRF)Failure to Restrict URL AccessInsecure Cryptographic StorageInsecure Storage
Using Components with Known VulnerabilitiesUsing Components with Known VulnerabilitiesInsufficient Transport Layer ProtectionInsecure CommunicationsApplication Denial of Service
Insufficient Logging & MonitoringUnvalidated Redirects and ForwardsUnvalidated Redirects and ForwardsFailure to Restrict URL AccessInsecure Configuration Management
All the data above has been summarized from OWASP Website!

Brief summary of each threat:

A1:2017- Injection:

Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

A2:2017-Broken Authentication:

Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.

A3:2017- Sensitive Data Exposure:

Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

A4:2017-XML External Entities (XXE):

Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks

A5:2017-Broken Access Control:

Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc.

A6:2017-Security Misconfiguration:

Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched and upgraded in a timely fashion.

A7:2017- Cross-Site Scripting (XSS):

XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

A8:2017- Insecure Deserialization:

Insecure deserialization often leads to remote code execution. Even if deserialization flaws do not result in remote code execution, they can be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks.

A9:2017-Using Components with Known Vulnerabilities:

Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

A10:2017- Insufficient Logging & Monitoring:

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

Further Reading and References:

Please find the complete PDF  or visit the OWASP Website.

 

Share it on your Social Network !

Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Hits: 73

GIBON Ransomware – Decryption Tool Available

A new ransomware dubbed as “GIBON”  was spotted by the ProofPoint researcher Matthew Mesa that observed it being distributed by malware spam.

The researcher dubbed the ransomware “GIBON” because of the presence of the string in two places:

  • User-Agent String of the malware containing the string “GIBON” while it communicating with its Control & Command Center
  • Admin panel for the ransomware’s C&C Server. (the logo is from the Russian television company VID)

The spam messages use a malicious document as attachment containing macros that once enabled will download and install the ransomware on a victim’s machine.

 

Operation:

Step#1:

When the GIBON malware executes, it connects to the C&C server and registers the new victim by sending a base64 encoded string that contains the timestamp, the version of Windows, and the “register” string.

Step#2: 

The C&C Server in turn, sends back a response that contains a base64 encoded string that will be used by GIBON ransomware as the ransom note

Step#3: 

Once the infected machine is registered with the C&C,  it will locally generate an encryption key and send it to the server as a base64 encoded string. The malware will use the key to encrypt all files on the target computer, it appends the .encrypt extension to the encrypted file’s name

Step#4: 

Now that the victim has been registered and key transmitted to the C2, the ransomware will begin to encrypt the computer. While encrypting the computer, it will target all files regardless of the extension as long as they are not in the Windows folder.” reads the blog post published by Lawrence Abrams

During the encryption process, GIBON will routinely connect to the C2 server and send it a “PING” to indicate that it is still encrypting the computer

Step#5: 

The malware drops a ransom note in each folder containing the encrypted files, it also generates a ransom note named READ_ME_NOW.txt.

Attention! All the files are encrypted! 
To restore the files, write to the mail:bomboms123@mail.ru 
If you do not receive a response from this mail within 24 hours, 
then write to the subsidiary:yourfood20@mail.ru”

Step#6: Once the GIBON ransomware completes the file encryption the victim’s computer, it will send a message to the C&C server with the string “finish”, a timestamp, the Windows version, and the number of  files that were encrypted.

GOOD NEWS:

The files encrypted by this ransomware can be decrypted using the GibonDecrypter.

Continue reading “GIBON Ransomware – Decryption Tool Available”

Share it on your Social Network !

Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Hits: 30

iOS : Apps with Camera Access can take your pictures secretly !

What can an iOS app do?

iOS users often grant camera access to an app soon after they download it (e.g., to add an avatar or send a photo). These apps, like a messaging app or any news-feed-based app, can easily track the users face, take pictures, or live stream the front and back camera, without the user’s consent.

  • Get full access to the front and back camera of an iPhone/iPad any time your app is running in the foreground
  • Use the front and the back camera to know what your user is doing right now and where the user is located based on image data
  • Upload random frames of the video stream to your web service, and run a proper face recognition software, which enables you to
    • Find existing photos of the person on the internet
    • Learn how the user looks like and create a 3d model of the user’s face
  • Live stream their camera onto the internet (e.g. while they sit on the toilet), with the recent innovation around faster internet connections, faster processors and more efficient video codecs it’s hard to detect for the average user
  • Estimate the mood of the user based on what you show in your app (e.g. news feed of your app)
  • Detect if the user is on their phone alone, or watching together with a second person
  • Recording stunning video material from bathrooms around the world, using both the front and the back camera, while the user scrolls through a social feed or plays a game
  • Using the new built-in iOS 11 Vision framework, every developer can very easily parse facial features in real-time like the eyes, mouth, and the face frame

Facts

Once you grant an app access to your camera, it can

  • access both the front and the back camera
  • record you at any time the app is in the foreground
  • take pictures and videos without telling you
  • upload the pictures/videos it takes immediately
  • run real-time face recognition to detect facial features or expressions

Have you ever used a social media app while using the bathroom? ?

All without indicating that your phone is recording you and your surrounding, no LEDs, no light or any other kind of indication.

How can I protect myself as a user?

There are only a few things you can do:

  • The only real safe way to protect yourself is using camera covers: There is many different covers available, find one that looks nice for you, or use a sticky note (for example). 
  • You can revoke camera access for all apps, always use the built-in camera app, and use the image picker of each app to select the photo (which will cause you to run into a problem I described with detect.location).
  • To avoid this as well, the best way is to use Copy & Paste to paste the screenshot into your messaging application. If an app has no copy & paste support, you’ll have to either expose your image library, or your camera.

It’s interesting that many people cover their camera, including Mark Zuckerberg.

Original Submission:

This Alarming privacy concern in Apple’s mobile operating system was highlighted by an Austrian developer and Google engineer, Felix Krause, who detailed the issue in his blog post published Wednesday.

Keep Defending !

Share it on your Social Network !

Facebook twittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Hits: 46

Google PlayStore 3rd Party Apps Bug Bounty Hunt Starts !

 

Google has introduced a new program to help root out vulnerabilities in third-party apps in its Google Play storefront. The “Google Play Security Reward Program” will pay researchers who discover problems in popular Android apps found in the store.

Google has maintained bug bounty programs for products such as Chrome, Chrome OS and others, paying thousands of dollars for vulnerabilities. Developers of popular apps are invited to opt-in to the program to “proactively improve the security of some of the most popular Android apps on Google Play !

The company is collaborating with vulnerability coordination and bug bounty platform HackerOne. Developers are only able to participate if they’re willing to respond to and fix the bugs in a timely manner, must follow HackerOne’s disclosure guidelines and provide detailed reports. Presently the following Apps are eligible for rewards as per HackerOne.

The program might change so please do refer to the original program on HackerOne!

Hope Google will expand this program to a wider app choices as in today’s world, we are seeing a lot of botnets and threats from apps directly available on the official app stores itself.

According to HackerOne, hackers will identify app vulnerabilities and report it to the developer, and both work out a resolution within 90 days. The hacker then requests a reward from the program. Once it’s evaluated and found to meet Google’s criteria, the finder will be awarded $1000.

Please refer to our upcoming research report on #AndroidSockbot.

Keep Defending !

Share it on your Social Network !

Facebook twittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Hits: 46