Samsung - Android 11 - java.net.UnknownHostException - Networking

Hi,
We have a rather large app but for some reason a sizeable amount of users on Samsung with Android 11 are getting java.net.UnknownHostException. For most people it helps with a reboot of their device but some users have to do a reinstall. It affects all domains so the app is unable to do any network calls.
Does anyone know of anything on a Samsung device on Android 11 that can restrict an app from reaching the network? I have such a phone myself but I can't see anywhere that it is possible to restrict access in such a way.
Due to an error we got removed from Google Play for 2 weeks but are back again now. I wonder if there is some security measures on Samsung that detected this and deemed the app unsafe maybe...? Sounds a bit far fetched but at this time I'm ready to believe anything.
Example from a log we got from a user:
Host: google.com
class java.net.UnknownHostException: [Unable to resolve host "google.com": No address associated with hostname].
https.nonProxyHosts=null
https.proxyHost=null
https.proxyPort=null
http.agent=Dalvik/2.1.0 (Linux; U; Android 11; SM-N975F Build/RP1A.200720.012)

Related

Android + encryption = no go?

Hi,
I own a HTC HD2 and since it has been possible to run Android on it I've started to love the device. Our companys policy does not allow Android phones to synchronize phones with the Exchange server, although it is possible and I have been doing it since I got Android. The reason that Android phones are not allowed to sync is that they do not support encryption. According to one of the persons in our IT staff the only mobile OS's that support are Windows Mobile and iPhone OS.
Is this correct and if so, will Android ever support encryption?
Our employees have a lot of sensitive information in their mailboxes..
I don't wanna go back to WinMo.
What kind of encryption do you mean? Encryption of data stored on a device? It's easy thing to do and it's a matter of software, not hardware, so actually any smartphone should be able to do that - including Android devices.
I mean hardware device encryption. If a person gets his phone stolen we want to make sure that the thief is unable to connect the phone to his computer and get access to all the data. Not just for the memory card but for the entire phone memory.
It is possible to open the phone and take out the storage and then connect it to a PC and collect data. But with hardware encryption that's way harder.
scanie said:
I mean hardware device encryption. If a person gets his phone stolen we want to make sure that the thief is unable to connect the phone to his computer and get access to all the data. Not just for the memory card but for the entire phone memory.
It is possible to open the phone and take out the storage and then connect it to a PC and collect data. But with hardware encryption that's way harder.
Click to expand...
Click to collapse
And does really iPhone and WM give you possibility to encrypt a whole partition using your passphrase, so you will have to enter it at boot time? If no, then it's not a true protection and Android can do that too.
My friend went thru the same prob on his hd2. Its more like so the IT staff can wipe your phone remotely/ change internet and emailing controls. Blackberry, Winmo, and iPhones do it.
U should use winmo at work then boot android on the way to the house. Best of both worlds.
Sent from my Androidized HTC HD2
WaveSecure anyone? It's the first application that came into my mind. I'm sure i've seen free solutions as well. If i remember well, Android 2.2 has this feature built-in.
Brut.all said:
And does really iPhone and WM give you possibility to encrypt a whole partition using your passphrase, so you will have to enter it at boot time? If no, then it's not a true protection and Android can do that too.
Click to expand...
Click to collapse
Yes they do. That's the whole point. My WM phone has an enforced policy and will not boot until the filesystem is unlocked by the passcode (that's not even to the WM splash screen).
The fact that no Android phones support hardware encryption means that whatever Google might say (and I've not seen it in their roadmap even now), their Exchange Provisioning support is substandard and therefore not suitable for secure enterprise use.
t1g3r3y3 said:
WaveSecure anyone? It's the first application that came into my mind. I'm sure i've seen free solutions as well. If i remember well, Android 2.2 has this feature built-in.
Click to expand...
Click to collapse
Wavesecure isn't actually encryption, it's just a solution for finding/wiping/backing up your phone.
Froyo does not have encryption built in.
Froyo permits device management by IT services, using Exchange. This allows remote wipe etc.
pulser_g2 said:
Froyo permits device management by IT services, using Exchange. This allows remote wipe etc.
Click to expand...
Click to collapse
But not device encryption, which is the whole point of this thread.
scanie said:
Hi,
I own a HTC HD2 and since it has been possible to run Android on it I've started to love the device. Our companys policy does not allow Android phones to synchronize phones with the Exchange server, although it is possible and I have been doing it since I got Android. The reason that Android phones are not allowed to sync is that they do not support encryption. According to one of the persons in our IT staff the only mobile OS's that support are Windows Mobile and iPhone OS.
Is this correct and if so, will Android ever support encryption?
Our employees have a lot of sensitive information in their mailboxes..
I don't wanna go back to WinMo.
Click to expand...
Click to collapse
Im not sure whom are you asking, Android its a open source OS, its up to those who make the devices to offer such features, ask HTC for instance if they plan to release such a "corp" devices, linux comes with such features so i doubt it would be very hard to make.
roalex said:
Im not sure whom are you asking, Android its a open source OS, its up to those who make the devices to offer such features, ask HTC for instance if they plan to release such a "corp" devices, linux comes with such features so i doubt it would be very hard to make.
Click to expand...
Click to collapse
Another post wide of the mark.
It's got nothing to do with the device makers or HTC. Android is Google's OS and the feature list of core releases (Froyo, Gingerbread etc.) is entirely under their control, as is the minimum hardware spec for each release. Device manufacturers like HTC are hardly going to go to the expense of building in device encryption if isn't supported by the OS provider or even on their roadmap.
Hence until Google decides otherwise Android will remain a leisure-orientated OS and just doesn't cut it for secure enterprise use.
without hardware support, like an extra encryption chip or a CPU, that has special functions, like AES-NI, full system encryption will be very, very slow.
xcreatir said:
without hardware support, like an extra encryption chip or a CPU, that has special functions, like AES-NI, full system encryption will be very, very slow.
Click to expand...
Click to collapse
Really? Doesn't seem to affect WM, Symbian and iOS devices which fully comply with Exchange security policies, nor those PC users protecting their hard disks with Bitlocker etc. No, this is just a case of Google dragging their feet because corporate users aren't high on their priority list.
Have you tried the encrypted certificate installer i think its a .psx doc. thats what let me into my server which still thinks it cant allow android phones.
vision
Interesting discussion. I know I can use up to 256bit AES encryption on Titanium Backup Pro...but thats it. I am guessing the software handles everything, only on backups and system data, but cant help but feel the phone has a say "of some kind" too.
Ineedtoys said:
Another post wide of the mark.
It's got nothing to do with the device makers or HTC. Android is Google's OS and the feature list of core releases (Froyo, Gingerbread etc.) is entirely under their control, as is the minimum hardware spec for each release. Device manufacturers like HTC are hardly going to go to the expense of building in device encryption if isn't supported by the OS provider or even on their roadmap.
Hence until Google decides otherwise Android will remain a leisure-orientated OS and just doesn't cut it for secure enterprise use.
Click to expand...
Click to collapse
But, HTC (or anyone else) can add and remove code to their build for the phone when adding/removing drivers or that [email protected] they load on your phone as someone said, it works under Linux who says I can't work for Android (anyway the kernel was made for modules)
As the hd2 roms are (mostly) pre-rooted who says you can't load the module to support filesystem encryption.
Sent from my Nexus One using XDA App
Edit: god I need to check what I am copying
Won't work. No network security manager in their right mind would make an exception for an unsupported hack. So until Google formally support all the Exchange policies (along with the responsibility should those implementations prove defective), many corporates will maintain a blanket ban on all Android connections.
foxwolfblood said:
But, HTC (or anyone else) can add and remove code to their build for the phone when adding/removing drivers or that [email protected] they load on your phone as someone said, it works under Linux who says I can't work for Android (anyway the kernel was made for modules)
As the hd2 roms are (mostly) pre-rooted who says you can't load the module to support filesystem encryption.
Sent from my Nexus One using XDA App
Edit: god I need to check what I am copying
Click to expand...
Click to collapse
This does nothing but further fragments Android as a platform. It's already suffering from Enterprise fragmentation due to Exchange client support: HTC's Exchange Client is notoriously the buggiest out of all the major Android Phone Manufacturers.
I would not want them developing that for Android.
My job banned Android phones after I had my first Vibrant stolen, because they were unable to Remote Wipe/Lock it or anything. Now, the server won't even let the phones connect to the Exchange server.
This is a serious issue. They actually banned everything but Windows Mobile phones for a while after that incident, but eventually let iOS and Nokia users connect after some "testing." Blackberries go through BES, so this were never a problem for them, since they don't use ActiveSync to access the Exchange server.
Android is still banned, and the fact that one manufacturer supports it when users can have phones from 5-10 different manufacturers who don't will not convince any IT department to allow them. Making these types of pointless exceptions does not help anyone.
http://www.nitrodesk.com/security.aspx

Security breach found on htc devices

The Vulnerability
In recent updates to some of its devices, HTC introduces a suite of logging tools that collected information. Lots of information. LOTS. Whatever the reason was, whether for better understanding problems on users' devices, easier remote analysis, corporate evilness - it doesn't matter. If you, as a company, plant these information collectors on a device, you better be DAMN sure the information they collect is secured and only available to privileged services or the user, after opting in.
That is not the case. What Trevor found is only the tip of the iceberg - we are all still digging deeper - but currently any app on affected devices that requests a single android.permission.INTERNET (which is normal for any app that connects to the web or shows ads) can get its hands on:
the list of user accounts, including email addresses and sync status for each
last known network and GPS locations and a limited previous history of locations
phone numbers from the phone log
SMS data, including phone numbers and encoded text (not sure yet if it's possible to decode it, but very likely)
system logs (both kernel/dmesg and app/logcat), which includes everything your running apps do and is likely to include email addresses, phone numbers, and other private info
Normally, applications get access to only what is allowed by the permissions they request, so when you install a simple, innocent-looking new game from the Market that only asks for the INTERNET permission (to submit scores online, for example), you don't expect it to read your phone log or list of emails.
But that's not all. After looking at the huge amount of data (the log file was 3.5MB on my EVO 3D) that is vulnerable to apps exploiting this vulnerability all day, I found the following is also exposed (granted, some of which may be already available to any app via the Android APIs):
active notifications in the notification bar, including notification text
build number, bootloader version, radio version, kernel version
network info, including IP addresses
full memory info
CPU info
file system info and free space on each partition
running processes
current snapshot/stacktrace of not only every running process but every running thread
list of installed apps, including permissions used, user ids, versions, and more
system properties/variables
currently active broadcast listeners and history of past broadcasts received
currently active content providers
battery info and status, including charging/wake lock history
and more
Let me put it another way. By using only the INTERNET permission, any app can also gain at least the following:
ACCESS_COARSE_LOCATION Allows an application to access coarse (e.g., Cell-ID, WiFi) location
ACCESS_FINE_LOCATION Allows an application to access fine (e.g., GPS) location
ACCESS_LOCATION_EXTRA_COMMANDS Allows an application to access extra location provider commands
ACCESS_WIFI_STATE Allows applications to access information about Wi-Fi networks
BATTERY_STATS Allows an application to collect battery statistics
DUMP Allows an application to retrieve state dump information from system services.
GET_ACCOUNTS Allows access to the list of accounts in the Accounts Service
GET_PACKAGE_SIZE Allows an application to find out the space used by any package.
GET_TASKS Allows an application to get information about the currently or recently running tasks: a thumbnail representation of the tasks, what activities are running in it, etc.
READ_LOGS Allows an application to read the low-level system log files.
READ_SYNC_SETTINGS Allows applications to read the sync settings
READ_SYNC_STATS Allows applications to read the sync stats
Theoretically, it may be possible to clone a device using only a small subset of the information leaked here.
I'd like to reiterate that the only reason the data is leaking left and right is because HTC set their snooping environment up this way. It's like leaving your keys under the mat and expecting nobody who finds them to unlock the door. For a more technical explanation, see the section below.
Additionally, and the implications of this could end up being insignificant, yet still very suspicious, HTC also decided to add an app called androidvncserver.apk to their Android OS installations. If you're not familiar with the definition of VNC, it is basically a remote access server. On the EVO 3D, it was present from the start and updated in the latest OTA. The app doesn't get started by default, but who knows what and who can trigger it and potentially get access to your phone remotely? I'm sure we'll know soon enough - HTC, care to tell us what it's doing here?
Technical Details
In addition to Carrier IQ (CIQ) that was planted by HTC/Sprint and prompted all kinds of questions a while ago, HTC also included another app called HtcLoggers.apk. This app is capable of collecting all kinds of data, as I mentioned above, and then... provide it to anyone who asks for it by opening a local port. Yup, not just HTC, but anyone who connects to it, which happens to be any app with the INTERNET permission. Ironically, because a given app has the INTERNET permission, it can also send all the data off to a remote server, killing 2 birds with one stone permission.
In fact, HtcLogger has a whole interface which accepts a variety of commands (such as the handy :help: that shows all available commands). Oh yeah - and no login/password are required to access said interface.
Furthermore, it's worth noting that HtcLogger tries to use root to dump even more data, such as WiMax state, and may attempt to run something called htcserviced - at least this code is present in the source:
/system/xbin/su 0 /data/data/com.htc.loggers/bin/htcserviced
HtcLoggers is only one of the services that is collecting data, and we haven't even gotten to the bottom of what else it can do, let alone what the other services are capable of doing. But hey - I think you'll agree that this is already more than enough.
Patching The Vulnerability
... is not possible without either root or an update from HTC. If you do root, we recommend immediate removal of Htcloggers (you can find it at /system/app/HtcLoggers.apk).
Stay safe and don't download suspicious apps. Of course, even quality-looking apps can silently capture and send off this data, but the chance of that is lower.
Affected Phones
Note: Only stock Sense firmware is affected - if you're running an AOSP-based ROM like CyanogenMod, you are safe.
EVO 4G
EVO 3D
Thunderbolt
EVO Shift 4G? (thanks, pm)
MyTouch 4G Slide? (thanks, Michael)
the upcoming Vigor? (thanks, bjn714)
some Sensations? (thanks, Nick)
View 4G? (thanks, Pat)
the upcoming Kingdom? (thanks, Pat)
most likely others - we haven't verified them yet, but you can help us by downloading the proof of concept above and running the APK
HTC's Response
After finding the vulnerability, Trevor contacted HTC on September 24th and received no real response for five business days, after which he released this information to the public (as per RF full disclosure Policy). In my experience, lighting fire under someone's ass in public makes things move a whole lot faster, which is why responsible disclosure is a norm in the security industry. (This is where we come in.)
As far as we know, HTC is now looking into the issue, but no statement has been issued yet.
HTC, you got yourself into this mess, and it's now up to you to climb out of the hole as fast as possible, in your own interest.
The ball is in your court.
Credit
ANDROID POLICE
Huge thank you to Trevor Eckhart who found the vulnerability and Justin Case for working with us today digging deeper.
Hi there, I need help, someone is consistently hacking into my phone, htc evo 4g, they are penetration testers and pc savvy, currently I cant login to the phn for trying to do a factory reset. They kept intercepting me and now my password does not work. Who knows maybe they changed it on their side. I wrote down everything I saw. I was seeing all these process running for the same app. in my applications. My phone was getting hot, freezes but its people that live in my apt complex and at work. can you help?
zzm5 said:
Hi there, I need help, someone is consistently hacking into my phone, htc evo 4g, they are penetration testers and pc savvy, currently I cant login to the phn for trying to do a factory reset. They kept intercepting me and now my password does not work. Who knows maybe they changed it on their side. I wrote down everything I saw. I was seeing all these process running for the same app. in my applications. My phone was getting hot, freezes but its people that live in my apt complex and at work. can you help?
Click to expand...
Click to collapse
Is your device rooted?
I used root explorer and removed the HtcLoggers.apk and other than the forced close loop that removing it caused (requiring me to remove the battery), after rebooting all seems to be working fine.
EDIT: Actually I didn't just delete HtcLoggers.apk but moved it to a safe location on the SD Card in case there was a problem and it needed to be restored. I highly suggest you do this instead of just deleting it, or better yet, a nandroid backup.
there are a few good ROMS out there that have the ICQ loggers removed already.
Do we really need three threads on the front page about the same thing?

Mobile phone Intrusion Detection System

Hi,
I'm new to this forum and after having a solid look around the site I have been unable to find anything that comes close to what I have in mind.
I am currently a student at Edinburgh Napier University and I am looking into the possibility of creating a local Intrusion Detection System on a Smartphone. One capable of informing a user that an intruder is currently attempting to gain access to their device and carry out malicious activities.
Has anyone managed to find anything I have not as I am under the impression that no such software exists for any type of Smartphone device. My main consideration is with Windows Phone but I would like to hear about anything that is out there that relates to this.
Any help would be amazing.
Thanks in advance :highfive:
I have no input, but this is interesting stuff. Will the hardware be robust enough to support it?
I know people have gotten Ubuntu running on various mobile devices, but it'd be interesting to see how SNORT (or similar) plays with mobile hardware.
The problem you are going to have (not unsurmountable) is that if you ignore the infosec/marketing what you have out there is primarily black box IDS devices, with capabilities to also run as an IPS.
However only the most nieve such as UK Gov & Local Gov have( certainly none of the Tier 1 Inv.Banks I have worked for) have switched IPS on for fear of backlash. It would be something if developed I would be interested in seeing, certainly if it could act as an IDS on a Ad-Hoc VPN there is commercial opportunities there....
So ask yourself - are you REALLY wanting to BOTH Detect and Prevent or merely Detect and Acknowledge. The latter a more easy task, less of a hit on functionality.
Perhaps there is an old Cybertrust source code now opensource....as a thought for you, but it would need reengineering as was a custom image.
In the meantime if what you actually want is Single IP/MAC/Hardware protection - why not root the device, install Synodroid (to control who or what has SU equivalent access) & DroidWall (firewall to limit traffic) & do an audit of the Apps you have downloaded of the rights requested. Perhaps setup a VPN to your university network or local broadband router (if you trust who manages them) so at least there is another layer to go through. However if you someone who opens zip's//tars on the device with install privileges elevated then your accepting the consequences. (Above Android related)
There is bound to be an IP traffic audit tool app - so you could use to Record a 24/26/48 hour period of the address ranges and what process linked back. But as you then start moving down the completely pain in the neck Firewall Rule analysis piece and SIEM world, don't!
Thanks finlaand
Thanks finlaand that is a lot to go on I really appreciate your thoughts.
I will be sure to keep you all up-to-date on how things are going.
Many thanks again :good:

[Q] is there a patch for this bug 13678484 (fake id)

can anyone make a patch for all variants of hd2 roms from gb up i used the bluebox app to check if my phone was vunerable for this bug 13678484 (fake id) and my daily driver barebone cm7 v2b was, and id say all roms developed for hd2 are vunerable have searched the net for how to patch this vunerability but cant find the info abywhere this is something i think all xda devs for this device will have to sort out as we cannot get help from carriers on this as this is what advice is given "contact your carrier or phone vendor for patch. if anyone has advice on how to sort this out would be very thankful i think xda should run a piece about this vunerability and what steps are being taken by all devs on xda to patch this vunerabilitu for older handsets likemy hd2.
Bluebox Security revealed a significant security flaw that affects all Android devices since version 2.1. Our hyperbolic title mocks the fact that he had little to ignite the Internet powders. If the fault is real, it should take a step back and put the case in context instead of screaming panic for nothing.
A serious flaw that affects a large number of terminals
Very schematically, the fault Fake ID allows malware to authenticate using the signature of a known application to hide its true origin. The firm provides an example of a virus masquerading as an Adobe Systems and Google software which would be able to become a Trojan horse or steal data used by Google Wallet acquiring the necessary permissions without using the user.
The flaw is serious. However, Google has already been made ​​aware, he has already released a patch he sent to his partners, he corrected the flaw in Android 4.4 KitKat, he scanned the Google Play and can say that no application in its store uses this vulnerability. Finally, Verify Apps, which monitors the behavior of applications on an Android device, is also fixed and can detect an application attempting to exploit Fake ID.
A patch already in place and a flaw in a very limited scope that still show that Google still has work to do in terms of security
In short, it is true that it is possible to be a victim of this fault, but it requires a terminal that has not been updated, download an application containing malware does not come from Google and Play Verify Apps have disabled or have an Android version of which is free. Suffice to say that the cases in question are very limited.
This flaw shows that Google still has work to do in terms of its security strategy. Last month, we décriions lax features the Play Store. Today, we are dealing with a flaw of a limited scope, but was discovered by analyzing the shortcomings of the source code of the operating system.
This flaw shows that Google still has work to do in terms of its security strategy. Last month, we décriions lax features the Play Store. Today, we are dealing with a flaw of a limited scope, but was discovered by analyzing the shortcomings of the source code of the operating system.[/QUOTE]
while the info you have given is fine and i thank you for it, but there are other app stores people use beside google play store and reading up on this bug it is still possible their phones could become compromised downloading apps from them?
A Big Big Thank You
Just an update: opssemnik backported the fake id xposed module and it works perfectly with gb roms a big big thank you to him. he also supplied a link in the comments on http://www.xda-developers.com/android/fight-fake-id-vulnerability-xposed/ So once again a big thank you to opssemnik

Unable to root the BlackBerry Priv is part of the marketing heart but is bad?

Evidently, BlackBerry will be heading straight to a 6 months on surviving root exploits which that is the same reason the device is being sold in the first place.
I knew some of my friends that are "conservatives" on Android and they believe that devices like Priv are the ones that makes Android not fun to deal with as root open big opportunity on having the best from a device.
I had been a faithful user of Google Nexus since Google Nexus 4 to 6 and yes and no I was in rush for a root, although I needed to control ads within the device, I am not a fan on modifying CPU's clock but controlling administrative aspect of the OS it is important too.
But BlackBerry Priv with a modified Android to be secure at least have answered all my needs that I sacrificed with the Google Nexus as previously was a faithful BlackBerry user and (you can correct me if I'm wrong) the bet pool for a fully functional root is currently at $300 and I wanted to ask if my friend are just being dramatic or it is true that not being able to root a phone can be upsetting to some?
BTW, I don't want to start a scuffle or anything, but I do believe BlackBerry has put many of know Android devs really to think about current exploits and if BlackBerry might be the precursor on a trend with other manufacturers.
To me, they are doing security by obscurity.
There are servers with root available that are secure, the access to said root is protected and exploits to access it without proper authentification are patched.
If they were that good, they would provide a secure way to use root privileges themselves.
They call for security, but you cannot manage iptables to prevent apps calling servers they should not talk to, you cannot prevent applications from tracking you using google's advertising ID, and most for all, you cannot prevent Google from tracking you, even when you don't use a Google account, because Googles services are tied to the system partition.
Being unable to root the PRIV with a security flaw is a good thing, being unable to protect yourself because your tools needs root and you cannot obtain it without a flaw is bad.
You should be able to obtain root from Blackberry themselves using a unique token the device can generate when your user password is good and the device unlocked. (Past password prompt, with a check that the password prompt had the right password, and that it wasn't killed some other ways).
Good point and btw, that was one of the argument in the discussion, Google itself is a big data mining system itself.
Magissia said:
To me, they are doing security by obscurity.
There are servers with root available that are secure, the access to said root is protected and exploits to access it without proper authentification are patched.
If they were that good, they would provide a secure way to use root privileges themselves.
They call for security, but you cannot manage iptables to prevent apps calling servers they should not talk to, you cannot prevent applications from tracking you using google's advertising ID, and most for all, you cannot prevent Google from tracking you, even when you don't use a Google account, because Googles services are tied to the system partition.
Being unable to root the PRIV with a security flaw is a good thing, being unable to protect yourself because your tools needs root and you cannot obtain it without a flaw is bad.
You should be able to obtain root from Blackberry themselves using a unique token the device can generate when your user password is good and the device unlocked. (Past password prompt, with a check that the password prompt had the right password, and that it wasn't killed some other ways).
Click to expand...
Click to collapse
Totally agree there - there has to be a secure way of providing root access to power users who know enough to request it and obviously accept the responsibility...
although i feel like the changes in the system you are proposing would probably mean that they wouldn't qualify for Google's android device approval process (whatever it's called) for allowing Google play services on it. That would basically defeat the purpose of moving to android as the app ecosystem is the main reason for the move...
Basically Google and apple are wielding all the power in the industry at this moment. and now with the (seemingly inevitable) slow, painful (especially for us fans) death of BlackBerry 10 on the horizon, i can't see there being an adequate alternative emerging for quite a while... unless you consider windows phone a viable alternative!! [emoji12]
So sit back, relax and enjoy our descent into the brave new world of 1984!!
Sent from my STV100-1 using Tapatalk
can't install a firewall. /thread if you think it's still secure.
well, you could still set up a VPN and filter on a remote server...
Sent from my STV100-1 using XDA-Developers mobile app

Categories

Resources