Is rooting an Android phone to install an anti-virus firewall worth it?

1. Why does the anti-virus tells you to root your device if it is a security risk

Basically, as answered here, rooting allows you to give root permissions (let's say to execute sudo) to some applications. The list of these applications with root permissions could be controlled with 'Superuser' app (integrated in the Settings for Cyanogenmod).

Also, you (a phone owner) now have root privileges. So if you will start installing software from third-party forums, noname markets/stores and will give root permissions to all of this applications, this will be bad, because you should not trust these apps. If you want to give a rooted phone to your grandma, and she does not undestand concepts of rooting/apps/app stores/permissions/etc - do not do it.

Next, if you are still careful, and only gives root permissions to 1-2 applications you and other people trust (like firewall or file manager, downloaded from reputable source), then it's ok. However, if this file manager or other software has vulnerability, some malware could use this vulnerability to get root access through this file manager, which now has root permissions. That is what I see as a risk.

However, unrooted devices could also have vulnerabilities like Stagefright, that allow an attacker to get root access to the phone, since unrooted Andriod still has libraries / system apps running with root permissions. So all you do is an increasing number of potentialy vulnerable apps with root permissions, that could be hacked (if you carefully select what and from where you install).

Most antivirus apps very often really need root permissions to be able to actively manage/block other apps, if they find some suspicious activity in them.

2. Does firewalls for android devices really worth it

It depends on what do you want from the firewall. E.g., I'm concerned about my privacy. And I still want to use some apps. However, these apps sometimes require Internet access, even though their functionality has nothing to do with Internet communication in my eyes (e.g., I do not want a music player to access an Internet, but I still want to use this music player, while PrivacyGuard has no functionality to control Internet access for apps). So I installed an AFWall+ to control which applications have Internet access. For me, it is worth it. I have a Cyanogenmod with root on my phone.

However, I do not have an antivirus. Personally, I do not see a much sense in having it, since I try to install apps only from trusted sources, see also this question

So, if you only give root permissions only to the single firewall from PlayStore, and you believe that this firewall has no serious vulnerabilities, then "A rooted Android device with a firewall" is more secure.


My ISP provides IPv6 natively but my VPN does not support IPv6

Your full setup is not known so I have to make some assumptions based on a typical setup:

Your local computer has both an IPv4 and IPv6 address in the local network.
Your router has both a public IPv4 and IPv6 address.
Routes on your local computer are setup so that both internet facing IPv4 and IPv6 traffic is going through the router.
Your local computer is the start point of the VPN connection.
The IPv4 only VPN software is not aware of the IPv6 capabilities of your computer, i.e. does not deal with them in a specific way. This is typical for OpenVPN installations.

In this setup the typically a new route (or multiple routes) for IPv4 traffic will be setup and will point to the VPN so that all IPv4 traffic will be send through the VPN. Since IPv6 traffic will not be specifically handled the existing IPv6 route will remain, i.e. IPv6 traffic will still flow outside the VPN. You can verify with sites like test-ipv6.com which IP addresses are visible from outside.

Of course, this is only true under the above assumption. It might well be that the VPN will simply disable all IPv6 on your host so that leakage using IPv6 is not possible. But, IPv6 leakage is a common problem with VPN setups.


Is this prime number large enough / too large for a Diffie-Hellman for AES-256?

AES-256 and a 8192-bit DH modulus are both overkill. Comparing them with each other is a delicate exercise which verges on the meaningless, since both are quite far into the realm of "can't break it now, can't do it in 30 years either". You can have a look at this site for information and calculators on various ways to estimate relative strength of symmetric and asymmetric algorithms.

Practical parameters which can be recommended now for proper security are AES-128 and a 2048-bit DH prime modulus (with 256-bit exponents).


Managing security of a desktop/mobile app

Not really sure why you think this is that hard?

I'm afraid I'm not sure why you want to create a new password store app either when  many already exist? If you feel the need for another app with some new features, please consider using an existing secure back-end such as the excellent KeePass. This has already solved the secure storage issue.

Then all you need to do is to make use of the Windows Passport libraries to use Windows for SSO though I'd have to say that personally, I wouldn't use such an app as most people configure their mobile login for convenience as much as for security and I wouldn't consider that secure enough for my password management tool.


What are the good resources for learning Metasploit?

The thing is that metasploit infact is a framework, so a collection of exploits. The beautiful thing about a framework is that you don't need to understand what's happening behind the scenes.

I think that if you want to learn more about exploits and how they work, you pick yourself up some basic books like The Shellcoder's Handbook. If you want a more hands-on experience, it's better to start with easy exploiting challenges. Check out http://smashthestack.org/. They have different challenges that start really easy and steadily increase in complexity. You can then apply what you read in the previous named book. If you find yourself in a pickle, there should be ample information on the net.


How does Near Field Communication (NFC) compare to RFID technologies? Looking for a functional primer

Is RFID a superset of NFC? (or vice versa?)

To quote from the the Wikipedia article "NFC standards cover communications protocols and data exchange formats, and are based on existing radio-frequency identification (RFID) standards..." So RFID is just a name for devices that use radio frequencies to communicate and NFC is one of these.

  Is all RFID / NFC hardware the same? (my Galaxy II has NFC, but Google
  payments isn't available)

All NFC hardware is the same, it works at 13.56MHz and has a data transfer rate of 106 kbit/s to 424 kbit/s, as described above NFC is a subset of RFID so whilst all NFC hardware belongs to the RFID category the reverse isn't necessarily true. The reason that Google Wallet doesn't work is that it requires in addition to NFC hardware that a secure element (SE) is in the device. A secure element is needed in order to store the card details etc. According to this and this the Galaxy S2 has no SE so can't use Google Wallet.

Edit: With the addition of Host Card Emulation in Android KitKat 4.4 it looks like Google is moving away from needing a Secure Element so there's a possibilty for Google Wallet working on all NFC enabled phones at some point in the future

  Can a mobile phone with NFC / RFID "read" an ID badge, Easy Pass (for
  highway/bridge tolls), US Passport, credit card, or other object?

I'm from the UK so I'm not aware about the Easy Pass reading but if you own one you could try reading it using an app such as NFC TagInfo. However in general your NFC enabled phone should be able to read these cards, for example I can read my student card, passport, train pass and credit card all via the NFC in my phone. The credit card requires a more specialised application than other cards to be read but it can be done easily.

  Does the ability to "read" an NFC object imply the ability to "copy"
  and emulate it? (Can I clone a credit card?)

NFC is just the standard for communication, it doesn't necessary imply anything about the object. For example a very popular form of access card for buildings is the MiFare Classic (my student card uses this). The chip in most (Android) phones allows emulation of this card, although the actual Android APIs don't currently allow for this easily. So you could emulate the data on the card however generally door access systems work with something called the Unique ID (UID) of each card to identify it and your phone doesn't allow for the setting of the UID so you can't use it as a door access.

Modern credit cards generally can't be copied, however this can depend on the country. In the USA I believe it's easier to clone cards as the banks there haven't all implemented what the UK calls Chip & PIN but is more generally known as EMV. EMV helps protects against cloning as each card has a cryptographic key that it uses to sign and then return some data that the ATM sends it. This key can't be (easily) extracted from the card meaning that you can't set up a fake card with the key. However it is possible to skim some data from a credit card using NFC and I've written my own app to do this. I was just looking for similar ones on the PlayStore to link to however it looks like Google is removing them and there used to be a lot more. It's possible to get information like card holder name, date of expiry and the card number.

N.B. I'm not sure why the site I linked to suggests skimming details from an NFC credit card in 2012 is new as it has been a known weakness for years. Part of my recent dissertation was on attacks on credit cards and I'll post a Q/A on here and link to that for more details as to why (modern) credit cards generally can't be skimmed and copied.


Is it possible to share BitLocker decryption keys between multiple TPMs?

I think I have found the "answer" to this. It should be possible, but Microsoft has not currently implemented it. As far as I know it is technically possible to have the decryption keys protected by several different TPMs stored on the same encrypted hard drive since they are (I think) a binary blob encrypted by the TPM, so each different TPM could have its own different blob that can be decrypted by that TPM.


Can File Sharing being Controlled by Mac Address?

MAC addressing resides in Layer 2 of the OSI model. Most of file sharing protocols are way up in Layer 7. I doubt you can do what you're trying to do only using MAC addresses.

It is possible to transfer anything using any layer of the OSI model. You can get physical and send the files bit by bit by yourself through the wire. You can even write an application that uses ICMP to setup a connection channels and use it to send and receive files.

I'm not sure what this has to do with security, but the answer is yes, it's possible. But I don't think there's any application that readily supports it.


Securing a website for my school project

It definitely sounds like you could get clarity on a the task.

But if that's all you have, I would start here: https://www.owasp.org/index.php/OWASP_Top_Ten_Cheat_Sheet

These are the 10 most common vulnerabilities for web applications. I would suggest going through each one following the instructions for checking whether they exist and steps to remediate them.


How to ensure web application remains secured after intrusion of server

One of the rules of security is:

  If the attacker has access to your box, it is his

This includes root access, or physical access. As root on a server an attacker can do anything.

So, what this means is you should be focusing more on prevention and detection. If you can place controls that make it difficult enough for an attacker that you spot them before they gain access, you can do something about it.

So, how do you do that?

First and foremost - get up to date. This includes upgrading to a more recent OS, and then keeping patches up to date. If a security advisory comes out in any application or framework you are using, test it doesn't break your system, then patch!

Use firewalls - they are a basic solution, but limiting access to only that which is required for business is still essential.

Similarly, limit account access.

Implement some form of IDS - whether it is a full blown IDS, logging of odd activity, su/admin logging etc. Log everything your IT administrators have access to.

Defence in depth - never gets old :-)


Security of passphrase-protected private key

With OpenSSL, OpenSSH and GPG/PGP the wrapping algorithm will be strong enough that you don't need to worry about it (and if you do need to worry about it then you have bigger problems, and this is the least of your worries).

Like any password or passphrase, it depends on the strength of the passphrase. A 40 character passphrase is as hard to brute force as a 256-bit key (since ASCII only uses 7 bits). The same rules for strong passwords apply here:

Random is better
Longer is stronger


Can I trust public code versioning platforms when building a social platform?

Unfortunately, you are the ones responsible of seeing if your threat model is justified or not. Therefore, we cannot simply give a definite "yes" whether we see using the platform as a security threat or not.

However, there are two points that I'd like to expand on:

You seem to be extremely worried about the source code containing vulnerabilities and that the disclosure of it would mean that an individual or party could identify them.

Personally, I would not feel confident about providing a service to users where its security relies on the source code not being open source. To me, this is some sort of security by obscurity. In the best world, you want your platform to be as solid even if the code leaks. Therefore, I would highly suggest that you partner up with some pentesters/code reviewers, or at least some developers that are very security-aware.

You mention wanting to move to private versioning servers.

Just do this right away and be done with this. At the risk of sounding blunt, I would question your technical skills if this seems to be a complicated or expensive step considering that you are starting off. Gitlab even offers a self-hosted solution; just make sure to review the platform and to block any communications with their servers if that part worries you.

Best of luck.


Can a sql query with both user input and parameter be prone to sql injection?

Yes.  Pretty much any sql query that concatenates raw or imperfectly protected user input can be vulnerable to injection.

There are some restrictions.  For example, The user input has to be long enough to be a viable attack (single character injection may not be enough, given the specific use of the soecific statement in question). It has to be usable data for the attack (input validation may restrict the input to a know white list of safe values, such as {1, 2, 3}).  It cannot be encoded in another, benign form (like basese64 encoding the user data).

The rule of thumb you should use is "if it's concatenated, it's a vulnerability unless proven otherwise."  It's generally cheaper and faster and easier to fix than to prove it's not a vulnerability, so it should just be fixed.


Steps to create user authentication system between mobile and server

You don't need half of those parts. Adding them will only create a more complicated system, with more room for failures.

You could do this:

Use certificate pinning on the device

This ensures that the device is talking to your server, and make the work very hard for any third party trying to read the data stream.
Using SSL, send login and password to the server

Any other data can be skipped. Timestamps, secret phrases, anything else is superfluous. You could send some device ID, it can be useful for accounting, not for authentication. You don't need the information, leave it out. Using SSL enables you to send the password as it is, without encryption, hashing or encoding. SSL will encrypt to you, transparently.
Store the username in clear, hash and salt the password

Hashing the username does not give any security, and increases difficulty for you. Salting and hashing the password will help your data survive longer in a case of database leakage. Just select the right encryption algorithm, and good salts. This site is a very good reference on password storage.
Use tokens with expiration time

Store the tokens on database, and send them to the client. You don't need to change  the token on every request, you just need to see if the token matches and is not expired. On every new login, expire the older tokens.

Don't trust the client. No matter how secure is the client code, someone can break it. Keep this in mind when designing the security of your system.


it was possible to be infected with malware just from simply opening the email?

Yes, technically it is. [1, 2] Images can have embedded content that is run when your browser or email client trusts external senders (e.g. showing pictures in emails by default). This is why it is especially important to not trust pictures in emails by default unless you know the sender (at home and in corporate environments).

It is of course easier (and additional attack methods are made possible) for an attacker to include a malicious payload in an attachment or website to which they link to in an email -- even at 1KB (though admittedly this is a very small attachment size).

[1] https://www.opswat.com/blog/image-borne-malware-how-viewing-image-can-infect-device

[2] http://www.acenyethehackerguy.com/2017/11/capturing-creds-through-email-and-html.html


It is possible detecting threat by only with file information?

Do a quick search on google and you find a lot of databases.
OWASP offers one with a pretty easy interface: OWASP File Hash Repository.
Simply send a DNS query with the Hash in MD5 oder SHA-1 prepended to hash.sapao.net (see "Testing the system"). If you want to run a large number of queries, I suggest you make a copy of their freely available Amazon AWS image and query local to reduce the load on their server(s).

This does not use ClamAV or Comodo AV, but you can use "dig" for the DNS query and simply "grep" the result.


Could "system volume information" and $RmMetadata pose information leakage on a nuked HDD?

The name of $TxfLog.blf is self-explanatory: The extension blf indicates a CLFS log file, and TxF stands for Transactional NTFS. You can see that TxF is just a temporary file that backs up transactions to help against sudden crashes, just like similar precautions in modern databases. There can exist some leakage from this file, but it only would consist of the last few transactions.

System Volume Information sounds innocent, but it can contain indexes for fast searching the files on the partition. Leakage is very likely here.

Although the method you've mentioned destroys most of the data, traces like these still can leak information about the original data. Most file systems can't be filled to 100%, so that writing files as long as writing is possible doesn't remove all traces. If you didn't like to use linux directly, you could use DBAN.


Trace facebook user ip. Is it even possible?

Directly, no.

Indirectly, it's possible. One way:

Have a web server, whose access log you control, up and running.
Send your chat partner a unique hyperlink pointing to that web server, have them click the link. For example: http://yourdomain.com/JohnDoe.html (the web page does not have to exist, throwing a 404 is fine).
Check your web server's access log to get the IP address of requests to /JohnDoe.html.
You have your conversation partner's IP address.


As long as you don't setup the server yourself you cannot be sure that what you are seeing with ssh is actually what is happening on the server. At the end your ssh access could just be a well built honeypot and nothing you see there relates to real server activity.

Even if you've setup the server yourself you cannot be sure, because there is still the BIOS, the firmware on the network cards, router in between client and server etc. All of these can affect what data get actually transferred to the client but all of these could be used to compromise the data.

And even if ssh shows the proper state of the server and no router, iptables or others are tampering with the server provided data: there might still be an in-memory malware like Darkleech affecting what actually gets served. You will not detect this when looking at the process table and you will not detect this when looking at the files, because it is just in the memory of the HTTP server.


Searching for script headers <script> is a pretty good giveaway, not really necessary, also searching for function-based language with the format ******(***) is helpful. The 'function' declaration is pretty obvious, as is 'var' As far as whether or not it is JavaScript per-se and not a similar language can be a challenging task. Really, though, looking for elements of javascript formatting and syntax that doesn't exist in other languages is going to be your dead giveaway. I have most of my experience with c++, and that's what I would be looking for.

Edit: Also, if it's not valid text it can't be a js, as suggested in the comments. Unless you are looking for compiled executables based on js... in which case... eek.


Secure mount options + partitioning on Ubuntu

The National Security Agency actually publish operating system configuration recommendations. They specifically publish information for hardening Red Hat 5 but this could be adapted to any Linux distribution.

This setup is simply too detailed to quote in its entirity, but the hardening guide gives you a set of services which you can safely remove setuid permissions from. Note that modern linux distributions use capabilities and you should also understand and be able to review these (Red Hat 5 is somewhat old). Specifically and of interest they recommend separate partitions for /var/log and /var/audit. I assume this is because these partitions are somehow securely mirrored such that one cannot remove information from them once it has been written.

I would be careful with your nosuid and noexec options; you might disable legitimate execution and nosuid may not apply to capabilities. I personally think the utmost best defence for any kind of application-level security is mandatory access control, but this is not fully prevalent and available / compatible with all software yet, since many software authors do not take this into account (the old NT assume I'm an admin problem).


Why the Windows Firewall has so many exception rules by default?

I would say main reasoning for this "common application ports being open" issue you are addressing is to avoid a "boy who cried wolf" situation in the future.

If a large majority of Windows connections (and common third party connections like connections made by web browsers) had to be explicitly defined as OK in the firewall rules, your average user would click accept on any request to add a new rule to the system, as legitimate requests from common services are blocked by inbound/outbound rules. Now, whenever there's suspicious traffic travelling through the firewall, your user disregards the concerning message, as it happened with every other legitimate packet.


Replacing revoked SSL with a new cert but domain still showing old revoked cert

Very simple solution for such issue is just redirect all https request to http using 301  and visa versa.

this will refresh browser and server ssl caching.

hope this will help.


How to select a random node when nodes are untrusted in a distributed network?

If you have anonymous nodes, then you have the problem of spawning fake nodes under your control. That is, you have worse problems than a node voting for itself.
So some kind of reputation is needed for each node. I am a fan of "bartering exchanges", where transactions happen within a local group. Trust grows from that small group succeeding to add value equally for each other. That group can form a group identity for performing larger transactions with larger groups, but initially starting small between those groups.
It's important that fair trade is used as the basis for gaining trust. Therefore if a relationship is asymmetric, then it won't last
I don't know what your network is doing so I can't help more without knowing what "value" is exchanged. But I want to assure readers that this value need not mean "money". In the digital world, computing resources may be exchanged, disk storage may be rented, and human laboured services can be rendered anonymously. With a "bartering" model you don't track a currency, but rather trust and equality.
When it comes to vote that occurs within a trusted group, then that groups outcome is signed by group members and shared onward to other peer groups, and so on. Barter trade value is the reputation that either validates the vote or multiplies the weighting of the group vote.


Email is insecure.  It is completely insecure.  Between you and the recipient it likely passed through dozens of servers and for each one it was passed as pure plain text.  Without specific details and logs it is impossible to say where a copy was lifted but regardless you should always ASSUME that anyone can read anything you put in an email.

If that concerns you then you should be encrypting the contents of your email using a tool like GPG.


DMARC none policy overwrites local policy

TL;DR: A DMARC policy of none does not mean that the mail should be accepted. It only means that it should not be rejected/quarantined based on a failed DMARC check. It can still be rejected based on SPF Fail.

  DMARC is used to tell receivers of e-mail what to do if SPF or DKIM fails in mails send from your domain.

DMARC does not define what happens if SPF or DKIM fail. It does not care about failed checks at all. It only cares about the successful and identifier aligned checks (i.e. domain from check must match From in mail header). DMARC passes if at least one of the identifier aligned DKIM signatures or SPF checks passes and fails otherwise. DMARC can define that the mail should be rejected or quarantined based if the DMARC check fails.

A DMARC policy of "none" does not mean that the mail should be kept - it only says that no decision will be done based on the DMARC status. From RFC 7489 section 6.3:

  none:  The Domain Owner requests no specific action be taken
           regarding delivery of messages.

And the example in section B.2.1 says more clearly that p=none should not be treated as a "pass" but as "don't change existing behavior":

  Receivers should not alter how they treat these messages because
        of this DMARC policy record ("p=none")

Thus p=none does not mean to accept the mail but that one should not reject/quarantine the mail and instead can rely on other policies. And SPF defines its own policy. A Fail means that the mail was not sent from a source IP which is allowed for sending. From RFC 4408 section 2.5.4:

  2.5.4.  Fail

  A "Fail" result is an explicit statement that the client is not
  authorized to use the domain in the given identity.  The checking
  software can choose to mark the mail based on this or to reject the
  mail outright.

Apart from that MTA are neither required to implement SPF nor DMARC and they can implement SPF without implementing DMARC and thus reject a mail solely based on an SPF Fail.


I have done this very thing before, the best method I found was to create a job to periodically pull the IP’s from the tor exit node list, this list can  be used to test your rule set against.

The list can be found here.

These scripts can help with converting them into a CSV file to be pulled by your SIEM.


What Trusted Root Certification Authorities should I trust?

All or None.

The singly-rooted CA trust paradigm we inherited from the 90s is almost entirely broken.

Vanilla browsers do not track or alert if the Certificate Authority backing a SSL certificate of site has changed, if the old and new CA are both recognised by the browser1. As the average computer trusts over a hundred root certificates from several dozen organisations2 - all of which are treated equal - any single breached, lazy or immoral certificate authority can undermine any browser anywhere.

The problem is compounded by the fact that almost all of the certificate authorities are not democratically accountable to you (i.e. private companies or foreign governments) and have little or no legally-enforced regulation over their day-to-day conduct. Maintainers of CA lists (Microsoft, Apple, Google, Mozilla, Oracle, etc) do not have the resources, legal authority, or inclination to audit the internal conduct of certificate authorities.

The epistemological riddle of who and what are we actually trusting, that was introduced by a 1990s Netscape trust kludge3, will require an expensive overhaul to resolve. Which I don't see happening this side of an threatened or actual cyberwar.

So.

If your computer (say, a server) doesn't talk out to unknown or ad-hoc sources - then run your HTTPS traffic through a proxy with an explicit list of trusted leaf-node certificates and no root certificates.
For normal computers which browse the internet and update dozens of applications in the background, just trust all of them and follow other security principles to protect your computer instead.

1. Back-end services and frameworks couldn't usefully prompt on change anyway; as they often lack interaction with the user and need to provide seamless operation.
2. See Firefox or iOS CA lists for example.
3. Try as I might, I couldn't re-locate a fascinating web article about how Netscape developers introduced the current Root CA paradigm as quick patch for theorised Man-in-the-Middle attacks for as-yet hypothetical eCommerce. Digital security is hard; and the cold war hangovers and legislative techno-illiteracy of the early 90s didn't help.


Risks associated with HTTP content injection?

Considering that the code they inject can be anything, one would have to assume that there are risks. Perhaps their code has a vulnerability in it that allows injection. Perhaps it obscures important items on the page. Perhaps it references an external resource (eg: JavaScript) of less security. Who knows? It certainly seems a risk to me.

There are other risks that you are exposed to independent of the injection. For example, they are probably providing a custom DNS of unknown behavior. So you're at their risk for DNS security.

In fact, how do you actually know you're using the hotel's WiFi router? In general you can't.

It is considered bad to use open WiFi routers.

Using a VPN (I use PIA) is generally considered a secure strategy.


how message authentication code share keys?

The common way is using the Public-Key to exchange keys. We assume both parties have public-private keys and they shared and verified their public keys before any other communication.

Diffie-Hellman Key Exchange (DHKE); after the key exchange, you can use a KDF two derive encryption and MAC key. DHKE has also a variant that uses Elliptic Curves, ECDH.
To mitigate the man-in-the-middle attack the DHKE needs a signature on the exchanged information. The TLS naming indicates this
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

Key exchange with ECDHE and sign the exchange information with ECDSA. Without the signature, the DHKE becomes anonymous Diffie-Hellman.

RSA-KEM in which RSA can be used to encrypt a uniform random value and this value can be used in the KDF to derive both keys.

You did not mention any encryption mode of operation for symmetric encryption. Actually, we have a modern encryption mode; Authenticated encryption with Associated Data (AEAD). Examples are AES-GCM, Chacha20-Poly1305. AEAD can provide confidentiality, integrity, and authentication. This authentication should not be confused with non-repudiation since both parties know the key you cannot prove that the message is produced only by one party.


As Snort manual is claiming:

The dsize keyword is used to test the packet payload size. This may be used to check for abnormally sized packets that might cause buffer overflows.
This example looks for a dsize that is between 300 and 400 bytes.
dsize:300<>400;

So, this setup is causing the generation and the not-generation of the alert.


Is there any research on which SSL certificate authority has the best browser compatibility

Verisign was in the certificate business from literally the very beginning, and for that reason alone is your top contender for most widely accepted across all devices, versions, technologies, and usage cases. They currently control somewhere around 40% of the SSL certificate market (when you include their other assets like Thawte, according to wikipedia), so a device that does not trust Verisign certificates would be considered "broken" by consumer standards.


How to remove a ca certificate in debian?

Looking at update-ca-certificates, it appears you need to explicitly list what to remove in /etc/ca-certificates.conf:
# Handle certificates that should be removed.  This is an explicit act
# by prefixing lines in the configuration files with exclamation marks (!).
sed -n -e '/^$/d' -e 's/^!//p' "$CERTSCONF" | while read crt
do
  remove "$CERTSDIR/$crt"
done

In other words, leave your cert file under /usr/share/ca-certificates, but put its name in /etc/ca-certificates.conf prefixed with a !.  Just removing the cert doesn't do what you were hoping it would do.


What is the difference between vulnerability identification and exploitation?

When you do a penetration test, you do not want (usually) to break your target. This is why you must choose the payload of your attack (what will be sent to the target service) so that it shows you that a vulnerability exists but without breaking anything.

The examples you show are typical in the vulnerability analysis part of a pentest: they work when there is a vulnerability but they are benign (for a less benign case, see the obligatory xkcd).

An exploit is, as you correctly guessed, the use of a vulnerability to attain an actual goal: extract data, crash a service, implant malware, ...


Password hashing on frontend or backend?

@John already descriped the passing of the password over the network very well (use HTTPS).

To answer your question:

  Where should I hash them? Frontend or Backend?

The backend. If you only hash them in the frontend, you are vulnerable to a pass the hash attack.

The reason that you hash passwords in your database is to prevent an attacker who already compromised your database from using those passwords.

If you hash the passwords in the backend, an attacker has to first crack them to use them on your website. but if you hash them in the frontend, an attacker doesn't need to do this, they can just pass the hash as it is stored in the database.


What type of attack can bring a website down by serving a redirect loop?

Look here at the OWASP article regarding redirects. Check your PHP code.


So I asked Adam Langley, author of the snap start draft. He mentioned that they are no longer working on snap start. Instead, he referred me to QUIC; snap start's design is the basis of QUIC's crypto support.


A stealth scan as it is commonly called is a half open TCP connection. Rather than:

SYN ->

<- SYN/ACK

ACK ->

it goes

SYN ->

<- SYN/ACK

RST ->

It's only referred to as stealth because many applications log a connection on its listening port. As this scan never completes the TCP connection, no log entry is made. Its in no way undetectable. The network stack in the kernel will still receive notification on the connection just the application listening on the port does not.

A bit more information is available here


Can mobile phone data be intercepted or compromised?

First of all KRACK is only at the WiFi level. An attacker gets no more access to data than the operator of the wireless access point would. You probably shouldn't be trusting random cafes more than the average stranger. HTTPS even over a compromised router should still be secure.

Now, on a mobile connection. The short answer is yes - data that is not sent encrypted at a higher level (i.e https) can be read.

The easy option for a false base-station is force your phone to 2G which isn't encrypted.
3G encryption has multiple known weaknesses.
4G encryption should be OK. But its only from the phone to the basestation. A malicious carrier (either themselves or by allowing access to other actors) or someone who manages to read data from the carriers backbone network can get just as much as with KRACK.

  I visit https://www.WebsiteThatRequiresaPassword.com on my mobile via mobile data and type my username and password in, can someone intercept and read my password?

As long as the username and password is sent over HTTPS  (the fact the inital page load was over HTTPS does not guarantee this although some browsers would now warn you if it didn't) and you trust all CAs for which your device has stored root certificates then no they cannot intercept it. The fact it was sent over mobile data is irrelevant.


I have continued access of my Facebook account from a particular iPad/IP Address - how do I stop it?

Your iPhone may show up in the list as an iPad. Mine does. It shows up in a different state because that is where your cellular provider has its nearest hub.

Try this

Open Facebook on your PC and navigate to the "Where you're logged in page."
Take note of which devices are showing "active"
Sign in and out of Facebook on your phone, refreshing the page on your PC, to see if the status changes.
If it changes, then you've been chasing a ghost.


How can I isolate suspicious executables witout deleting them?

What I would use is a virtual machine with Windows Defender turned off. Overall, having a malicious executable on your actual PC is not a good idea and you should always do this kind of testing on a disposable virtual machine.


Someone has my ip address and is threatining to find and leak my personal information

Don't worry too much

It is relatively easy for someone to get your IP address, they just need to get you to visit a website they control. Some forums let people include links to images, which your browser will automatically load and reveal your IP address.

Normally this doesn't let them do much. They can work out your ISP and approximate location, but usually not any other personal information. Potentially they can connect your IP with other online activity, but that's more a Google/NSA thing than some guy on a forum.

You are absolutely right to lock down your router. Knowing your IP does allow them to try to attack your router. Even with a strong password, many routers have had vulnerabilities that allow compromise. But if your router's firewall blocks all ports, you should be ok. You can verify this using an online service like this.

If revealing your ISP and approximate location troubles you, I suggest you use a VPN. They are pretty cheap and easy to use.


The DMZ server in your example could be a simple proxy server.

If you use a well known / open source proxy server, this will obscure a lot of information about your internal server and prevent some classes of attack in the event the internet service is compromised.

You can also use it for secure logging - particularly useful in the event of an incident on either side of the connection


Protecting the remote database against tampering in a mobile app

@Philipp is right when he says that you can't protect against your customer.

Instead of going to great lengths to keep the pseudo-queries secret, you should focus your efforts upon input validation and injection protections.  On the server where you take the pseudo-query and translate it to a SQL query, make sure that you're properly quoting any input to the SQL query, and perform basic sanity checking to raise the barrier against abuse.  A WAF could also help here, but if you're writing your application, you're in the right time and place to put proper protections in situ, which is even better.


Iframe inheriting parent's Content Security Policy

For 3, it seems there might be, and one that should allow you to set a tighter CSP on your other pages/content.

According to https://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/, you can provide specific rights to your iframe (or remove them).

It seems that iframe sandbox is supporter by all your targetted browsers: http://caniuse.com/#feat=iframe-sandbox

So I might create the iframe with the appropriate sandboxing, rather than rely purely on the parent page's CSP policy.

The one unknown (to me) is what happens if/when someone manages to modify the iframe's sandbox


Is this a XSS vulnerability? I can't figure out why it's not working

document.getElementById("results").innerHTML = label_results;

This is vulnerable to XSS. It interprets the label_results variable as HTML.

  var node = document.createTextNode(label_results);

This is not vulnerable to XSS. It interprets label_results as text.

  the paragraph looks like this
Searched:
.

Are you sure? Are you using the inspector in the developer tools of the browser? That can't always be trusted to correctly distinguish between HTML and text.


Downside of allowing uncertified Certificates

The purpose of certificates is to prove the identity of the remote party you are communicating with. Failing this would make it possible for impersonation to take place: active MITM attackers could intercept the traffic and alter it to make it pass as their own.

It's quite similar to verifying someone's identity by checking a passport. Suppose you want to verify the name of the person in front of you, who is showing you a passport.

You want to verify that you trust the authenticity of the passport itself. A local sports club membership card might not be enough. Checking this aspect of a certificate is what building a certification path to a trusted CA in the PKIX specification (RFC 5280/RFC 3280) is for; it also provides other aspects such as what purpose the CA was willing to allow it for.
You want to verify that the passport belongs to the person whose identity you're trying to check. (In this analogy, the server name is more akin to the person's picture, since you're trying to find the person's name, knowing what they look like (*).)

It's one thing to trust the the passport is real, but it should be issued to the person who is claiming its usage. Failing that, anyone who has got hold of a passport of a country you recognise could claim they're anyone in any country you recognise.

In the HTTPS world, this is done following the rules in RFC 2818 (Section 3.1), and more generally in SSL/TLS in RFC 6125.
The last point is not strictly part of the certificate verification itself. You want to verify bind the picture in the passport to the person in front of you. In this analogy, the picture to person link is ensured by the authenticated key exchange in TLS, which guarantees that the remote party has the private key matching the public key in this certificate.

Having performed those three steps successfully, you can then bind the name in the passport to the physical person in front of you.

Certificates in SSL/TLS have the same role: you want to make sure the certificate comes from a CA you trust, make sure that it's issued to the server you want to communicate with, and make sure you're talking to the party to which that certificate was issued.

More specifically in your example, the certificate was issued to DI-PRE-UFCG, which is a different name to the one you're trying to contact and sec_error_untrusted_issuer indicates that the browser doesn't even recognise it as issued by an entity it trusts (which makes sense for a self-signed certificate that wouldn't be imported explicitly).

(*) I'm only making the analogy in that order because it's more natural in practice in my experience. You rarely start off by looking for a specific person by name, given a crowd and their passports, but this could make sense in some circumstances. You would have similar problems if someone had multiple aliases, but the one you're looking for wasn't the one of their passport.


How can I prevent all Windows 10 Telemetry?

Set up a proxy/firewall between you and the outside world. Add a white list of good servers to the proxy. This is very restrictive but the only way to guarantee it (except have no network). A black list could work, but there are always ways around.


What kind of vulnerability is this considered?

Generally speaking you want to split your categorisation into weakness and impact. In this case the weakness is that a process with elevated privileges (root in this case) exposes an IPC mechanism with excessively permissive access control. The impact is that you can access data that you shouldn't be able to as an unprivileged user.

It is easy to get this backwards. For example, you could look at the impact and decide that the weakness is an information disclosure. This is incorrect as the issue does not arise because of an information disclosure. Rather, the issue arises because of excessively permissive access control, and results in information disclosure.


Can a Windows program compromise the desktop hardware without giving administrator rights?

If I run a program on a Windows 10 machine, can the program install a virus on an attached USB drive

Yes. You don't need admin access to write to a USB drive.

  can it install a virus into the firmware of the computer to be loaded before the OS/bootloader?

It shouldn't be able to. Of course privilege escalation vulnerabilities are found all the time - so if you do not have the latest security updates installed or if the exploit used is previously unknown / microsoft are still working on a fix then should the program use one of these techniques it can do it.


Is it possible to change original filename of an exe?

Yes. There is a tool on GitHub here that can change that information. It supports both 64-bit and 32-bit.

The syntax I used: rcedit-x64.exe cmx.exe --set-version-string  OriginalFilename "cmdx.exe" --set-version-string FileDescription "details are irrelevant"

Therefore, your solution may be efficient against beginners, but not against people with IT knowledge.


So if she is hijacking your accounts, she must be maintaining some sort of access. Security questions are easy to guess especially if she's your ex. If you haven't changed your password, now's the time to do that too! Use something that she wouldn't know about.

The easiest way to solve things is to create 100% new accounts. Google also have "two-factor" authentication where you log in with a password and also use an authentication code that is sent to your phone by Google. That way, you need the phone AND the password. Even if she did somehow know your password, she wouldn't be able to log in without the code on your phone.

It's quite possible that she's using very low-key attacks, aka password guessing and security question guessing. As long as she hasn't had access to your computer recently, she's probably not using keyloggers and other malware to snoop on you.

Just for giggles, what have you been noticing?


Is there a "no-spy, no-backdoors standard" for telecom hardware manufacturing?

Given that there had been zero substantial evidence presented that Huawei's networking equipment was ever bugged to begin with, this looks like it's just translation issue.

The "standard" they're referring to is the contract/agreement they're signing, which is the de facto expectation with pretty much the sales and manufacturing of any such business networking equipment to begin with. A better translation would've been "expectation (of the contract)".

With consumer level equipments things becomes a lot fuzzier because of definitions issue. Many consumer equipments are self updating and some may collect analytics for troubleshooting purpose, which with some squinting could be interpreted as a backdoor and spyware. Self updates are generally a good thing and analytics is also not necessarily malicious, as it ensures that the equipments are up to date and patched from any security problems discovered after manufacture, but to some degree a self update feature is essentially also a backdoor as it allows manufacturer to push new software to the device.


Is it okay for our IT support contractor to remote in without authorization?

You haven't actually provided enough details to say one way or the other.  The fact that you didn't see an authentication prompt doesn't preclude there from being one.

The remote access tools I use in my job (which also deals with HIPAA) both require me to authenticate with my domain admin credentials and do not prompt users to accept the connection, because I've configured them that way.


Can we trust encrpytion when the random number generator is compromised?

Can we trust encryption when the random number generator is compromised?

No.  For example, if you are doing AES-128 and your flawed pseudo random number generator creates a 128-bit key, where the key due to flawed random number generation can only be one of 2^40 (10^12 ) options (that are well distributed and appear random), it would be possible for a governmental attacker to simply try all 2^40 options to try brute-forcing your AES-128 key.  Many more attacks of this sort are described on wikipedia.

I don't think its fair to assume that the NSA has compromised encryption by simply compromising all random number generators.  It's probably a multi-faceted approach that ranges from compromising hardware, software (both open source software by submitting new features with subtle flaws) and closed-source software (either develop it yourself, or pay someone off to alter the source code right before it ships), certificate authorities, standards, infiltrating and paying off organizations (like paying RSA Security $10 million to default to Dual EC DRBG with its "rather-obvious" ability to be backdoored).  Possibly even involves number theoretic advances like the ability to break easily factor prime numbers or solve discrete logs which would undermine RSA and ElGamal encryption.

Speculation

My guess is no on this number-theoretic front -- if the government could very easily break RSA moduli easily, then why did they have to shutdown lavabit when the founder refused to give away his private SSL key (versus let him continue to operate and decrypt the traffic anyway).  My personal guess is a lot of it tends to be nonsensical designs that allow programming "mistakes" that undermine security through side-channel attacks like Heartbleed, or software with deliberately introduced flaws (open-source with mistakes like heartbleed or closed-source through modifications secretly made), or hardware with major vulnerabilities in the design.  Yes, it sounds like a conspiracy theory, but to quote the NY Times reporting on leaked Snowden documents:

  The N.S.A.'s SIGINT Enabling Project is a $250 million-a-year program that works with Internet companies to weaken privacy by inserting back doors into encryption products.


How does Stripe Checkout prevent phishing attacks?

Stripe's Checkout overlay doesn't help prevent phishing, but the preferred alternative (iframes) doesn't either, so it's a wash in terms of phishing security.

PCI DSS emphasizes the steps required to secure the server which is providing the overall page to the customer, which in turn should help ensure the validity of the (iframe, javascript, links).  If the merchant's web server gets kicked over, those can all be redirected to a malicious third party, so preventing that is the focus.

Things tend to work out like this:

Outsourcing card data entry to the Processor reduces Merchant scope and improves overall Security
Merchants prefer checkout to be seamless; the customer should not be aware of #1 unless they really want to know.
iframe and javascript can be seamless, but by the same token remove phishing indicators from the process.

In the end, #1 and #2 outweigh the negatives of #3 given the lack of PCI DSS anti-phishing concern.


Why does the RFC 5280 dictate the CAs not to issue certificates with negative serial numbers?

Short answer: because RFC 3280, its predecessor, says so.

Longer answer: because historically ASN.1 encoders/decoders have had problems with properly encoding and decoding integers.

X.509 uses DER encoded ASN.1, which amongst other things, means that the data must be encoded in its minimal (shortest) form. As integers are stored in a variable length twos-complement form, in order to properly encode a non-negative integer which happens to have its leading bit (MSB) set, it must be padded with a leading zero, which in other circumstance is disallowed.
The wording of X.690(http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf )
is such that the leading 9 bits of an integer must be inspected in order to verify the minimal form, thus allowing such positive integers to have leading 0 byte.

To quote Peter Gutmann

  There's a second but: Historically many encoders have gotten the signedness of
  integers wrong, which means that (a) if you get a negative number (at least in
  the area of crypto, which I'm most familiar with) it's always an encoding
  error and never a deliberate use of a negative value, and (b) because of the
  widespread use of incorrect encoders, many decoders treat all integer values
  as unsigned.  So while you can use negative values in theory, it's not a good
  idea in practice.

The correct determination of serial numbers is critical when it comes to revocation checks. Ambiguity is an enemy.

It seems to me that this is exactly the problem your encoder is having...


Why are password boxes always blanked out when other sensitive data isn't?

I don't think this is about secret vs sensitive information, eg "secret information is masked and sensitive isn't." (the distinction is problematic; many secrets need to be shared too).

I think cc and ssn information isn't blanked for several reasons. They're not hard fact, but still, here are a few:

Doing what everybody else is doing, not surprising the user. Passwords came long before web forms and were already masked. So when they were used in login forms, they were masked too. When online business and administration came along, prior art (paper forms) required unmasked entry of sensitive information (obviously), so web forms made the same choice.
It would be very easy to make a mistake and enter a wrong number if you didn't see what you typed. In the case of a wrong password, this is only mildly annoying and you get instant feedback; in the case of other wrong sensitive data, this might have further consequences which isn't immediately clear (such as a request to a government office being denied because of a wrong SSN or a payment not going through - although in the cc and ssn cases, this is usually  hedged against by looking if the checksum is right and providing immediate feedback if it wasn't)
Many people don't know their cc number from memory and copy it down from the actual credit card. So the number is there to be seen by a bystander anyway; blanking the entry field wouldn't help much to protect the number at the client end and thus doesn't merit the additional difficulties caused by 2.
Impact - A stolen cc number doesn't necessarily have the same impact as a stolen password, especially if you consider that information stolen by looking over your shoulder would most likely be stolen by people who know you (collegues at work, family members, classmates etc) and want your password for a very specific reason that would have personal consequences. OTOH, even if they were interested in your cc number, you wouldn't have to take the financial damage because the cc company would probably cover it. For the same reason, you don't mind letting a waiter or store clerk see your credit card, even though he could copy it and sell it to someone else...

Number 4 may not apply to other kinds of sensitive information, though.


I had to stop apache2. SEToolkit does NOT use Apache. It uses it's own HTTP daemon. I had to Google how to turn apache ON in the config file. Please mark this as solved.


Why don't we use hash based digital signatures everywhere?

If it is known that existing digital signature schemes like elliptic curve crypto or RSA are vulnerable to quantum computers, why haven't we already switched to Lamport signatures or something like that?

Quantum computers were not a realistic threat when these algorithms became standardized and widely deployed. As indicated in the comments by @Steffen Ullrich, hash-based signatures carry some disadvantages. The size of the public/private keys and the size of the signatures can be a non-negligible downside if quantum computers aren't relevant.
Additionally, some hash-based signature schemes are stateful. Stateless schemes carry a big advantage over stateful schemes in regards to implementation simplicity.

Is there something that prevents people from deploying this type of signature right now?
I understand that we still believe/know that nobody has a good working quantum computer yet but why not make the switch anyway?

For a cryptographic algorithm to be adopted for use in the real world, it needs to be standardized.
Hash-based signature have been submitted to NISTs call for post-quantum algorithms.. It is entirely possible that hash-based signatures will become standardized and recommended for use - assuming that they survive the analysis. The deadline for submissions was just closed (November 30, 2017) and it will probably be a few years before anything is standardized.


How do servers protect against straight up sending a HTTP request that is actually some malware or HTML code?

Here is an image of the SARS-CoV-2 genome. Will looking at the image give you COVID-19? Of course not. While you could call this the biological equivalent of "malicious code," it doesn't cause any harm unless it's presented in a format and context where it might be "executed."
The same concept applies to computers - code or data that is dangerous in one context can be completely inert in another context. If you send malicious code or data to a web server, unless it's specifically designed to target a flaw in the web server, it will just be treated as data and it will have no meaningful effect.


Are there any risks in just sshing into a compromised server?

I would say that if you will just connect there, nothing should happen. Except you give him your IP so he can theoretically focus you. If you have correctly configured your client.

It really depends on the security of your client setup and another servers you use. If you authorize / sudo yourself using the key the probability he will be able to exploit another server is quiet low.

But many times I also saw tunelling over SSH setup in the way the servers were able to access each other over the SSH channel opened by the user. And keys were stored on "compromised server".

As I said in the beginning. It really depends on many other things, I would say, its hardly possible but not probable if other security recommendations will be followed.


Pen Testing ASP.NET application with Backtrack

Linked are some videos which can give you a running head start: "Web Application Pen Testing Tutorials" however, firing off a tool or two at an application is not a reliable mechanism to ensure security. Since you stated: "we have developed an ASP.NET Based Enterprise Application", your best best is to work using say Agile or other SDLC based TEST CASES and create your own MISUSE cases. Link: "Software Security, Misuse, Fault Injection"

The reasoning/rational behind this comment is, you (the company, developers, etc.) are the ones who made the application. You know (have documented) how it is supposed to function, and what it is NOT supposed to do. You can create "specially targeted" attacks against your own application that can yield better results.

The issue with tools are, they are pre-programmed with "known knowns." Attacks and attackers all evolve. So relying on one tool can leave you still vulnerable if the author of the tool, was unaware of a new threat. This was the issue with JAVA recently where there were issues, Oracle would sandbox, an attacker would re-break it, they'd patch it, and another attacker would re-break that too.

For something like this (application testing), its a very broad thing. You can use fuzzers, networking tools, and a smorgasbord of everything and anything, and still get it wrong. It pays to begin from the ground up:

What does my tool do (test case)
How can someone abuse that my tool is supposed to do? (misuse/abuse case)

E.g.:

Test Case 1: Application takes input from user (a name)
Misuse Case 1: Rogue user tries to enter something other than a name (unicode, hex, etc.)

EDITED

I decided to re-comment on this since I see the "hire a professional" answer. While this would a better thing to do since "professionals" tend to be better equipped and experienced to deal with this, they too can and so fail. An SDLC like approach should be at the forefront of developing secure code. Testing against (hiring a pro) this SDLC practice should come secondary. There is a HUGE difference in penetration testing, and application security. See: "Writing Secure Code"


What is described in the question is Format Preserving Encryption. However, expect a steep learning curve, and a severe lack of ready made implementations.


Is there a reasonable chance of a well-funded agent obtaining raw traffic over Tor circuits

«Since January 2020, a mysterious threat actor has been adding servers to the Tor network (...) by May 2020, they ran a quarter of all Tor exit relays» (ZDNet)
SecurityWeek clarifies the number as 380 exit nodes. See also the full Nusenu post
Note that this attacker was probably only interested in positioning exit nodes.
So yes, a well-funded agent would be able to control substantially more than 20 relays.

wouldn't this agent be able to consistently get complete circuits through their relays and, as a consequence, have complete access to the data it was relaying?

Not really a consequence. Data is encrypted to the target nodes. If you are using a plaintext protocol (like HTTP), the exit node knows the full contents of the communication. The agent only needs to be chosen as an exit node, and the previous ones are irrelevant.
If the target was a hidden service, or even just a https website, the exit node won't know the contents of the communication (it would know which https server you are communicating with, and the traffic flow, but not what was transmitted).
The point on controlling a full circuit is about deanonymizing users, in order to know not only what was sent but also the origin ip address (which might then be tracked to its physical location and the person behind that)
As for the number of circuits being established, you may be right, but the calculation won't be as simple. The tor client doesn't pick nodes at random. Most importantly, the EntryGuards will try to stick to connecting to the same nodes so that, you won't be at the mercy of many different entry node operators, only a few of them. If you were lucky picking them (they are honest), you'd be safe. See the EntryGuards FAQ


Could a malicious server compromise a Yubikey OTP and use it to login to other servers?

Yes, if the compromised server does not validate the OTP for the purpose you expect, it can use it to attempt to connect to other of the services that work with the same Yubikey. This would be a man in the middle attack with the particularity that the "man in the middle" happens to be one of your servers (the compromised server). The Yubikey OTP scheme itself does not protect against such attacks.
This assumes that the compromised server is not a Yubikey validation server. If this is the case, you should assume the attacker can generate OTPs of any sequence number. In other words, the attacker virtually possesses a copy of the Yubikey. This is because validation servers know the secret that is stored on the Yubikey if the key is registered with them.


My recommendation is to use a completely separate key.  Because you're signing backups, only you need to trust the separate key, so there's not a web of trust issue here.  You can even sign it with your main key, if you like.

A second option is to load a gpg-agent and load the key.  You'll need to set max-cache-ttl=-1 and default-cache-ttl=-1 to allow it to keep the key indefinitely.  You'll still need to type in the passphrase once per boot.  (I haven't tested the -1 options, that's based on reading the code that -1 is infinite.)

If you don't want to do that, you could copy your GNUPGHOME (~/.gnupg, typically), delete the other subkeys, and change the passphrase on the key.  Then have duplicity use this subkey-only installation with the new passphrase.  (Just set the GNUPGHOME environment variable to work with the different home directory.)


Should I use CSRF protection for GET requests?

CSRF protection is only needed for state-changing operations because of the same-origin policy. This policy states that:

  a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin.

So the CSRF attack will not be able to access the data it requests because it is a cross-site (that's the CS in CSRF) request and prohibited by the same-origin policy. So illicit data access is not a problem with CSRF.

As a CSRF attack can execute commands but can't see their results, it is forced to act blindly. For example, a CSRF attack can tell your browser to request your bank account balance, but it can't see that balance. This is obviously a pointless attack (unless you're trying to DDoS the bank server or something). But it is not pointless if, for example, the CSRF attack tells your browser to instruct your bank to transfer money from your account to the attacker's account. The success or failure page for the transfer is inaccessible to the attacking script. Fortunately for the attacker, they don't need to see the bank's response, they just want the money in their account.

As only state-changing operations are likely to be targets of CSRF attacks, only they need CSRF defenses.


Is there a way to send a password over JSONP (GET) over HTTPS (SSL)? Crypto maybe?

JSONP is usually used with a server sending data to a client, wrapped in a function call which gets executed on the client by javascript.  Sending data to a server does not require JSONP, it just requires a normal HTTP request.

You should definitely not use the GET method for submitting username + password pairs. Secondly your response from the server should not include the login credentials themselves; the sensitive login data should only go one direction (from the client to the server) and never be reflected back. What I would suggest is two asynchronous calls, one to each server. You probably want to do this in parallel, rather than one after the other, using Promises. Then if both promises resolve and both servers indicate successful login, send back session id's or tokens in the response from each server.


7zip AES encrypted archive, padding oracle attack

A padding oracle attack is not helpful in cracking a 7zip archive.  In a padding oracle attack the attacker must be able to decrypt arbitrary ciphertext, and the target must return a signal notifying the attacker that the padding of the arbitrary ciphertext is correct or not.

In the case of a 7zip archive where you do not know the password, you cannot decrypt the archive, so there is no way of knowing, if the padding is valid to begin with.


What are some instant red flags when scanning an network with nmap

To echo gameOver's comment and elaborate further, simply detecting that a port is open is interesting but I wouldn't see it as an immediate 'red flag'. Perhaps a better approach might be to run Nmap with the -sV or -sC flags which will either run a service/version scan or launch the default NSE (Nmap Scripting Engine) scripts against the target port that you've deemed interesting, provided you have the proper authorization to do so.

So, for example let's say you discovered  that port 21 is open, which is interesting, but it only becomes a potential attack vector when you can enumerate the service running behind it. Once you discover the specific service you can begin searching CVEs and gain a better understanding if there is a vulnerability tied to it. By running a script-scan, the NSE will test your specific port in question and will output its findings, this might include (for port 21) an anonymous FTP login misconfiguration that allows for read/write access.

Now, after further enumeration of the service running behind port 21, you have a potential attack vector.

As a final note, there are some known ports where specific types of malware have a history of using, but these can also be false positives as I could simply run my SSH client out of TCP port 31337. You might see this port as open and immediately think Back Orifice! Instead I'm just running SSH using an unusual port to do so.

Sources:

https://nmap.org/nsedoc/scripts/


Almost certainly, but it may not translate to a reliable exploit. As you are controlling ESI, EDI and ECX you are most likely controlling a byte copy operation and I'm assuming the crash is caused because you're trying to read/write to an address like 0x41414141.

At worst you can hard code some addresses where ESI points at the start of your shell code, EDI points to the next instruction address (EIP+opcode bytes). ECX should be the length of your shellcode. This will overwrite the next series of instructions with your shell code.

For a more reliable exploit you would have to do some more analysis on how you ended up controlling these registers and what code paths are available depending on what you point these registers at.


How bad it would be? If hackers managed to take down all 13 Root DNS servers at the same time?

It probably wouldn't be as horrible as you'd think.

First of all, the Domain Name System is a critical part of the Internet and DNS root servers are at the top of the hierarchy as they fulfill requests for the root zone. So, if you want to determine the IP address for a domain name (e.g. security.stackexchange.com) your very first step would be asking a root server for the authoritative name server of the .com TLD. Then you would go further down the hierarchy until you have resolved the name to an IP address.

In theory this means that without root servers, domain name resolution would fail globally, making major parts of the Internet unavailable -- but:

There is lots of caching and redundancy. A root server outage wouldn't be immediately result in servers becoming unavailable as your operating system as well as intermediate DNS servers all maintain their own caches, so they don't have to repeatedly issue the same requests. It would take some time until these entries expire and the queries actually fail. Caching is also the reason why the root servers actually only receive a moderate amount of requests.
Network administrators (and ISPs) can take easy countermeasures by maintaining their own copy of the root zone file, which then wouldn't be updated but could substitute the purpose of the root servers during an outage without noticeable impact on their users.

Also, the root server infrastructure is very robust, as concluded after the DDoS incident in 2015 (although the attack could have been made much worse using amplification techniques). While "13 root servers" doesn't sound like a lot, there are actually globally distributed server farms behind it (the root servers use Anycast routing):

  In fact, each “server” actually consists of a server farm of many physical servers in multiple locations, for reliability.
  Server L, for example, is mirrored in 128 locations in 127 towns and cities (San Jose, California, hosts two instances) in 68 countries, from Argentina to Yemen.

(Source)


Why does a deauth attack work on WPA2 despite encryption?

The use of encryption in 802.11 is limited to data payloads only. Encryption does not apply to the 802.11 frame headers, and cannot do so as key elements of 802.11 headers are necessary for normal operations of 802.11 traffic.

Since 802.11 management frames largely work by setting information in the headers, management frames are not encrypted and as such are easily spoofed.

To prevent deauthentication/disaccotiation attacks, the IEEE implemented the 802.11w amendment to 802.11. This provides a mechanism to help prevent the spoofing of management frames, but both client and infrastructure need to support it (and have it enabled) for it to function. You can find a bit more information on 802.11w in my answer here if you wanted to learn more.


Will two smartphones (identical hardware and software) generate the same canvas fingerprint?

This site describes the techniques used in canvas fingerprinting:

The technique is based on the fact that the same canvas image may be rendered differently in different computers. This happens for several reasons. At the image format level – web browsers uses different image processing engines, image export options, compression level, the final images may got different checksum even if they are pixel-identical. At the system level – operating systems have different fonts, they use different algorithms and settings for anti-aliasing and sub-pixel rendering.

So this sounds like it is fingerprinting the algorithms and config settings that your device uses to render a canvas.

It looks like wikipedia/Canvas_fingerprinting answers this question fairly directly, so I'll quote the relevant section in full (emphasis mine):

Uniqueness
Since the fingerprint is primarily based on the browser, operating system, and installed graphics hardware it does not uniquely identify users. In a small-scale study with 294 participants from Amazon's Mechanical Turk, an experimental entropy of 5.7 bits was observed, but the authors of the study suggest more entropy could likely be observed in the wild and with more patterns used in the fingerprint. While not sufficient to uniquely identify users by itself, this fingerprint could be combined with other sources of entropy to provide a unique identifier. It is claimed that because the technique is effectively fingerprinting the GPU, the entropy is "orthogonal" to the entropy of previous browser fingerprint techniques such as screen resolution and browser JavaScript capabilities.

Summary
It sounds like if two devices are running the identical hardware and software, then they will produce the identical canvas fingerprint. So it seems like canvas fingerprinting is not a unique identifier by itself, but rather is part of a healthy diet of data that websites collect about you.


What type of SSL certificate do I need for communications between an Android app and a web service?

You are not communicating directly with MySQL, you're communicating with REST server (presumably over HTTPS), and therefore need an SSL certificate, not for MySQL, but for your REST API.

If the REST service is your own, then you need to make it SSL-enabled by installing a certificate on the web server that runs it. If it's run by someone else, then they need to do so.

And if it's your service, and only used by your client, then you can (and probably should if you know how) create your own SSL CA to sign the associated certificate, and then code your application to only trust certificates that you sign. This would mean that you don't need to purchase certificates and also means that you can't fall victim to any sort of SSL MITM attack. Bear in mind that you should only go down this route if you really know what you're doing. Otherwise, just purchase a domain-validated certificate like everyone else does.


Does the file encryption of Microsoft Office guarantee integrity?

Based on the latest MS Office spec, "agile encryption" uses a SHA1-based HMAC for message authentication:

https://interoperability.blob.core.windows.net/files/MS-OFFCRYPTO/[MS-OFFCRYPTO].pdf

Office 2016 appears to use agile encryption by default:

https://docs.microsoft.com/en-us/DeployOffice/security/cryptography-and-encryption-in-office


Any useful tools for Android source code review?

Try LAPSE+, Yasca, CodePro AnalytiX, Klocwork Solo, and the Teachable Static Analysis Workbench.

Be sure to check out The Denim Group's blog post on Using static analysis to review file access in android apps, which includes some tools written in Perl.

When Angry Birds Attack Android Edition is the latest blog post from TEAM JOCK, who presented on this research during this video at Shmoocon with a talk entitled [PDF - TEAM JOCH vs. Android: The Ultimate Showdown - PDF].

Nils also presented on Building android sandcastles in android’s sandbox at a recent BlackHat.

ENISA has done a more formal job at modeling the risks to smartphone platforms with their Smartphones: Information security risks, opportunities and recommendations for users paper. Cigital has at least one blog post on Moving to Mobile - New Threats which also covers threat-modeling topics.


Hiding Tor traffic to prevent deanonymization

When generating Tor traffic is suspicious then the best way to hide is to not use Tor. What is your end goal and who is your adversary? You only really need Tor when you want to connect to a hidden service. For normal websites you could just use a VPN/proxy or multiple of those.
For VPN  + Tor creating lots of (non tor) traffic will make analysis at least harder.
Many bridges are public. Using obfsproxy + a private bridge would maybe not stick out that much but the protocol still does not look like standard internet traffic. The host for the private bridge will know you use Tor. The bridge itself is also not invisible since it needs to connect to other Tor nodes in order to work. Meek is better than obfsproxy because it looks like TLS. There is also another upcoming pluggable transport which should make the connection look like a normal browser.


How can I demonstrate the reflected XSS via post methods

The fact that the alert doesn't show, doesn't mean it's not there and in return it means input validation is not performed. That alone should be sufficient.

My next thought is (if the content type is set to html and not to json) to change the payload. What happens if you do:

<script>document.location.href="http://www.google.com";</script>

Assuming that a web application is used in front of the API, perhaps you can demonstrate a cookie stealer scenario.

In addition, you could demonstrate the alert box when using a proxy such as Fiddler and Burp Suite: Select the response, then click "generate HTML".


Does an established HTTPS connection mean a line is really secure?

It's important to understand what SSL does and does not do, especially since this is a very common source of misunderstanding.

It encrypts the channel
It applies integrity checking
It provides authentication

So, the quick answer should be: "yes, it is secure enough to transmit sensitive data". However, things are not that simple.

The newest versions of SSL - version 3, or better yet: TLS, even TLS 1.2, are definitely better than previous versions. E.g. SSL 2 was relatively easy to MITM (Man in the middle). So, first it depends on protocol version.
Both the channel encryption and the integrity checking are configurable in the protocol, i.e. you can choose which algorithms to use (cipher suite). Obviously, if you're using RSA1024/SHA512 you're much better off... However, SSL even support a mode of NULL encryption - i.e. no encryption at all, just wrapping the requests up to tunnel over SSL protocol. I.e., no protection. (This is configurable both at the client and the server, the selected cipher suite is the first matching set according to the configured order).
Authentication in SSL has two modes: server-authentication only, and mutual authentication (client certificates). In both cases, the security ensured by the cryptographic certificates is definitely strong enough, however the validity of the actual authentication is only as good as your validity checks: Do you even bother checking the certificate? Do you ensure its validity? Trust chain? Who issued it? Etc.
This last point re authentication is a lot easier in web applications, wherein the client can easily view the servers certificate, the lock icon is easily viewable, etc. With Web Services, you usually need to be more explicit in checking its validity (depending on your choice of platform). Note that this same point has tripped up so many mobile apps - even if the app developer remembered to use only TLS between the phone and the server, if the app doesn't explicitly verify the certificates then the TLS is broken.
While there are some mostly theoretical attacks on the cryptography of SSL, from my PoV its still plenty strong enough for almost all purposes, and will be for a long time.
What is actually done with the data at the other end? E.g. if its super-sensitive, or even credit card data, you dont want that in the browsers cache, or history, etc.
Cookies (and thus authentication) can be shared between a secure, SSL channel, and a non-secure HTTP channel - unless explicitly marked with the "secure" attribute.

So, shorter answer? Yes, SSL can be secure enough, but (as with most things) it depends how you use it. :)


How can I intercept Android application's SSL traffic where SSL pinning is used?

SSL Pinning is the additional layer of security implemented at the client side to let the mobile application only trust a particular SSL certificate during HTTPs connection establishment and not the certificates installed in the device trust store. Since the implementation is the client side implementation, it can be easily bypassed using the following techniques:

Automated Approach

Xposed modules such as SSLUnpinning 2.0.
FRIDA(Dynamic Instrumentation Tool)-Universal SSL Pinning Bypass Script.
Inspeckage-Android Package Inspector

Manual Approach

I feel this is the last, bit complex and the most reliable solution for bypassing SSL Pinning. The following are the steps to perform the same.

Understand the implementation of SSL Pinning. You can refer to this Medium blog which explains the implementation of SSL Pinning using different network libraries such as OkHttp, Volley, Retrofit etc.
Analyze the responsible method and map the same with the SMALI code.

Once the responsible method is analyzed and identified, we can use the following approach for bypassing SSL Pinning:

Tampering Application

Tamper the SMALI code to bypass SSL Pinning.
Re-Build the application using APKTool.
Resign and install the application and capture the traffic.

Reference: https://samsclass.info/android/codemod.html

Runtime Hooking
Once the responsible method is identified use runtime hookers such as FRIDA, JDB to hook the method and change the implementation.


Generic solution for sharing a secret is Shamir's algorithm. This is not hard to implement, but it requires some mathematical knowledge. I am not aware of a ready-to-use open-source .NET implementation.

An easier solution is to use a hash function. If you have n people who each own a "secret element", then just concatenate all the secret elements in due sequence, hash the lot with SHA-256, and take the first 128 bits of the SHA-256 output as key for AES-128. This scales to more than two shares, and avoids any potential issue with a "partially known" AES-256 key; also, it lets you use the much more sensible AES-128.

There is no known issue with a half-known 256-bit AES key, but AES is known to be somewhat flaky with regards to related-key attacks which, from a general overview, somewhat look to be potentially relevant. To be brief, it seems somewhat risky to rely on AES being robust against partially revealed keys.


How do I know that mobile apps aren't stealing my login info?

You can't, which is one of the big problems with password-based authentication for mobile apps.

Reddit also offers and strongly encourages use of OAuth. You can read more about OAuth elsewhere, but the summary is that each individual app gets its own token to use to authenticate to your account. This means you can revoke access for one app without needing to change your password for the website or other apps. In many OAuth implementations, you can specify a restricted set of permissions for each token as well, so you can limit the app from doing things other than what you expect it to.

However, many reddit apps have implemented the OAuth flow in a way that still allows them to sniff your password. The flow involves sending the user to reddit.com, where they authorize the app and are redirected back to the app. The least disruptive way to do this is to use a webview inside the app, but then the user is still entering their password into the app!


How can Microsoft validate a shorter password on Microsoft accounts (MSDN)?

Three possibilities:

Microsoft was always truncating it and you just were not aware.  Can you use the old system with a 16 character password and wrong characters at the end?
They were storing the passwords in plaintext (or equivalently encrypting the passwords, allowing them to decrypt the password to truncate it).
When you first migrated accounts (or secretly in anticipation of you eventually migrating), they required you to enter the full 18-character password, checked that you were who you said you were against that, and then created and stored a new 16-character hash of the truncated password for the new system.  This is unlikely but possible.

Regardless, truncating passwords or forcing short password lengths is bad password policy.  It prevents easy-to-remember moderately strong passphrases; e.g., correct horse battery staple which is 28 characters long.  Password lengths should not be truncated until at least ~50 characters or so.  If your database requires a fixed maximum length, it probably makes sense to truncate somewhere around 100 characters or so at which point it is allows passphrases which probably have more entropy than can fit into a 128/256 bit hash which are perfectly strong hash lengths.


Why do we trust session info over the wire but not an OAuth access token?

If the attacker would've been able to get the access token, surely they can get the cookie storing the session information

An XSS attack can't get to the cookie if you specify it with HttpOnly. It must have been an oversight, he really should have mentioned this. Oh, and Secure (HTTPS-only) as well. Then this cookie can't be stolen via XSS or MitM'd/sniffed.

  Why is it that we consider encrypted cookies with session details in them safe,

So by putting the tokens in a cookie marked HttpOnly, they're safe from XSS. By encrypting them, you've prevented them from getting leaked, intentionally or not, for example by the user inspecting his cookies.

  but trusting the client with the actual access token is considered insecure?

This problem isn't really the client but rather an XSS attacker, who could steal the access_token and then impersonate the user.

But now that we're using cookies, his last statement, made almost as an afterthough, is important:

  To protect an attacker just stealing the cookie you can use CSRF protection measures.

To mitigate CSRF, you can enforce on the server that the client provide an X-Requested-With (or other custom) header. That will prevent malicious sites or XSS-hacked sites from calling your APIs because the browser's cross-domain restrictions won't let them add custom headers, and then you can reject the requests.

  What is actually the most secure way for a single page application to prove it's identity to an API?

I've been looking around and I think this approach, using a proxy server-side, is it. You'll find variants of it elsewhere googling around, for example here and here, but Alex Bilbie's approach of encrypting the access_token has an advantage over those two that there is never a window (even a short one) where the access_token is vulnerable to XSS.


Chrome/ Opera continue to save & autofill passwords after installing LastPass? Good or bad? Enable/ Disable?

What's happening

Both the built-in and Lastpass password managers are trying to auto fill/auto login and probably the built-in password manager gets precedence over Lastpass.

Pros and cons
Pros:
Your passwords are stored redundantly.

Cons:
Multiple popups to save /override passwords/login when saving new login data.

More efforts in terms of manageability.

Recommendations

Turn off built-in password manager/lastpass (either via browser settings or use the option from Lastpass's settings.

Lastpass allows saving the cross browser& cross platform login info in cloud, so you can access it from any* device using your credentials. I suggest you use it.

*some device features are available only in premium and enterprise versions. Eg: mobile addons.


Is there a security risk using bluetooth computer speakers?

Yes, enabling Bluetooth will increase your attack surface.  If you do not have Bluetooth enabled, you close a whole series of possible attacks.  There was a series of vulnerabilities disclosed recently which highlight the risk of having Bluetooth enabled.


How does the authentication flow with Azure Active Directory differ from Azure ACS?

HRD is done through two different mechanisms, which are used in either passive or active contexts. The passive method will determine the realm based on the username after they've lost focus of the username field. A lookup is done of the username and determines what tenant the username is tied to. If the tenant requires federated auth the site will redirect to the new IdP. The active method determines the realm based on the incoming username, and if federation is required a pointer is returned to use the IdP's endpoint.

Whether HRD is necessary is dependent on the authentication method tied to the domain of the user. HRD is required for domains whose AuthenticationMethod is marked as Federated.

The basic process works like this:

Get suffix of UPN
Look up suffix in domain list
If domain present look at AuthenticationMethod
If method == Managed, don't redirect
If context == passive get PassiveLogOnUri
If preferred protocol == WS-Fed redirect to PassiveLogOnUri and set wtrealm = urn:federation:MicrosoftOnline
If preferred protocol == SAML redirect to PassiveLogOnUri with SAMLRequest
If context == active get GetActiveLogOnUri and return to caller

You can look at these values by using the MSOL PowerShell cmdlets and calling Get-MsolDomainFederationSettings, Get-MsolDomain, etc. See here (disclosure - I wrote the post): http://www.syfuhs.net/post/2012/12/07/Windows-Azure-Active-Directory-Federation-In-Depth-(Part-2).aspx

I'm not sure what you mean by the request-response patterns though. In a scenario that requires HRD, it basically works like

  RST-> IdP (AAD) -> RST-IP (ADFS) -> RSTR -> IdP (AAD) -> RSTR


Unknown malware, how to report it and whom to report it to?

If you can find the offending executable or dll, one thing you can do is to upload it at https://www.virustotal.com. Try even the svchost file if you feel it's suspicious.

It will show you how many antivirus engines detect it out of a huge list, and will also forward your sample, if it fails to be detected, to antivirus companies for further processing and signature development.


Why do multiple IP Addresses in my local network point to the same computer?

This is explained in the Virtualbox manual. Since your VM is a Virtual Machine, it runs on hardware that does not actually exist, and sees a network containing equally virtual other nodes. The manual above contains the following:

  In NAT mode, the guest network interface is assigned to the IPv4 range 10.0.x.0/24 by default where x corresponds to the instance of the NAT interface +2. So x is 2 when there is only one NAT instance active. In that case the guest is assigned to the address 10.0.2.15, the gateway is set to 10.0.2.2 and the name server can be found at 10.0.2.3.

And a few lines later:

  For network booting in NAT mode, by default VirtualBox uses a built-in TFTP server at the IP address 10.0.2.4.

So the IP addresses that the guest VM sees as 10.0.2.2, 10.0.2.3 and 10.0.2.4 are addresses for virtual nodes that Virtualbox maintains on the virtual network to which the guest VM believe that it is connected; the guest VM itself is awarded IP address 10.0.2.15 on that network.

All of this happens within the entrails of Virtualbox; the host operating system (Windows 7) is completely unaware of it. When the guest VM sends an IP packet with target address (for instance) 10.0.2.3, the packet is sent on the virtual network interface: the guest VM sends an I/O request on that "hardware" (with an out opcode); the opcode triggers a CPU exception trapped with Virtualbox, which then sees the packet contents (they are in RAM) and acts as if a network interface really existed. From the packet contents, Virtualbox notices that it is meant for one of its virtual nodes, and computes a response packet, puts it in the RAM buffer that corresponds to the buffer for the virtual network interface of the guest, and triggers an interrupt request for the guest, there again as if there really was a network card able to warn the guest CPU about incoming data. Everything about virtual machines and emulation is smoke and mirrors, and this includes the whole virtual network that the guest VM is part of.

From the point of view of that Windows, there is only a process (Virtualbox) which possibly issues network-related system calls; the 10.0.2.x addresses are invisible to it.


How does forward secrecy beat public-key encryption if the key is regularly updated?

Well forward secrecy is usually achieved exactly by what you propose, namely ephemeral public (usually Diffie-Hellman) keys. This basically works as follows:

Generate some DH parameters.
Sign the public parameters via your longterm public key.
Send parameters and your signature over the parameters to whatever computer you want to talk to.
Use the ephemeral parameters to generate a shared secret from which to derive symmetric keys.

If you look at the key exchange mechanism for most HTTPS connections you'll see part of the ciphersuite is usually ECDHE_RSA, meaning ephemeral Diffie-Hellman (over an elliptic curve group) with the parameters signed via RSA (the RSA key being the servers long-term private key for which the corresponding public key is found in the servers certificate).

It is important that you sign your ephemeral keys with your long-term private key, otherwise an attacker would be able to upload a key of their choice to say the WhatsApp servers and read all messages intended for you as there would be no way to verify the ephemeral keys legitimacy.

  Once one message under forward secrecy is compromised, subsequent messages would become readable. The method just described would be stronger in that respect.

This is not correct, only messages related to the session whose ephemeral parameters were compromised would become readable. The next session would have different ephemeral parameters and would still be secure.


Https server side, as well as client encryption?

No, the whole point of TLS is to encrypt the traffic between your app and your server. TLS deals with the key distribution, which would otherwise be a really hard problem. TLS was made exactly to solve your problem. Adding another encryption layer that is essentially the same as TLS does not add any security for your system. It only increases complexity (attack surface).

Make sure your TLS implementation is secure and users cannot bypass it (using legacy HTTP or something). Consider using modern security features like strict transport policy and focus on web security (XSS, CSRF, etc.). Experience shows that most of the time the implementations are insecure, not the crypto.


Is having Steam installed a security risk?

From what I can tell, there have only been two serious public vulnerabilities in Steam.

Markup injection (XSS) from steam:// links
HTTPS man-in-the-middle attack

Neither are current. I can't see any real risk. However, since Steam is completely unnecessary at work, it's a minor potential risk that could be avoided.

Most likely, he's nit-picking because he doesn't think having Steam installed is appropriate at work, but he doesn't want to be the bad guy.


Actually if there is XSS,  CSRF tokens don't offer any protection. The moment you can inject JavaScript, you could easily also fetch the token protecting the form.


Logging server compromised (IptabLes and IptabLex)

You should never leave Elasticsearch open to the world, in the same way as you wouldn't leave any database server open to the world.  Always put a proxy in front of it and use (at least) HTTP auth.  Preferably, your proxy should limit what can be done from outside, eg only allowing GET requests, otherwise any user could delete all your data or shutdown your servers.

From version 1.2.0 onwards, dynamic scripting (passing a script as part of eg a search request) has been disabled by default.  On older versions it is enabled by default, meaning that any outside user could do anything on your server that the Elasticsearch user can do.

If you're running an older version, you want to add this to your config/elasticsearch.yaml:

script.disable_dynamic: true

See http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/modules-scripting.html#_enabling_dynamic_scripting for more, and http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/url-access-control.html#url-access-control


Disclaimer: My organization uses MobileIron, but I am not my organization's MobileIron administrator.  However I have some experience with other MDM solutions.

I would suspect that MobileIron still needs to monitor for activity in various areas.  Also, it needs to allow for containerization of corporate email, files, photos, etc. separate from personal content.  Just because MobileIron is asking for permission to view and get its fingers in those areas, doesn't mean that the MobileIron administrator will be able to view all the photos on your phone that are not in the container.