Using the Android Management API, I would like to identify if a device has been rooted.
I found the attribute "devicePosture" and the possible values for this attribute are listed in this documentation here.
However, for me, it was not clear what these items mean.
For example:
Does the type "POTENTIALLY_COMPROMISED" mean that the device is rooted or just had its bootloader unlocked?
Does the "AT_RISK" type mean that you have a virus version of android (or something similar)?
Thank you for your help.
You can check this link , Also to answer some of your questions with regards to device posture.
The value of the security posture determines the current device state and the policies applied. Or in other terms it reflects how secure the device is
1.) “POTENTIALLY_COMPROMISED” value means that either SafetyNet's ctsProfileMatch check or basicIntegrity check fail or this device may be compromised and corporate data may be accessible to unauthorized actors. It covers both bootloader unlocked and rooted scenarios[1].
2.) "AT_RISK” value means that both SafetyNet's ctsProfileMatch check and basicIntegrity check pass but fails to meet requirements set by the policy (e.g. device's password state, etc.).
To determine whether what fails you can check the PostureDetail, SecurityRisk Value
[1] To understand what SafetyNet's ctsProfileMatch and basicIntegrity fields mean, you can check this link, which also explains what scenarios correspond to the combination of the value of the two checks.
Related
I am trying to implement an authorization system based on general NFC tags. One of the concerns I want to address is tag cloning. I have read some literature ensuring tag authenticity by using a read-only tag ID written on the tags during manufacture. This ID is signed by the owner and written on the tag. This way, a cloned tag (which will have a different, tag-manufacturer assigned ID) can be detected by comparing tag IDs with the cloned signature.
My question is, is it safe to assume that all (or most) NFC tags will have such a coded-in, read-only ID which I may use for cloning detection?
Narrow your problem down first pick a tag type and manufacturer that is suitably secure for your needs.
A UID is a general property of most tags BUT different tags have different specifications. Some tags have a small UID size and thus UID re-use is likely. Different tags have different length UID's. Some are supposed to be set at the factory but clones allow them to be set later. Some specification state the tag UID is always writeable.
Also using Host Card Emulation, it possible to write program to brute force any security based on UID alone (time taken could vary depending on UID length used)
Various tags offer password protection and encryption of the data on the tag (older tag types can have weak encryption/password protection though).
Most of the of the password protection is done with a special area where a password can be written to by a Reader/Writer but can only be read by the tag itself.
If you do use the password protection features of some tags make sure you don't the same password for every instance of the system, make sure the Admin of the system is forced to set one for their systems.
Considering UID for authenticity check is not a good idea, because cloned cards can have the UID cloned exact same as that of original card.
I'm not sure about other manufacturers, but as I have worked a lot with NXP tags, I'm just gonna suggest a solution here, if that suits your requirements then you can go ahead. For working with NXP cards they have provided an open api called TapLinx, where you get an api for originality check. Using which you can get to know if the card is authentic or cloned. It will identify the cloned cards even if the UID is also cloned.
Do not rely on the UID as security mechanism. There are cloned chips on the market, as well as chips where you can program the UID yourself. On top we have seen mistakes from manufactureres, resulting in duplicate UIDs.
Better use your own numbering scheme. Ideally on a cryptographic basis.
When WMI is queried and returns a list of devices, I've noted some information at the END of the DeviceID string that isn't documented anywhere I've looked so far. Here's an example of a DeviceID string returned from a WMI query looking at Win32_PnPEntity:
USB\VID_046D&PID_082D&MI_00\7&3538A2BF&0&0000
Now, the first two parts - both the 'USB' and the VID and PID are really well documented, as is the 'interface number' - the &MI_XX. However, the last part of the string (shown below) isn't documented anywhere I've looked. I don't even know what to call this part of the DeviceID string:
\7&3538A2BF&0&0000
Curiously, it comes in several flavors. I've noted that if I have two identical devices plugged into the PC, I'll get different values, which I've defaulted to calling 'instance id's' for lack of better documented reference info. Here's what I see when I have two identical USB Web cameras plugged into my PC:
USB\VID_046D&PID_082D&MI_00\6&DB509D0&0&0000
USB\VID_046D&PID_082D&MI_00\7&3538A2BF&0&0000
So far, so good. I can pick out that I have two identical devices plugged into the PC and can parse against these unique values. But wait! When the OS sees these devices, it also loads anything the drivers offers for different 'interfaces' or modes of operation, so along with the above entries when I make a WMI query against Win32_PnPEntity, I also get these nice entries in the DeviceID field as well:
USB\VID_046D&PID_082D\195825EF
USB\VID_046D&PID_082D\36149BBF
So the problem is that without documentation that describes what this last part of the DeviceID is, I don't know to expect, and can't associate or separate these 'duplicate' entries from their brethren in the query results.
The goal is to be able to scan through the WMI result, identify ONE 'primary' entry for a given device and discard anything else. I could likely HACK the filtering by looking for "USB Composite Device" in the Description field, but this is rather ugly and would discard some devices that do not have an appropriate or vendor-specified 'description.'
MSDN only provides that the DeviceID is a "Unique identifier of the USB controller. This property is inherited from CIM_LogicalDevice." -- and CIM_LogicalDevice doesn't detail the makeup of this field either.
Anyone been down this path or know which hole to look in? Similar questions in here and in other forums remain unanswered. (Hey M$, Why is this so %$##! mystical???)
It looks like this webcam is a composite device.
I think the node with the ID of USB\VID_046D&PID_082D\36149BBF is the parent device. The part after the second slash in this case is most likely the serial number of the device. (I have made Windows software for composite devices for years and we always get the serial number by parsing that part). This node probably uses usbccgp.sys as the driver, which allows it to parse the interface descriptors of the device and produce child nodes.
The node with ID USB\VID_046D&PID_082D&MI_00\6&DB509D0&0&0000 is the child node corresponding to USB interface 0. From my experience, I believe that the part after the second slash is some kind of unique identifier that depends on what USB port the device is plugged in to.
For the WMI query, you should probably just ignore the child nodes altogether. Just discard anything with MI_ in it before the second slash. The parent node tells you everything you need to know about the identity of the device.
I have a software activation logic which relies on thre parameters:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\DigitalProductId
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\InstallDate
Id of system volume
I'm interested in question: could these parameters ever change under any conditions except manual modification of registry values (for 1, 2) in single OS installation?
System volume id, as far as i know, can change only when the volume is formated.
Both DigitalProductId and InstalLDate also should be constant in single OS as they identify a license (concrete windows installation) and the date the OS was initially installes respectively. So according to this logic they shouldn't ever change.
I want to find any documentation that proves these points. Unfortunately my searching for such a documentation didn't give me enough as all that i've found are articles like this http://technet.microsoft.com/en-us/library/cc709644(v=ws.10).aspx which contain inderect information on the topic.
Also i've looked through this great post: http://siginetsoftware.com/forum/showthread.php?596-Investigating-the-Microsoft-Digital-ProductID-(DPID)
It partially proves my points but doesn't give a 100% guarantee
I repeat a question here once again:
Could parameters 1-3 ever change in single Windows installation?
Thanks in advance
My research has shown that independently of windows updates, service packs and other software, these keys remain the same.
I am having a hard time finding out what factors go into determining whether BCryptGetFipsAlgorithmMode() returns TRUE or FALSE. Does it just return the status of:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy\Enabled
or is it something else?
As I understand it: basically yes.
It's the C/C++ way to ascertain whether the system you're running on has FIPS Compliance specified in group policy. Using this function, rather than the registry keys allows Microsoft to move the registry key around as they see fit, as well as determine other ways in which this rule may be enforced. I suspect that's why they've provided a function and not just details of a key to check.
I am using some SNMP traps for monitoring of applications. Now I was told that some monitoring systems might have problems if the order of the attributes within the the traps was not the same as defined in the MIB. From the Complexity of the OIDs that could easily be used to re-order the attributes I was surprised by this, so I tried to find the relevant section of the RFC, but I could neither find something that said any ordering is allowed nor anything that said it is important. In other secondary documentation about SNMP I was not able to find anything usefull either.
So this is more a curiosity question, that could however also help in further projects using SNMP. Could anyone point me to the correct documentation as far as this problem is concerned. Or is this something that one software might handle while other software might not handle this and I should check the actual documentation for that software?
I found the relevant document.
Section 3.1.2 specifies:
The VARIABLES clause, which need not be present, defines the
ordered sequence of MIB objects which are contained within
every instance of the trap type. Each variable is placed, in
order, inside the variable-bindings field of the SNMP Trap-
PDU. Note that at the option of the agent, additional
variables may follow in the variable-bindings field.
Thanks to the person who pointed this out to me.