Is dual-booting an OS more or less secure than running a virtual machine? I run two operating systems on two separate disk partitions on the same physical machine (a modern MacBook Pro). In order to isolate them from each other, I've taken the following steps:

Configured /etc/fstab with ro,noauto (read-only, no auto-mount)
Fully encrypted each partition with a separate encryption key
    (committed to memory)

Let's assume that a virus infects my first partition unbeknownst to me. I log out of the first partition (which encrypts the volume), and then turn off the machine to clear the RAM. I then un-encrypt and boot into the second partition. Can I be reasonably confident that the virus has not / cannot infect both partitions, or am I playing with fire here? I realize that MBPs don't ship with a TPM, so a boot-loader infection going unnoticed is still a theoretical possibility. However, this risk seems about equal to the risk of the VMWare/VirtualBox Hypervisor being exploited when running a guest OS, especially since the MBP line uses UEFI instead of BIOS.

This leads to my question: is the dual-partitioning approach outlined above more or less secure than using a Virtual Machine for isolation of services? Would that change if my computer had a TPM installed?

Background:

Note that I am of course taking all the usual additional precautions, such as checking for OS software updates daily, not logging in as an Admin user unless absolutely necessary, running real-time antivirus programs on both partitions, running a host-based firewall, monitoring outgoing network connections, etc. My question is really a public check to see if I'm overlooking anything here and try to figure out if my dual-boot scheme actually is more secure than the Virtual Machine route. Most importantly, I'm just looking to learn more about security issues.

EDIT #1:

As pointed out in the comments, the scenario is a bit on the paranoid side for my particular use-case. But think about people who may be in corporate or government settings and are considering using a Virtual Machine to run services or applications that are considered "high risk". Are they better off using a VM or a dual-boot scenario as I outlined? An answer that effectively weighs any pros/cons to that trade-off is what I'm really looking for in an answer to this post.

EDIT #2:

This question was partially fueled by debate about whether a Virtual Machine actually protects a host OS at all. Personally, I think it does, but consider this quote from Theo de Raadt on the OpenBSD mailing list:

  x86 virtualization is about basically placing another nearly full
  kernel, full of new bugs, on top of a nasty x86 architecture which
  barely has correct page protection. Then running your operating system
  on the other side of this brand new pile of shit. You are absolutely
  deluded, if not stupid, if you think that a worldwide collection of
  software engineers who can't write operating systems or applications
  without security holes, can then turn around and suddenly write
  virtualization layers without security holes.

-http://kerneltrap.org/OpenBSD/Virtualization_Security

By quoting Theo's argument, I'm not endorsing it. I'm simply pointing out that there are multiple perspectives here, so I'm trying to find out more about the issue.

Answer first, then why: A virtual machine can be more secure.

From a practical standpoint, there exists code and malware that can infect both boot partitions, BIOS, and also hardware devices.  So, a VM has slightly more advantages in a reduced attack surface from a generic point of view - potential VM hopping code is the largest one specific to the VM.  This code is likely to be specific to the type of VM being employed such as the recent http://www.kb.cert.org/vuls/id/649219 issue.  Note it required a specific virtual machine (kvm or xen), ring, etc.

So, from the perspective of hostile code, virtualized is more secure.

Approaching from the network angle, many users of virtualization solutions have more flexibility at the network level via NAT within NAT, PAT, or other features an OS may not native support, or rolling their own enhanced security through use of the VMs.  It is fairly trivial to enhance a secure posture via using a specific VM to inspect all traffic i/o with virtualization.

So, from the perspective of network security, virtualized is more secure.

Onto guest operations.  The beauty of cloning operating systems in second...Depending on the type of virtualization solution being employed, a powered off VM can be patched transparently without action by the user.  It is trivial to take a general purpose VM, and lock it down using various hardening guides to where there is minimal functionality except from specific applications. VMs make it easier to perform extreme levels of hardening such as performing least privilege on certificate trust stores (e.g. I delete most certificates from commercial CAs except for ones I am using)  These type of activities can be much faster with a VM due to the ability to snapshot and recover from catastrophic changes.  Furthermore, a VM in entirety can easily be packaged up into a file and saved somewhere, on a USB, etc.  Also, when you think of compromises, realize that in virtualization, a compromise can be much less privileged than regularly.  In a type 1 hypervisor for example, it is the hypervisor itself that is the most privileged instance on the computer..  Increasing levels of hoops for an attacker.  It can also be used to grant developers administrative/root access, without granting said developer domain admins, or privileges on the corporate LDAP.

So, from the perspective of guest operations, virtualized is more secure.

However, I'm going to focus on the premise for a second - that virtualized and booted up native type OSes are either-or choices.  They aren't, as you can boot a virtualized OS using 3rd party solutions as if it was a dual boot option.  Software like vboot enables VHD/VMDK/VDI/Raw format booting.

As far as types of virtualization go, there are a few that are applicable to this case.  Those being Type 1 virtualization (bare metal), Type 2 virtualization (Hosted OS) and I  consider partial, operating system & paravirtualization out of scope. The leading x86 type 1 virtualization solution, VMware vsphere hypervisor, uses a microkernel approach with a minimal attack surface.  Type 2 virtualization have bigger attack surfaces since they rely on a full underlying operating system.  So, Theo's comments about full operating systems is incorrect when applied to VMware.

Here is some VMware propaganda on the topic

http://www.vmware.com/technical-resources/security/overview.html

Of course, security is most often a tradeoff between usability and security.  It is important to consider a threat situation that a user is likely to encounter, and who will deploy resources against you to attack you.  If you are a nation-state or bank you need extensive protections.  Companies, more.  Individual users of little notoriety - good enough protections.  Keep in mind that a good security solution protects you enough, but does not negatively impact usability to the extent of being a hindrance.  Overall risk management is a different topic, worthy of review elsewhere.

I didn't talk about more exotic security approaches, such as thin clients that could be used to expand upon virtualization security by further reducing attack surfaces, or TPM lockdown in conjunction with a type 1 hypervisor.


When would you support the storage of Security & Application event logs in the Cloud? Under what conditions would you be comfortable storing server log data residing in a secure facility, off-premises?

When would you consider a SaaS /hosted solution and what value add should that provide?

If the requirement is purely storage (no active analysis required), then it would seem sensible to encrypt the data using GPG/PGP or similar before sending to the offsite facility.

At that point from a security standpoint the primary issues are availability of the data to be accessed when required, so it'd be important for the provider to be able to prove that they take appropriate measures (backup, redundancy, DR/BCP, etc) to ensure that the data is available if needed.

If the idea is that the data will be processed at the 3rd party site and therefore needs to be processed in the clear, then the risks change substantially as there's a confidentiality/integrity risk as well.

So then it'd likely depend on what's in the logs, as there might be regulatory requirements for processing the information (eg, EU Data Protection Act), and the supplier would need to provide strong evidence that their security controls are at the same level or higher than the customer to ensure that the log data is appropriately managed.


Checking system integrity after clicking scam email link on Linux Earlier today, my mother opened an email thinking it was from my sister-inlaw, then clicked on the shortened link.
The link loaded a page of fairly nonsensical text. The source of the page had no explicit javascript code, but the text was formatted with a non-standard identifier. NoScript told me there were scripts on the page (but they weren't trusted, so should have been blocked).
The system is Fedora 32, upgraded to this release a few days ago. The browser is Firefox with NoScript installed.
What should I do to confirm the integrity of the system?
I'm concerned about the integrity of the Linux system, of course, but I'd also be concerned about any possible transfer of viruses or malware to Windows users my mother emails.
I've done this once before after a similar incident. I'm planning to create a live USB to scan the system for problems (which I did before) using one of the forensic Linux distros designed for this, but I'm pretty sure I did something else last time and can't remember what.
What is necessary to ensure the system's integrity?
I've read Clicked link in faked email and https://security.stackexchange.com/a/17854.
https://security.stackexchange.com/a/73660 is fairly scary, though I'm somewhat sceptical of its claims.
I also read various online guides, but had difficulty finding anything specific to Linux and reasonably current. (I think I must be searching the wrong terms because I seem to remember finding this kind of information fairly easily before.)

Most of the standard security in Linux distributions prevent the worse incidents. I assume your mother does not browse as root. And if your distro has the latest patches applied, most of the time, you'r OK.
There are some integrity checks, like chkrootkit; you must stay of course up-to-date and it will not detect everything.
Further, more extreme measures would be to create a Trusted Computing Base, like they had (have?) on AIX. Store a checksum of every file and from time-to-time check if they are still correct. Be sure to update your signatures after each package upgrade.
You could also create a reference system and compare it with that. That is overkill for a single PC, ofcourse.
And you could look into mounting partitions as read-only. I've seen /usr on a read-only, and that kind of works. Keeping up-to-date with the system is horror though.


How do I ensure that a VPS host will keep my information private? Basically, I want to use OpenVPN on a VPS to browse confidentially. However, I don't know much about VPS hosters and to me, it seems to be a hard choice because there are so many.

However, I think it's important to choose the right one because it seems to be pointless to set up your own VPN if the VPS hoster is willing to share your personal information with anybody (I assume I would have to enter my name and that kind of information when I'll sign up for the server).

How do I know if I can trust the VPS hoster to keep my personal information for itself?

Legal documents.

More specifically, the Terms & Conditions you agreed to when renting a VPS from a provider.


arp spoofing and https reading doubts in bettercap tool using the popular bettercap tool and observing responses I had two doubts that also concerns some theoretical questions:

Bettercap allows you to arp spoof entire ranges of ip-s (e.g. an entire /24 subnetwork you're in), but as far as I know do an arp spoofing attack consists in "telling" the router (the gateway) that the ip xxx.xxx.xxx.xxx correspond to your physical address (MAC) and not to the one of the target: it is possible to do so for RANGES of ip-s? Can an ARP table contain a range of ip-s instead of a single one as an entry?
Bettercap also allows you to launch a proxy you can use to "interact" with traffic when you're spoofing it; in the case of https proxy (SSL strip DISABLED by default) bettercap outputs some information about the https request header (for example user-agent ecc...), but what I know is that https is no more than http over SSL (TLS), so I was not expecting the tool to read https headers... What am I missing?

Can an ARP table contain a range of ip-s instead of a single one as an entry?

There is no need for a range. But an ARP table can have multiple IP associated with the same MAC. It is actually not uncommon for servers to have multiple IP addresses on the same physical interface.

  ... but what I know is that https is no more than http over SSL (TLS), so I was not expecting the tool to read https headers... What am I missing?

The https proxy is doing a man in the middle attack against TLS, i.e. generating certificates on the fly. Of course, unless the https client is either buggy or specifically setup to accept these certificates as trusted, the client will complain that the connection is insecure because the certificate is not trusted.


non-https winscp website The whole point of WinSCP is to provide a secure channel between a computer and a server. "Secure" means that there is a possibility of an attacker that can view or modify bytes sent both ways.
Let's assume I have keys from the server but have no WinSCP installed (or have it but want to update it). In that case I'm going to download WinSCP from winscp.net which is NOT https and thus webpages I get can be changed by an attacker that is capable of modifying bytes sent/recieved.
Download webpage provides checksums which can also be modified by an attacker.

Questions are:

How come WinSCP authors did not implement https yet on the website?
What can I do to prevent described attack?

I'm the sysadmin responsible for WinSCP.net hosting. We have moved to HTTPS gradually. As first thing we made available page with checksums (probably already at the time you wrote original post). For some time it was possible to access website on both HTTP and HTTPS and now we serve all pages over HTTPS. We still recommend to check checksum after downloading the files as the files are served from a CDN in certain regions.


Does using many XML parsers (XDocument, XMLDocument) from the public Internet increase attack surface area? I am coding an anonymous WCF service that allows others to post XML into it.

Does using different kinds of XML parsers XDocument, XMLDocument, or even 3rd party parsers increase the attack surface area? (Buffer overflows, etc).

Yes.  By definition, allowing user interaction with additional software increases the Attack surface.


How useful is Protocol Anomaly-based IDS? Protocols such as IP, TCP, UDP, ICMP, and RPC, according to Juniper networks could potentially be useful for IDS objectives of determining the direction and test conditions. In a way, protocol anomaly-based IDS is considered more practical than other methods as it uses available basic TCP header data and other attributes. Is this approach really practical in reality?

The problem IDSes face today is encryption. Once you receive a stream of encrypted information, you can only try to make sense of its behaviour.

They rely on defaults (a default port or protocol for a service), on well-known endpoints and on some pre-encryption activities (handshakes for instance).

So I would say that it is more one of the few possibilities left today, rather than being "more practical".


Is tails os susceptible to a cold boot attack? I've looked at the documentation and it mentions that upon shutdown the data residing in the ram is overwritten, however it doesn't go into any detail on how it does this.

Documentation link: https://tails.boum.org/doc/advanced_topics/cold_boot_attacks/index.en.html

Is there any foreseeable way that this could be bypassed or even recovered following a cold boot attack?

Also could something else interfere with the shutdown whilst the user is on the OS. For example some malware that's executed that would bypass the data in RAM being overwritten.

Could malware interfere with the wiping process?
If there is malware present on the system, then yes, it will be able to interfere with the memory wiping process. If a malicious process spawns many copies of itself in memory, it can prevent the processes which initiate memory wiping from executing, essentially causing the computer to hang. This is an extremely simple attack called a fork bomb, which fills up the system process table and prevents new processes from forming. Even unplugging the USB stick will not kick the computer out of this frozen state, and only holding down the power button can power it off. The malware does not need root privileges either. It can do this as a regular user. This is not a very likely threat though, because it would have to be tightly coordinated with a physical raid against you, which is unlikely. It would be much easier to prevent you from pulling out the USB stick than it would be to get malware on the system. This is not an intrinsic limitation in Linux, however, and Tails could be configured in the future to resist such denial of service attacks from non-root users quite well by using PAM. Malware which has root permissions will still be able to do practically whatever it wants, though.
Is there any way to recover wiped memory?
In theory, yes, but not because the memory can be recovered after it is wiped. On some systems, the wiping fails. This is usually not a big deal because it only saves you a few extra seconds of time. On very old computers, it can save a minute at most. If the wiping fails and your computer has DDR3 or DDR4 memory, just make sure it stays off for 5 seconds or so and the memory will fade naturally. If you have older DDR2 memory, wait a few minutes just to be sure.
If you are asking whether or not a cold boot attack after a successful erasure of memory can recover previous contents, then I would say absolutely not. Not with 21st century technology, at least.
Cold boot attacks against VRAM
There is however a different problem regarding recovering memory, and that is video memory, or VRAM. VRAM in most video cards is usually either true DDR3, or GDDR4/GDDR5. GDDR4 and GDDR5 are based on DDR3, but optimized for higher bandwidth and thus graphical tasks. Because they are based on DDR3, similar cold boot techniques against them likely apply. Tails currently cannot wipe video memory on shutdown. Cold boot attacks against video memory are possible, and they allow for reconstructing framebuffers from while the system was powered on, along with calculations the GPU was making at the time. If your system uses integrated graphics (i.e. the GPU is contained entirely in the CPU, and not a discrete graphics card), then cold boot attacks against video memory on Tails become much harder. This is mostly problematic for people with discrete GPUs. There are a few possible solutions to this, other than simply waiting the few seconds for the memory to naturally fade, but Tails has not yet implemented it. I'm actually working on a few of them in my free time and may contribute them to Tails. Other people are as well, so this is not unknown and it won't necessarily be an issue forever.
But what is the actual risk?
Honestly, I would not worry about the possibility of memory wiping failing or being defeated on Tails. Modern RAM (DDR3 and DDR4) needs to be cooled down to more than -30 degrees Celsius in order to retain any information for more than a couple of seconds. The Tails memory wiping feature is there primarily for older computers using DDR2 (or god forbid, ancient DDR) memory, where if you power off the machine and walk away, someone can walk up to it 3 minutes later and recover a significant portion of the information on it (even that is a worst case scenario. Most DDR2 memory fades in under a minute). With modern memory, they would have to be right there, freezer spray in hand, with the computer ripped open and equipment next to them, as you shut the system down for them to have any chance at recovering memory. And that would be even if you didn't wipe RAM!
As long as you have DDR3 or DDR4 memory, and you are able to shut down your system several seconds before "they" get their hands on it, then you are completely safe. Cold boot attacks are a risk if either you have 1) DDR2 or DDR memory, or 2) your computer is taken from you while it is still on, and your adversary has ample time to prepare and freeze the memory sticks while the system is still running.
All technical details aside, how should you defend yourself?
If an adversary is about to gain physical access to your computer, you must power it off, there is no way around that. If they take the computer and you are not able to get it to shut down, they will be able to do whatever they want with it. But if you manage to yank the USB stick out before that happens, then you are completely safe (from the threat of cold boot attacks).


.JPEG File upload shell via EXIF comments I came across this advisory recently and I'm a bit confused by both exploits, but specifically the file upload vulnerability.
I don't understand how to actually exploit this condition (or even why this exists as a condition).

I tried using a shell like this and inserting it into the comments section of the EXIF data, but I couldn't find any way to execute the code afterwards.

Can anyone assist? Why is it that a condition like this even exists? Is this vulnerability actually a vulnerability? Or is it just a PoC showing that you can upload things inside things (but not actually exploit them)?

What they're saying is the following:

The upload page does not enforce file extensions, and allows you to upload an image file with an extension of .aspx.
You can embed code inside a JPEG's EXIF comment tag, and it will survive the resize process (i.e. the comment tag is not stripped)
When viewing the file, the server parses the file data as a normal ASPX page. The server outputs the binary data before the EXIF tags, sees the <% and then executes the code in the EXIF comment tag, stops parsing when it finds the %>, then outputs the remainder of the binary data.

I'm not sure whether this actually works, since I haven't tested it, but it sounds legit. A similar trick works with PHP, whereby any file upload system that allows you to upload an image with extension .php will allow you to exploit the EXIF tags by injecting <?php /* code here */ ?> into them.


Combining MAC and Encryption What is the most preferred and secure way of combining both Encryption and MAC. There was a lecture on different combining strategies adopted by different protocols on a cryptography course by coursera.

 - Authenticate then encrypt SSL
   (MSG -> compute Tag(MSG)-> MSG + Tag -> Encrypt(MSG+Tag)
 - Encrypt then authenticate IPSEC
   (MSG -> encrypt(MSG) -> compute Tag(encrypted MSG) -> encrypted MSG + tag)
 - Encrypt and authenticate SSH
   (MSG -> encrypt(MSG) -> compute Tag(MSG) -> encrypted MSG + tag

The lecture concluded with IPSEC approach being the correct implement but i still lacks mathematical background and why SSL approach is not preferred.

The preferred way is to use an encryption mode which does the hard work for you; these are authenticated encryption. Usual recommendations are EAX and GCM.

If you are stuck with "classical" encryption, and an additional MAC (and you are designing your own protocol, which is a daunting task), then the theoretically "good" way is to apply the MAC on the encrypted data. This is called "encrypt-then-MAC". See this question on crypto.SE. As a summary, when you apply the MAC on the encrypted data, then whatever the MAC does cannot reveal anything on the plaintext data, and, similarly, since you verify the MAC before decrypting, then this will protect you against many chosen ciphertext attacks (when the attackers feeds you with cunningly crafted so-called "ciphertext" and observes your reactions).


Application to detect SSL certificate fingerprint differences My project is to find out how to detect HTTPS interception/mitm and create some sort of application using detection techniques. One of the ways I was thinking of is a active desktop application to listen in on the connections between client and server to check the authenticity of SSL certificates using the certificate fingerprint. Is it possible to create a desktop application in python (or any other language) to detect HTTPS interception using the sites SSL certificate fingerprinting?
Taking a look at this page https://www.grc.com/fingerprints.htm, it seems quite possible to do so.
I understand that browsers are likely to have built-in technologies to do this but this is something that is part of my research and development project.

There is a mechanism called Certificate Transparency. It is based on a system of public logs of issued certificates. Here you can red how it works.
MITM can have different reasons. For instance, some organizations (in different fields - in education, public sector, some also in business) pre-install their CA certificates on all devices of their users and issue certificates for any servers the users want to access. For any TLS connection a proxy presents a certificate that they have just generated. Browsers consider such certificates as trusted because it is issued by a CA whose certificate is pre-installed and thus considered trusted. Then proxy server sends a request to the target server. Thus on the proxy level the organization can read the requests and responses, i.e. the whole traffic.
But it will be impossible to register such certificates in the public logs. E.g. Facebook would be informed that some organization is trying to register a certificate for Facebook domain and would not allow to do that. That's why organizations that employ such MITM method don't even try to register such certificates.
Another example is the case when an attacker has broken a part of CA system (stolen the needed private key etc.) and issued a technically valid certificate for some domain. In such case the domain owner would be informed that there is an attempt to register a new certificate for the domain. The owner would check it and would report such certificate as fraud. Thus the usage of such certificate will be impossible (if you apply CT technique).


Is it possible to disable `ypcat passwd` We have an old NIS setup which, at geological speed, is being replaced by a Kerberos one. In the meantime, all the (non-root) users can simply type ypcat passwd and get the hashes of all the users' passwords. Is there an interim hack one can do to mitigate this so that it is at least not trivial to get the password hashes?

You can upgrade to NIS+, but that's sort of an epic definition of "interim hack."

No, plain old NIS does not support any protection for the password hashes it distributes.

(and before someone suggests removing or chmod'ing ypcat, you'd have to disable every programming language on the system as well.  Writing a ypcat clone is trivial, see Python for example.)


Encrypting IP addresses in a MySQL database I'd like to encrypt IP addresses in my MySQL database, with the following constraints:

Does not need to be resistant to attackers that can execute queries.
Must be resistant to attackers that have access to files on disk.
Must be able to validate an IP against the encrypted form, to check if it matches.
Checking against /24 wildcards (e.g. 10.20.30.*) would be useful too.
Any form of key or password cannot be entered on system startup, as this will be running on a server in a datacenter, and logging in via SSH every reboot is a pain I can do without.

I'm currently using separate database connections to give better privilege restrictions, with a separate table for passwords. I'm also using MySQLi and semi-automated code reviews to ensure there are no SQL injection holes.

With a non-salted (i.e. deterministic) hash mechanism, it would be easy to compute all possible IP hashes. With a salted hash, that problem is reduced, but it's still not much better if an attacker is just trying to break one IP hash. Of course, all of this prevents wildcard searches, too.

Is there a solution to this?

Update:
After some thought, I've come up with the following scheme:

Webapp has a 4096-bit RSA public key embedded in the source, I keep the private key in a TrueCrypt volume on my home machine.
When inserting entries into the logs table, the IP is padded with a random string and encrypted with the public key. This makes decrypting it impossible and makes the encryption non-deterministic.
The webapp provides an API for exporting the logs, which can only be accessed over SSL by authenticated admin users.
I write an application to use the API to browse logs my home machine, using the private key to decrypt the IP addresses.
When an IP address is banned, the IP is stored in plaintext in the bans table.

Any comments or suggestions?

Public / private key encryption is slow. It's ideal for write it & forget it, but it's not a fast process.

For the sake of speed, consider this: use a randomly generated symmetric key that is chosen when the daemon starts and possibly is rotated out every hourly, daily, weekly, or monthly (depending on your traffic and security needs). Leave that key in memory only and encrypt that symmetric key to a database table with the public key of your keypair. Then you can recover the key, but an attacker can't get it from except by dumping the processes memory. Even then, the attacker can only use the most recent key. You will likely want to use something to link the keys to the data or you'll have to brute-force your list of keys against each record. That recording could be as simple as start / stop time if your logs are timestamped, or sequence numbers, or starting encrypted entries with a key id field, etc.

Regardless of what method you use, pad your IP before encrypting it. I see that since you updated your answer this is mentioned, but it's definitely important for anybody referencing this. That will prevent indexing, but it will also prevent any "pigeonhole" issues and the same IP always having the same encrypted output.


Would IT Security professionel people notice a backdoor in Windows 7 or SBS 2011 implemented by Microsoft? I guess you have heard of Edward Snowden. Papers around the world published that the NSA invests much time, money and effort for a »full take« of the communication around the world.

Given this, it seems -- without too much knowledge of computers -- plausible, that people who invest large amounts of money in such actions could tend to force US based companies to implement a backdoor or some kind of trojan in their own software, in particular force Microsoft to implement a backdoor / trojan into Windows or SBS 2011.

You see, I'm a lawyer in Europe and I'm obliged by law to keep the secrets of my clients. I can breach the law simply by doing nothing, if action would be obviously necessary. Because my small law firm uses computers, I've got two questions:

Would such a backdoor / trojan make my computer accessible with administrator rights from outside, if the PC or server is connected to the internet, usually via router?
Would IT security professionals sooner or later become aware of such a backdoor / trojan and therefore its existence is really, really improbable?

Please take my apologies for asking such questions here. But I guess my question is being pondered by many people these days, who don't have your qualifications.

Edit:

This question has been put on hold, because the regulars here, well, guessed, that answers would not been given on knowledge, but on opinion.

But the first answer (https://security.stackexchange.com/a/41515/30160) was good enough to give me a clue. And besides that, the Washington Post published a long article which confirmed the answer given by AJ_Henderson : A backdoor in Windows made by manufacturer etc. is improbable, because it would be noticed.

So the question now is:

Is there a way to find out, whether the encryption modules in Windows 7 and the Small Business Server 2011 deliver encrypted files or messages, which can be read by Microsoft, by using a kind of implemented key?

For Windows 8 there has been a hot discussion in Germany, see here: http://investmentwatchblog.com/leaked-german-government-warns-key-entities-not-to-use-windows-8-links-the-nsa/

And to ease the fear for stackexchange, that I'd spread the rumour there were a backdoor in the encryption of MS product: clearly I do not assume that; I just would like to know, whether there are hints in one or the other direction.

Is it possible that one could avoid detection, possibly, but if it was used with any regularity, it would be detected quickly.  There would need to be a mechanism to hook into it and the amount of scrutiny that the code receives makes it pretty unlikely.  Additionally, if there was any such back door, then the software wouldn't be used on government machines and we can compare the executables the government uses to the ones that are otherwise provided to users.

Since there aren't differences like this and nothing has ever been spotted, we can be reasonably sure that there aren't backdoors as they would be both hard to find and a security issue for the government itself.  Again, there is no way to definitively prove a negative, but it isn't particularly likely that Windows has a backdoor in it.  Even if it did, using a firewall that isolates the system from the Internet would prevent it from being able to be accessed remotely unless the networking gear also had back doors.

Unless you are using encryption, Windows doesn't provide any security against local control of your hardware, so the only real question then becomes is there a backdoor in the encryption Windows provides.  This gets a little bit trickier since this kind of encryption is used less or not at all by government, so there might be something there and it would be far harder to tell since cryptography systems are far harder to look for holes.

Once again, the possible outcry from something being found probably makes it unlikely.  It would be on a whole different level if the encryption was intentionally compromised than the fact that they have been sharing access to records that they maintain.  Businesses use the encryption to protect billions of dollars worth of data and if Microsoft intentionally put a backdoor in, they would be liable if that backdoor was used to compromise business data.  You don't normally make that kind of gamble with your entire business.


Chrome: why is invalid certificate usage for resources loaded from localhost disabled? In chrome there is a flag called: allow-insecure-localhost. As far as I can tell all it does is block localhost connection over tls if the certificate is self signed.

Why is this feature turned off by default?
Does it affect regular users in any way (regular user = someone who is not developing something).
Are there any serious cases of localhost connection being used malicious that could have been prevented by having this option enabled?

Because insecure by default is bad practice.

As with many things, you have to weigh convenience against security. Your proposal would make many people a little bit less secure, by making the life of very few developers a little bit more convenient. This is really not a great deal to make.

In general, software should aim to be configured by default to be as secure as possible. Any configuration changes that could make the system less secure should be concious choices made by the user or administrator.


Finding all the subdomains and registered email addresses? Could you please explain, how to find all of the existed subdomains of a domain address and registered email addresses of these subdomains?

I found a website called snov.io but it only shows some of the email addresses, also it doesn't work for subdomains.

The second website called robtex.com, but this one is not for finding email addresses. It shows some of the subdomains but not all of them. Sometimes it requires to find subdomain of a subdomain of a domain.

I'm talking of tens of thousands (50k) email addresses, maybe more. Probably I would need some automation. I'm not an ethical hacker or pentester, I have knowledge of the C language and very limited Python experience. If I need any other website, software, OS or programming language, please refer their names. It is highly appreciated. Thanks in advance.

So, let's suppose you have a domain, e.g. stackexchange.com
Only their subdomains would know all its subdomains. In fact, it is possible that it has a wildcard (like stackexchange.com), so anything ending exists. For example: https://subdomainforquestion241763bymkde.stackexchange.com There is not a website there ("Site not found"), but the subdomain exists.
If the nameserver was misconfigured, you would be able to get a copy of the zone from them (a zone transfer). It shouldn't let you do that, though.
With no knowledge of the real data, it is possible to find some of the subdomains, for example search engines will typically discover subdomains, which you can then show on their search results. DNS resolvers can log the queries that people do, and from searching on that history, get all the subdomains that people requested through them. This is probably what robtex does.
As for the registered email addresses of these subdomains, that's a concept which doesn't exist. A domain will be registered to someone, and their email would be listed on the whois entry for the domain (assuming the tld doesn't block it, it wasn't registered through a privacy whois service, and that it wasn't now removed after GDPR changes). However, the subdomains belong to the same entity as the registered domain. There won't be an email for someone that registered it (actually, the holder of the domain might have given the subdomain to someone else, like a university giving control of the "cs" subdomain to the computer science department, but it's up to the owner of the domain to relinquish / claim back that control, and to track in any way their wish to, who is making use of it).


What's wrong with this authentication system? I'm a software developer with an interest in and basic level of knowledge about security. I've come across an authentication system that "smells bad" to me however I lack the expertise to know what if anything is wrong.

The software system involves web services for downloading and uploading data from/to a database over the public internet. All communication occurs over HTTPS and a random 32 bit integer identifies the user. Requests from unknown user ids are dropped.

Something about this seems weak but I'm not sure how weak and whether it's worth advocating change. I suppose this is equivalent to a 5 character alpha (upper/lower case) numeric password with no associated username (log62(4 billion) ~ 5) and if I look at it in those terms it seems completely anemic.

My gut instinct about what to do for authentication would have been to expose a web service operation for "logging in" that takes a username/password and passes back an authentication token (for example a cryptographic hash based on the credentials and the current time) which is then good for a certain amount of time or until the user requests a log out.

I believe my approach is more secure mainly because the credential space is dramatically larger and because the authentication token changes over time, whereas in the current system the credential space is small and the authentication token never changes. But I have no reference point... what kind of adversary would the current system fail against? What kind of adversary would my idea fail against?

The argument in support of the current system is that we are a small player with small customers in a large world so we're not expecting to be attacked, and if we are attacked we do have some level of security. My thought is that security threats are becoming more numerous and more sophisticated pretty quickly, and we do happen to be in an industry where security is a concern. I don't want to give specifics here just because I may be pointing out the existence of a poorly secured live system, but perhaps someone knowledgeable could speak to current trends in security threats?

I would appreciate any input on this topic, and if for some reason my question is inadequate please let me know so I can update it accordingly rather than marking it to be closed!

I assume that the user ID are attributed randomly and uniformly among the 232 possible 32-bit values. In that case, the best an attacker can do is to try potential user IDs (32-bit values) in any order until a proper one is found. If there are N valid user ID, then the average number of tries that the attacker will need to perform will be close 232/(N+1): if there are one thousand of users, then the attacker will need to connect about 4 million times to your server before being granted access. Once the attacker gains access, he can reuse the ID at will.

Your only defence in that case is to try to detect such brute forcing, e.g. by banning IP addresses from which come too many failed attempts. This has limitations; in particular, when many people are behind some kind of Web proxy or NAT, they may, from your point of view, share the same IP address, so you risk disabling a lost of users with a lockout strategy. Conversely, attackers can rent botnets in order to perform their one-time brute force from a lot of distinct IP addresses.

One way to look at it is indeed to consider the user ID to be some kind of password; in that view, the attacker can attack the passwords for all users simultaneously. The security level is thereby lowered when there are more users, as can be seen in the mathematical expression above: more users means more targets for the attacker, without increasing the search cost.

A login+password strategy is what most people do. This is much better: when trying to brute force a password, the attacker must select a specific user name, and will be able to break only that specific password. The "user name" is a non-secret piece of information that is specific to each user. With user names, the attacker's task is no longer a thousand times easier when there are a thousand of users. As for a "session token", well, there are several methods which are more or less equivalent (token in the URL, token as a POST parameter, token as a HTTP header -- also known as a "cookie" --, and so on); SSL itself has its own notion of session and you could reuse that.

Summary: the "secret user ID" with no user name strategy can be secure, but only if the space of possible user ID is large enough to defeat brute force, even if there are many valid user ID. This requires large user ID which must be selected randomly and uniformly. 128 bits would be enough. 64 bits would make me quite nervous. 32 bits are way too small.


Using VPN in order to continue working from home? Recently, I asked my manager is it possible for me to take my laptop home in order to work on a project that I've been involved for my company. I received an approval, however he mentioned that I'd need a VPN. Because he will be unavailable for contact during the following week because of some health issues, I can't consult with him about what is and how to setup a VPN so I can work on the software project from home.

Can someone please explain what is a VPN and is it possible for me to set it up from my home by using my company laptop?

Can someone please explain what is a VPN ...

A VPN is a virtual private network, essentially a virtual network cable which allows you to be present in some remote network with your laptop without actually being physically present at the remote location.

  ... and is it possible for me to set it up from my home by using my company laptop?

In order to securely use a VPN into your company network the endpoint inside the companies network has to be setup by the IT department and they also need to install the necessary software to access the VPN on your laptop (or provide it to you) and provide you with the login credentials and also instructions on how to use the VPN. Depending on the security policy in your company there might also be additional restrictions on what you are allowed to do with the system when working from home.

Thus, contact your IT department for further instructions and help.


Who should issue the client certificate for client certificate authentication? In case of client certificate authentication, who should issue the client certificate?
The service provider which exposes the API or the client consumer which consumes the API?
In my experience, I have seen both the approaches but I would like to know what sacred texts say.

The API consumer should generate a CSR, usually, so that there is confidence that the consumer is the only party with the corresponding private key for the certificate. The certificate issuing can then be carried out by the service provider (service-signed), the client (self-signed), or a third party trusted CA (CA-signed).

If the service provider creates the client CSR, there is an integrity issue, in that they could potentially issue the same certificate to multiple end users. This isn't always a problem - if the certificate is being used to secure a channel and further steps are taken for authentication, for example, or if it is being used for an initial connection where a client specific public key can be transferred - but isn't ideal.

Similarly, if the service requires that the client certificate be signed by a trusted third party, that isn't going to work if the service generates it - the third party verification steps would then apply to the service, rather than the actual end user, nullifying the benefits. It's not particularly uncommon for service providers to sign client certificates, however, which allows them to have a very small list of trusted root certificates (their own ones), and doesn't require that the client expose the private key to anyone. Instead, the client sends a CSR to the service, gets a certificate in response, and can use that in conjunction with the key, which has never left their control.


Access-control-allow-origin: * with a bearer token When testing a single page application, I've identified that the REST endpoints return CORS headers that allow cross-domain access:

access-control-allow-credentials: true
access-control-allow-methods: GET, POST, DELETE, PUT
access-control-allow-origin: *

These endpoints handle confidential data, so my initial reaction to this is to raise a high-risk vulnerability.

However, when I attempted to exploit the issue I found I couldn't. The site uses a bearer token in the authorisation header instead of a session cookie. While it is possible to make cross-domain requests, it isn't possible to attach the required header.

What are the risks with this model? Is this a sensible way to do things?

There are a few things that will mean exploitation is unlikely.

To start with

access-control-allow-credentials: true
access-control-allow-origin: *

is an invalid combination:

  Important note: when responding to a credentialed request,  server
  must specify a domain, and cannot use wild carding.  The above example
  would fail if the header was wildcarded as:
  Access-Control-Allow-Origin: *.  Since the Access-Control-Allow-Origin
  explicitly mentions http://foo.example, the credential-cognizant
  content is returned to the invoking web content.

Another thing is that the authorization header is not a simple header, so would require a preflight that results in an Access-Control-Allow-Headers response returning that header. The server not returning this would also prevent any CSRF attack, because the pre-flight will block it.

Unless it allows the header, it is not usually possible to add a custom header cross domain unless you attempt an exploit with Flash that used to work on certain browsers.

  What are the risks with this model? Is this a sensible way to do
  things?

As it is invalid to specify this combination of headers, indeed this is not a sensible way to do things. There may be some odd browser out there that would allow it and the site would be vulnerable (should any potential victim be using it). Allowing all origins but not credentialed requests allows the victim browser to be used as a sort of proxy in order to reach otherwise inaccessible resources. However, as the bearer header cannot be attached (without a Flash exploit) and being allowed through Access-Control-Allow-Headers, I wouldn't say this is high risk. Additionally, as the attacker does not have their victim's bearer token, any cross domain requests that would be made would be under the attacker's session rather than their victim's.

I would probably point it out as an advisory item that they should review that their CORS headers match their intention.


Implications of a 6 digit password reset token I'm designing a password reset system for my website/app right now and I'm not sure if the solution that I've reached could be considered suitably secure. The steps for resetting a password are as follows:

User visits the login page (HTTPS) and chooses 'Forgot Password'.
The user submits their email address (or username as the app allows sign-in with either).
If no account is found with the provided email/username then no email is sent (user is not warned of this to prevent user enumeration).
A 6 digit number is randomly generated as the reset token and stored in a key-value store (with the key being the token and the value being the user's ID). This store entry is configured to expire after 1 hour.
The token is sent to the account's email address.
The user then submits the token onto the same page that they provided their email on (the page contents changes to provide an input for the token).
If the token is valid then the corresponding store entry is prematurely expired and the user is prompted to provide the new password (with a 'repeat password' input to double-check).
On submission of their new password, the user's database record is updated to reflect this change and all active login sessions are invalidated.

This system doesn't use the standard method which involves generating a longer token (which comprises of a larger character set than just numerical digits); is this considered insecure?

My reasoning for this method is that our app is being developed for young people (specifically children and teens) and so this password reset system should be as simple as possible. This system means that the user doesn't have to change the page they're on (as the form to provide the reset token is automatically displayed after the email is sent) and they don't have to open any link from the email meaning that only one browser tab is ever used (and it's the same tab).

And from what I can tell, another benefit to this system is that password reset token is never exposed to any logs as it's never included in any URLs, although it's still exposed in the email however that's not something I can get around.

Can this system be considered suitably secure?

Also, would implementing a CAPTCHA service anywhere make this system more secure, or should I only ever consider adding one if we start to see too many requests being made?

The password reset scheme you describe looks OK, but you are leaving several questions unanswered at point 7, which are relevant for evaluation:

What happens, if the token the user submitted is wrong?
How many tries do you give the user before considering the reset attempt failed and block further token submissions?
If a reset attempt failed, can a user retry resetting his password again?
Is there any rate limiting (e.g. only one password reset attempt per account per day)?
Do you monitor failed attempts and react to such attacks (e.g. block an offenders IP address)?

The answers to these questions allow you to calculate the probability of an successful brute-force attack.

6 digits means a number in the range from 000000 to 999999. This gives you one million different possible tokens. Let's assume you allow up to 10 token submissions per reset attempt before you consider it failed and block further attempts. This gives an attacker a slightly better chance of success than 0.001% for a reset attempt.

That seems like a low probability, but if the attacker can automate the process and there are no limits how often a password reset can be triggered, a successful attack becomes likely fast. If an attacker makes 10000 such attempts, he has a probability of success to reset at least one account of around 10%. Ramp this up to 100000 attempts and you we are talking of a success rate of around 64% to reset at least one account. This does not look secure at all anymore.

So the real question is, can you prevent an attacker from making such a huge amount of reset requests, considering that it doesn't matter if they are done for a single account or multiple accounts.

You also talked about simplicity of the process. If you do not want to use a complex character set for the token, that's totally fine. Length is much more important anyway. If you want to make the token stronger, I would recommend adding a few extra digits. But in the ends, it comes down to protect against brute-force attempts.


What security considerations should be made when choosing a universal authenticator app? The USPTO has two-step authentication: recommended applications comprise:

Google Authenticator
Microsoft Authenticator
Oracle Authenticator

Assume that I use my Gmail address as the USPTO username.  What considerations / questions should I ask myself when choosing an authenticator?

I don't think there is really anything we as a group can do to contrast those in terms of security of the app out-of-hand, since they're at least all reputable organizations(though hey, maybe someone here has actually tested them, who knows!), so all other things being equal there's only really one question I can think of:

Which auth app will incur the smallest expansion of my digital footprint?

i.e. "Which app's use least results in my data being sent to new locations/entities?"

In the case of the USPTO, with a gmail account as username, we can assume that 2 entities by necessity know your gmail address(USPTO+Google), and 1 entity definitely knows you have a USPTO account, with another (Google) being extremely likely to learn it as soon as you get an account creation verification email.

So in this case, the minimal number of entities who know about you is 2.
This is before we choose an authenticator app.

Without recommending a tool, I will say that it seems clear to me which choice would not involve informing an additional entity about one or more pieces of information (i.e. that you have a USPTO account and/or your gmail address)...


Why does Bouncy Castle have a separate download for the IDEA algorithm? I'm looking at downloading the C# binary for Bouncy Castle and see two downloads with source code.  One has the IDEA algorithm, the others presumably not.

http://www.bouncycastle.org/csharp/

Why make separate distributions?

In some countries, IDEA is patented and redistributing an implementation of it requires it to be licensed. IDEA was a default cipher used in early versions of PGP. For backward compatibility, it is included in OpenPGP which Bouncy Castle implements.

For your case (a new application), get the distribution without it and use AES instead.


Is AES encryption vulnerable? I was reading weaknesses in AES encryption. Unfortunately, I have a website that uses AES: Its database is almost entirely AES encrypted.

Is there a real threat? Would it be worth to refactor the web site's implementation?

Technically "cracked" only means that a method was found that reduces guessing from random guesses to slightly less than random guesses.  The flaw that was discovered is one such minor crack.  A perfect crypto-system would require making 2^127th guesses on average to crack a 128 bit key.  The attack against AES allows it to be done on average in 2^125.1th guesses.  Sure, it is over 1/4 faster, but 1/4 of now to the heat death of the universe is still far longer than we need to worry about.

And if you are truly worried, up the bit depth of your key and it's even more unlikely to be cracked.  This is basically what the approach is for when 3DES is still used.  There are significant compromises against DES, but upping the key length and using 3 DES operations back to back results in preserving a relatively secure algorithm out of something that has actual significant weaknesses to cryptanalysis.


What is Logjam and how do I prevent it? I heard there is a "new" TLS vulnerability named Logjam, what does it do and how do I prevent it?

TL;DR

SSL/TLS client and server agree to use some weak crypto. Well, turns out that weak crypto is weak.

In Detail

When an SSL/TLS protocol is performed, the client sends a list of supported cipher suites, and the server chooses one. At the end of the initial handshake, some Finished messages are exchanged, and encrypted/protected with the newly negotiated crypto algorithms, and the contents of these messages is a hash of all the preceding messages.

The idea is that an active attacker(a MitM attack) could try to manipulate the list of cipher suites sent by the client to remove all "strong" crypto suites, keeping only the weakest that both client and server support. However, this would break the Finished messages. Thus, these messages are meant(among other roles) to detect such downgrade attacks.

In theory, it's fine; unless the client and server both support a cipher suite that is so weak that the MitM attacker can break it right away, unravel the whole crypto layer, and fix a Finished message in real-time. Which is what happens here.

In Even More Detail

When using the "DHE" cipher suites(as in "Diffie-Hellman Ephemeral"), the server sends the "DH parameters"(modulus and generator) with which client and server will perform a Diffie-Hellman key exchange. Furthermore, the server signs that message with its private key(usually an RSA key, since everybody uses RSA in practice). The client verifies that signature(the public key is the one in the server certificate), then proceeds to use the DH parameter to complete the key exchange.

It so happens that in the previous century, there were some rather strict U.S. export regulations on crypto, and this prompted "export cipher suites", i.e. weak crypto that was compatible with these regulations. Many SSL servers still support these "export cipher suites". In particular, some cipher suites that use DHE and mandate a DH modulus of no more than 512-bits. Moreover, most SSLs in the servers use the same modulus, because using the one provided with the SSL library is easier than generating your own. Reusing the same modulus as everybody else is not a big issue; DH tolerates that just fine. However, it means that if an attacker invests a lot of computations in breaking one DH instance that uses a given modulus p, the same attacker can reuse almost all of the work for breaking other instances that use the same modulus p.

So the attack runs like this:

Attacker is in the MitM position; where he can modify data flows in real-time,
Attacker alters the list of cipher suites sent by the client to specify the use of an export DHE cipher suite,
The server complies and sends a 512-bit modulus p,
The client is still persuaded that it is doing a non-export DHE, but a DH modulus is a DH modulus, so the client accepts the weak/export modulus from the server just fine,
Attacker uses his pre-computations on that value p to break the DH in real-time and fix the Finished messages.

The Logjam article authors call this a "protocol flaw" because the ServerKeyExchange message that contains the export DH parameters is not tagged as "for export", and thus is indistinguishable(save for the modulus length) from a ServerKeyExchange message that contains non-export DH parameters. However, I would say that the real flaw is not there; the real problem is that the client and server accept to use a 512-bit DH modulus even though they both know that it is weak.

What should you do ?

Well, the same thing as always: install patches from your software vendors. As a matter of fact, this should go without saying.

On the client side, Microsoft has already patched Internet Explorer to refuse to use a too small modulus. A fix for Firefox in the form of a plugin by Mozilla is available here now. It is expected that other browser vendors(Opera, Chrome...) will soon follow.

On the server side, you can explicitly disable support for "export" cipher suites, and generate your own DH parameters. See that page for details. Note that IIS is kind of immune to all of this because apparently it never supported DHE cipher suites with anything else than a DSS server certificate, and nobody uses DSS server certificates.

Note that ECDHE cipher suites, in which "EC" meaning "elliptic curve", are not at risk here, because:

There are no "export" ECDHE cipher suites (ECDHE cipher suites were defined after the US export regulations were considerably lifted).
Clients in general support only a few specific curves (usually only two of them, P-256 and P-384) and neither is weak enough to be broken (not now, not in the foreseeable future either).

And what about the NSA ?

The Logjam researchers include some talk about how some "attackers with nation-state resources" could break through 1024-bit DH. This is quite a stretch. In my experience, nation-states indeed have a lot of resources and are good at spending it, but that's not the same thing as succeeding at breaking hard crypto.

Nevertheless, if you fear that 1024-bit DH is "too weak",go for 2048-bit(this is the recommended one anyway), or ECDHE.

Or simply accept that people with overwhelming resources really have overwhelming resources and won't be defeated by a simple modulus size. Those who can spend billions of dollars for cracking machines can also bribe your kids with a few hundreds of dollars to go through your computer files and your wallet.


Tell and sell a (web app) vulnerability legally If someone discover an unknown vulnerability for a given online service or website, is there a decent way to sell it directly to the concerned entity.

There is no guaranteed safe solution for dealing with found vulnerabilities. There have been recent cases where researchers have been threatened with prosecution simply for reporting a simple URL vulnerability to a bank. The bank accused them of hacking, because it was a violation of their TOS to attempt to manipulate their URL.

They are under no obligation to deal with you. They did not contract with you to search for vulnerabilities. So don't expect much in the way of cooperation.

Consider using a third party remailer to contact them. You could anonymously offer them the vulnerability, along with a code word, then approach them later after they agree not to prosecute.

You could also approach them through one of their vendors. If you see that their site is hosted on IIS, you could contact Microsoft's security team instead of the organization.


Why on earth would anyone use the 'top secret' option of IPv4? So, I was reading RFC 791, and got to the bit about options (here). Everything seemed to be decent and sensible, until I got to the 'levels of security' part.

Now, I can understand how, internally, the DoD might want their packets to take special routes, but at the same time, wouldn't using an option like that simply alert people that, hey, this is the traffic most worth trying to decrypt/trace (assuming, of course, that someone sending something classified would also have the basic sense to encrypt the transmission)?

Who would use that capability of IP? Why?
When would it be helpful to anyone but an attacker sifting through a lot of information?

...Additionally...

If I wrote a networked program which labeled all of its packets 'secret', for example, would they be treated any differently when routed through the internet than packets labeled simply 'unclassified' or 'confidential'?

The point of classification flags is that it tells routers what they are allowed to do with it.  You wouldn't see classification flags on the open internet as they are handled by private government networks.  What the flags do perform however is allow routers within the government network to determine if a packet should be allowed to bridge to a public or less secure network without having to understand what is within the packet.

Be sure to check out Falcon Momot's answer as well.  It has some excellent additional depth.


What's eating my entropy? Or what does entropy_avail really show? Below are graphs with the value of /proc/sys/kernel/random/entropy_avail on a Raspberry Pi. This answer which might not be correct describes it as:

   /proc/sys/kernel/random/entropy_avail simply gives you the number of bits that can currently be read from /dev/random. Attempts to read more than that will block until more entropy becomes available.

The pattern always comes to the same "stable" saw pattern with ~130 bit decrease every single minute. If entropy grows too much, something is "eating" it to return to the 700-800 range. If I reboot the device, the entropy is still being eaten each minute, but in a smaller chunks thus enabling it to grow again to 700-800 range.

How shall I interpret the graphs? What is happening?

My feeling is that if there was just a process using a random number generator, the entropy_avail once thrown out of balance (by using the device hardware) should either grow infinitely or decrease to the level of 200, when /dev/random would stop supplying the values.

Also if any of the monitoring methods (see checks below) influenced the entropy, it should rather decrease entropy every second, rather than let it grow and drop suddenly at one minute intervals.

(if I leave the machine idle, the stable "saw" pattern continues for days, I took the screenshots in a shorter period of time)

The graphs

The machine is idle for a long time:

At around 19:14:45 another machine accessed apt-cacher on the Pi - entropy grew (I guess from network usage). After that at 19:16:30 the drop to "usual levels" was larger than usual (it is also repeatable - if entropy_avail grows too large, it drops faster):

I reboot the machine, the entropy grows until it reaches the "usual" level:

Once again it reaches an idle state:

After another reboot the point in time of the entropy decrease changes, but it still occurs every single minute:

Checks

I stopped netdata (monitoring program) and checked with watch -n1 cat /proc/sys/kernel/random/entropy_avail. The value of entropy_avail grows to ~800 and drops to ~680 at regular one minute intervals.
Per advice "trace all processes for access to /dev/random and /dev/urandom" I checked with inotifywait (idea from an answer to a similar question) on Debian VM and there is no access to either /dev/random or /dev/urandom at the moment entropy_avail drops (of course checking manually logs the event).
I used the entropy-watcher to check the entropy as advised against using watch. The results are still consistent with a steady increase and a sharp drop every single minute:

833 (-62)
836 (+3)
838 (+2)
840 (+2)
842 (+2)
844 (+2)
846 (+2)
848 (+2)
850 (+2)
852 (+2)
854 (+2)
856 (+2)
858 (+2)
860 (+2)
862 (+2)
864 (+2)
866 (+2)
868 (+2)
871 (+3)
873 (+2)
811 (-62)

Two questions on Unix StackExchange describing the same phenomenon (found later):

What keeps draining entropy?
What program(s) is(are) lowering my entropy pool level?

First, the claim that "/proc/sys/kernel/random/entropy_avail simply gives you the number of bits that can currently be read from /dev/random" is false.

The entropy_avail field reads the input_pool.entropy_count, the "output" pool refers to the pool used for urandom (non-blocking pool) and random (blocking pool).

As mentioned in this answer, spawning new processes consumes entropy for things like ASLR. The watch program spawns a new process for every invocation, perhaps the monitoring tool does the same (possibly via one of the other monitoring sources that have to invoke an external program to obtain the status?).

For monitoring the entropy pool without draining it you can try the entropy-watcher program (see linked answer).

Watching the entropy-watcher numbers closely it seems that you lose about 64 bits of entropy at intervals. Based on the analysis in the other answer, this seems to be the result of moving entropy to an "output pool" to avoid wasting it. This is observed on Linux v4.6, future implementations may be different.

Based on the source code (drivers/char/random.c in v4.6), I can see that reading the output pools (/dev/{u,}random or get_random_bytes()) invokes extract_entropy{,_user} which calls xfer_secondary_pool and account. The blocking pool has the property limit set (r->limit == 1) which affects both functions:

For account() it will return no data from the blocking pool if its entropy is too low. For the non-blocking output pool, the remaining entropy will be consumed but data is still returned.
xfer_secondary_pool() ensures that enough entropy is available in the output pool. If the blocking output pool has insufficient entropy, it will take some from the input pool (when possible).
xfer_secondary_pool() for the non-blocking output pool behaves specially according to the /proc/sys/kernel/random/urandom_min_reseed_secs parameter. If this value is non-zero, entropy is only taken from the input pool if at least urandom_min_reseed_secs seconds have elapsed since the last transfer. By default this value is set to 60 seconds.

The last point finally explains why you see an entropy drain in the input pool every 60 seconds. If some consumer requests random bytes from the non-blocking output pool (TCP sequence numbers, ASLR, /dev/urandom, getrandom(), ...), then 128 bits will be consumed from the input pool to reseed the non-blocking output pool.


Should I inform a random person on the internet that their data may be compromised? I've found a data leak in a fairly well known password manager. I'm currently in talks with the developers to get this corrected. However, in proving that this is a bug I stumbled on a users data which is freely accessible to anyone. All it requires is a simple google search and you can view the data.

Given that I have seen many people in the US (where I currently reside) be prosecuted for simply pointing out security flaws, should I email this random person and tell them that their data is out there for the world to see?

You did the right thing in informing the developers that their product is flawed.

Now, whether to inform the user whose passwords you accidentally discovered, that's up to your ethics. It seems like an important breach of security, so I probably would do this.

If you choose to report the breach to the user, you can do it anonymously. You could send a message from a throwaway email account as I think there's very little chance that the user would try to prosecute you. (You probably had a greater risk of getting sued by the developers.) If you feel paranoid, and would prefer to go fully anonymous, just run a live Tails CD and from there send an anonymous email via Sendy.


Export ciphers prevalance I would like to clarify the consequences of not supporting export ciphers.

When I run a qualys ssl test on ebay.com, I notice that the following cipher suites are supported.

TLS_RSA_WITH_RC4_128_MD5 (0x4)
TLS_RSA_WITH_RC4_128_SHA (0x5)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)

Interestingly, they prefer to mitigate BEAST by prioritizing RC4 ciphers, however they have not included any export ciphers. In fact, I have rarely see any domain supports export ciphers these days.

Is it true to say the following:

Ebay.com will not be specifically inaccessible in any country, especially groups D or E as defined in Supplement No. 1 to Part 740 due to unsupported export ciphers on the server side. For e.g. Any country listed under Group E can still access Ebay.com.

However, it does mean that ebay.com may be potentially inaccessible from extremely old browser versions (e.g. Netscape Navigator), if they do not support any of the 5 ciphers listed above.

The "export ciphers" were defined in SSL 3.0 and TLS 1.0, but they implied that symmetric encryption relied on a 40-bit key only; this is highly breakable in practice. Notably, the reduction was direct (the key has length 40 bits exactly), instead of a reduction trick with a 40-bit key space (as can be done in RC2), so precomputed tables can be used to break this encryption instantly. Using an "export cipher suite" is not much better than not using SSL at all, at least against passive eavesdropping (for active attacks, we could argue).

This is reason enough not to use these cipher suites at all. Indeed TLS 1.1 and TLS 1.2 declare them as unsupported. Indeed, in annex A.5 of TLS 1.1, we find this text:

  When SSLv3 and TLS 1.0 were designed, the United States restricted
     the export of cryptographic software containing certain strong
     encryption algorithms.  A series of cipher suites were designed to
     operate at reduced key lengths in order to comply with those
     regulations.  Due to advances in computer performance, these
     algorithms are now unacceptably weak, and export restrictions have
     since been loosened.  TLS 1.1 implementations MUST NOT negotiate
     these cipher suites in TLS 1.1 mode.  However, for backward
     compatibility they may be offered in the ClientHello for use with TLS
     1.0 or SSLv3-only servers.  TLS 1.1 clients MUST check that the
     server did not choose one of these cipher suites during the
     handshake.  These ciphersuites are listed below for informational
     purposes and to reserve the numbers.

Note also that the US export regulations have been lightened circa 2000, so these cipher suites don't make much sense nowadays.

If there is no cipher suite which both client and server support, then they won't be able to "do SSL".

I quite doubt, though, that there are people on the Internet with browsers who can only use "export" cipher suites, and these people are still able to connect to the Internet and try to use it. Even Netscape Navigator supported non-export cipher suites, and it was legally exportable (version 4.8 was from 2002; and versions prior to 4.8 crash on UTF-8 text, so they cannot be considered as "usable" at all...).

Also, note that export regulations are just that: export regulations. These means that it might be unlawful for a US-based company to send a product with strong encryption across the border, into, say, North Korea. This does not mean that it never happened. Only that if there is a browser with strong SSL encryption right now in North Korea, then, at some point, chances are that one export regulation of one country was transgressed. Or even maybe not: a given software may hop from country to country, in each case with full conformance with local export and import rules, and then reach North Korea, even if a direct USA-to-North Korea export would have been frowned upon by US authorities. There is no guarantee that export regulations are transitive (in the mathematical sense).

In fact, it can be surmised that if someone from North Korea can access ebay.com at all (meaning in practice that this guy is Kim Jong-Un himself), then he most probably uses a browser which can do strong SSL encryption.

Summary: consequences of not supporting "export" cipher suites are, in practice, nil.


What are the likely effects of increased government spending on "Cyber Weapons" on the software industry? From the conference scene and news this year it seems probable that there's an increased amount of spending from governmental agencies on what it getting termed "Cyber Weapons".  A key component of these weapons are 0-day vulnerabilities which can be used to get access to systems which may not otherwise present an exploitable flaw.

This in turn has created a trade and market value (which can apparently be quite high) in 0-day sales to governments, with a number of companies springing up to facilitate sales.

Whilst I've seen quite a bit of conversation on the effects of this on security in general, I've not seen too much on the effects on the software development industry, and I'd be interested to here where people think this trend will have an impact.

So far thoughts that had occurred to me

There's now an incentive for developers to either deliberately introduce flaws into software (or to fail to patch them) so that they can sell knowledge of this flaw on to 3rd parties.
Software companies may come under pressure not to patch issues which are being actively used by the military in "Cyber Space" operations.
Software vendors may find it harder to sell to governments other than their home nation as the assumption becomes that they will put back doors or leave exploitable flaws unpatched at the behest of government agencies.

I think the most likely outcome would be delayed patches to fixes at the behest of friendly governments. Consider:

Deliberately introducing flaws is not an easy thing. Anyone from the organization could look at the code and see the flaw - so the details might leak.
Continuing point one, if the flaw causes an issue for customers, that would be bad rep for the company.
Protectionism exists already in other industries.
I assume governments do a cursory check of what they install, just in case.
Governments probably use air gaps for anything important. That would reduce the likelihood of the exploit being exploitable if the air gap is properly maintained.

All of this boils down to one thing: the least worst course for a software company that wishes to help a government is to let them find the flaw, and then not patch it for an agreed window especially if it doesn't cause any issues.


Why snort uses "alert" rule only? Among community rules and registered rules, all are "alert" type rules only. Since there are more rule types like log,pass,activate,dynamic,drop,sdrop available , snort official rule sets use only alert type. Why other type of rules are not included in the snort official rule sets ?

"Alert" type is the default one that can be used if you want to generate that kind of event when the signature matches.
Based on your need, and to customize the use of the application, you might want to not be alerted all the time, for example.

You might want to set "log" type for some rules that might be too noisy, so that you can analyze them once a day, with some analytic methodology.


Could this piece of code be harmful ? I just wrote these 2 functions in C#.net and it can get any user's system IP and MAC address. Isn't this harmful since I got help from microsoft documentation. Could these lead to potential damage or could be labeled as illegal ?

public string GetLocalIPAddress()
    {
        IPHostEntry host;
        string localIP = "";
        host = Dns.GetHostEntry(Dns.GetHostName());
        foreach (IPAddress ip in host.AddressList)
        {
            if (ip.AddressFamily == AddressFamily.InterNetwork)
            {
                localIP = ip.ToString();
                break;
            }
        }
        return localIP;
    }

    private string GetMacAddress()
    {
        string macAddresses = string.Empty;

        foreach (NetworkInterface nic in NetworkInterface.GetAllNetworkInterfaces())
        {
            if (nic.OperationalStatus == OperationalStatus.Up)
            {
                macAddresses += nic.GetPhysicalAddress().ToString();
                break;
            }
        }

        return macAddresses;
    }

An IP number is very comparable to a phone number. By default this is a public information available in any public directory and is necessary to establish a communication.

However there are tons of way to exploit even public information in illegal ways.

So the real determinant here is not the fact that you are collecting the local IP and MAC address, but the purpose you have behind it.


What are the security risks of using public address schemes for the DHCP of your VPN'd Users? At the company I work for we recently purchased a network scanning tool to help with asset inventory and overall PC network management. My supervisor, while looking at the different IP address ranges for the various offices, noticed the range 222.222.222.x on about 30 machine's. We called the IT supervisor at the site and was told that the address range is set up as the DCHP range for VPN users. This seems like a huge security risk to me.

What are the risks involved with using this range of addresses?

The address's are used publicly in China, what are the risks associated with this?

Does this open us up as an easier target for attack?

It does not add any major risk.

The fact that the range is public (versus private like 10.0.0.0/8) doesn't change much as attempts to contact it from the outside (from an attacker for example) would still end up going to the legitimate owner of the IP block.

Furthermore a well-configured network should have a firewall that would block access to those VPN clients from the outside if the packets manage to reach the network for some reason.

The only issue could be if the legitimate owner of the IP block is malicious and sets up malicious services on those IPs, and somehow your users try to access your company's VPN range but instead end up accessing the real IPs which are malicious (if for example their VPN goes down).

However it is very bad practice, as now those VPN clients can't contact the "real" 222.222.222.0/24 subnet, and depending on how the network is designed it could be that either the entire company's network can't reach 222.222.222.0/24, or that some computers in the company would reach the real 222.x.x.x instead of reaching the VPN clients.

Either get the company to acquire/rent out more IPv4 blocks for their VPN clients, or use private addresses (and NAT for v4) and move to IPv6 for everything else.


Any good free SSL proxy on windows? I'm looking for SSL proxy capable of dumping requests.

I want to test custom browser against SSL-MITM attacks.

I'm able to re-route all traffic ongoing from browser to machine with proxy.

Basically proxy should:

initiate SSL connection with legitimate website
issue self-signed certificate
pass data received from legitimate website to browser
capture requests issued by browser


What can websites learn about me when I disable cookies? I run Google Chrome with Ghostery, Privacy Badger, AdBlock and cookies disabled. If, theoretically, Ghostery is blocking all the trackers, AdBlock blocks ads, and I don't accept cookies, what can the sites I visit learn about me? Can they still track my IPs, my location,...

A great deal amount you can be learned, and correlated without using cookies or your IP address.

Cookies serve the purpose of tracking specifically you. However other methods of tracking have been found to be 99.1% accurate  in tracking you by using other unique characteristics of your browser/session/machine. Some of the unique identifiers are your user-agent, your screen size/density, your java/flash version etc. Read the white paper here (or at least the abstract for an over view of their findings).

You can see the unique characteristics that can be pulled to represent you without the need of a cookie on the main site of that white paper here.


User authentication: In HTTP Server vs. in Web Application Management decided to switch the authentication-backend from LDAP to Kerberos as LDAP is deemed "obsolete and insecure". Also they want to switch from Apache to nginx for "performance and reliability". Ultimate goal is to enable SPNEGO for single-sign-on within the domain.
Previously, we happily used Apache's mod_authnz_ldap. nginx however does not even seem to support authentication modules by default. I never worked with nginx before, so I might have missed something.
Asking local experts about this, I received the response "The HTTP server should not do the user authentication – that is the web application's responsibility." So now I am stuck with a bunch of services which were never designed to do user authentication themselves.
This made me think: What are the advantages of not having authentication in the HTTP server?
Performance might be one factor – but at what cost? Usually my stance is "never do it yourself". Especially when it comes to cryptography or – in this case – authentication schemes. Using the HTTP server's features, all authentication is done in one place. User information is simply forwarded to the server-side application. Without such a feature in the HTTP server, I would need to implement the authentication scheme in each and every application over and over again. As of today, I failed to find ready-to-use modules for our ancient php-based applications. There is a kerberos module for flask. It was last updated six years ago and does not play nice with me at all. I have not even looked into the other services yet. It seems to be a massive increase in the maintenance required. I suppose, there are upsides to this approach, but I fail to see the. What are the advantages?

The advantage of authenticating at the application is having this done independently of the OS and web server, you are not mixing your implementation layers (i.e. the application's authentication and access controls don't rely on information passed on from another piece of software).
Generally the advice of not authenticating at the web server level is a good one, since there's limited control of granularity and it affects the concept of server side sessions. But it's also a one-sided argument and there could be good reasons to use it. Context is critical.
Personally I find, at face value with the information you shared, I find it a poor decision to essentially break a functional setup and shoehorn a type of solution into multiple applications that may not be running on the most up to date platforms or receiving sufficient amount of maintenance effort. It's both fixing what isn't broken and multiplying effort. If/once it's done you'd probably be in a better position for the future, but getting there will become a problem.


Can bankers' rounding be exploited to maliciously increase balances? Everyone knows about the sure thing retirement strategy that is the Superman 3 exploit, but is there a way to exploit bankers' rounding to grab some of the less than half pennies "floating around out there"?

Specifically, assuming that the internal accounting cannot be tampered with like in Office Space, can transactions be formed within certain constraints to recover the rounded-off portions?

In fact it was exploited (on a low scale) in Germany before the Euro cash was introduced. The scheme worked like this:

Create two accounts, one already in Euros, the other in Deutsche Mark.

Transfer 0,01 DM to the Euro account, it is rounded up to 0,01 Euro

Transfer 0,01 Euro to the DM account, it is rounded up to 0,02 DM

A school class made some press headlines earning a few hundered Euros this way.

Of course, a transaction fee by the bank immediately destroys such schemes.


How do I protect myself against the attacks in this php script? Due to a vulnerability in how PHP was installed (Shared VPS with PHP installed as an Apache module instead of CGI) and hence how OSCommerce was configured (with security of 777 on certain directories), I found a number of PHP scripts on a friends webserver which had been loaded by hackers. The actual code was hidden using several layers of encryption. They had a PHP file with a huge string assigned to a variable $str. Then they used the following line to decrypt the string into malicious PHP code and attempted to run it by visiting the page.  The statement used to decrypt the encoded string was eval(gzinflate(str_rot13(base64_decode($str))));

They can't run the code from this directory now because there's a .htaccess file preventing the execution of scripts from that folder which was put in place since we discovered the system had been compromised, this is a temporary fix but probably not the best one.

I ran this script on a linux vm running on my Mac while altering the statement above to echo(gzinflate(str_rot13(base64_decode($str)))); so that I could see the source code.  I've put it up on pastebin for the interest of people here.

Pastebin of source for hacked page

From what I can gather, this seems to be a pretty sophisticated script which tries all sorts of tricks to gain access to your server but I'm not familiar enough with PHP to identify all the vulnerabilities this might attempt to exploit.  What checks should I perform on my system if I can assume they managed to run this at some point in the past?

What was uploaded is a popular shell script - a common post exploitation method.
The one you got seems like it is of the C99 variety.

In short, its a script that gives the attacker a control panel to your server, so that he can execute commands, download and install malicious things, find files with passwords, further infect the system, launch other attacks and other.

OsCommerce recently had a very severe RFI vulnerability allowing exactly these things to be uploaded, and that is probably how you got it - there are automated tools looking for the vulnerability and exploiting it.

Your system is no longer safe: The attacker might have downloaded rootkits or he may have created a second backdoor on your machine so deleteting the file won't suffice.

The ideal solution is to perform a full wipe and restore anything you want from backups - that is, if you trust your backups are clean.

If you can't do that, you have to do a full investigation of the server, but you can never be sure.

As for you question: There's no point enumerating the different attacks the script contains, as it provides basically a command line to your server and the attacker could run any command he wants or download any tools he needs. It just has some preconfigured functionality for his convenience.


Why does Firefox split HTTPS request? I am using Firefox browser version 28.0. To access https://www.yahoo.com, I put a proxy with a self-signed certificate in between and my client PC can access the HTTPS site. I then sniffed traffic in my client PC and observed a strange thing;

Each HTTPS request sent from Firefox is split into two TCP segments. One is only one character long ("G"), the other includes the rest ("ET / HTTP 1.1 ...")

Why does Firefox behave like this?

This is the "1/n-1 split" technique which has been deployed in SSL libraries as a workaround for the BEAST attack.

The BEAST attack is the application to a Web context of a chosen plaintext attack. The attack works when:

The encryption uses a block cipher in CBC mode.
The attacker can choose the data that gets encrypted (in a Web context, this is done with Javascript).
Right before sending his bytes to encrypt, the attacker knows the IV that will be used with CBC mode.

In SSL 3.0 and TLS 1.0, the IV for a record is the last encrypted block from the previous record, so the attacker can see it by spying on the line (the attack setup supposes that the attacker can eavesdrop on the line and send information to some evil Javascript planted in the victim's browser -- this is realistic in the "WiFi in a restaurant" scenario, with an attacker-controlled access point).

The "1/n-1 split" prevents the attack because the frame with 1 byte includes a MAC value, that the attacker cannot predict, and that gets encrypted as well. The subtlety is a question of timing: when the attacker gets to choose the data which will be encrypted, neither the "1" nor the "n-1" records have been emittted; only when the attacker has pushed his n bytes will the two records be computed and sent. The net effect is that the attacker will not be able to know the IV for the n-1 record before sending his n bytes to encrypt. The attacker will still be able to predict the IV for the "1" record, but one byte is not enough for the attacker to pull off the BEAST attack.

Theoretically, a "0/n split" would be possible (a first frame with no data at all, then the actual frame) and would be even better (in an academic way), but, though it is supported as far as the standard is concerned, a number of deployed implementations choke on empty records, so the "1/n-1 split" is deemed more practical.

The BEAST attack also requires that the attacker gets a lot of control on the bytes he needs to send, e.g. he must not be restricted to only ASCII characters; the prototype attack relied on a pair of extra vulnerabilitiies which have been fixed since, so even without the 1/n-1 split, the attack would no longer work. But SSL library designers are cautious and don't want to see the SSL security being jeopardized by a vulnerability in another component of the application.

TLS 1.1 and later versions are immune because their record header includes a record-specific IV.


What is the the meaning of "out-of-band" in "out-of-band key exchange"? When we say "out-of-band exchange of symmetric keys", what does "out-of-band" mean?

From Wikipedia:

  Out-of-band is activity outside a defined telecommunications frequency band, or, metaphorically, outside some other kind of activity.

It just means through another means of communication than the one you use to exchange the ciphertexts.

If you are sending the encrypted messages over the internet, calling up the other person on the phone and reading the key to them would be transmitting it "out of band". So would meeting the person IRL and giving them the key or sending it in an ordinary letter.

The point is that you have on (relatively) secure means of communication (where you don't think there is any eavesdropper). You can use this channel to transmit a symmetric key, that you can later use to communicate securely on an insecure channel (where there might be eavesdroppers).


Why isn't cloud (AWS, Azure, GCP) metadata served over HTTPS? Why can any application or user on your server type an insecure URL like these to get server information about that instance?

http://instance-data.us-east-1.compute.internal/latest/meta-data/
http://metadata.google.internal/computeMetadata/v1/
http://169.254.169.254/metadata/instance?api-version=2019-04-30

Doesn't it allow any attacker in the middle the capability to intercept potentially crucial and high-value data?

The first point to observe is that if you click one of the above addresses you shouldn't be able to open it.  They all point (clearly in the case of Azure) to a link-local IP address.  These are reserved addresses in the space 169.254.0.0/16 that are not forwarded by routers, and crucially are only accessible from a given instance.

The second point to note is the data that the URL contains.  User data can be stored via these APIs, but it shouldn't be as it's not protected by any cryptographic methods.  Identity and Access Management (IAM) data can also be stored, and that is one of their strengths.  But wait!  Doesn't that mean any user with access can see data that allows them to do things they really shouldn't?  Well...yes.  However, that data is rotated on a relatively short time frame (~1 hour by default) meaning any reveal is limited, and the data can be rotated on demand.

As for the question as to why the URL is unencrypted?  Yes, there is still network communication taking place, even if it was hosted on a local network interface.  However, since it's only accessible from your instance, and any attacker looking to sniff network packets requires root access (for any reasonably normal scenario at least), it can't be intercepted by anybody except root - and if a user has root access to your machine, then it doesn't matter what data is stored in the credentials!  Trying to determine exactly how the metadata server is called is tricky, but it's likely that the data is simply stored by the physical host of the virtual machine, and authentication is done by the physical host simply returning information corresponding to the virtual machine that the request comes from.  In that sense, the requests do leave your instance, but they never cross a network to be intercepted, unless a physical host has been compromised - at which point, again, your system has been compromised anyway.  AWS or Azure don't seem to detail anything specific, but Google seem to back up this logical assumption:

  When you make a request to get information from the metadata server, your request and the subsequent metadata response never leaves the physical host running the virtual machine instance.

That doesn't quite explain it all however, and the real answer is speed.  Any additional handshake takes time, and if there is no practical need to having the data encrypted then why do it?  Securing it here offers no additional protection, and only serves to delay the many requests to the API.

Why then is it not a big worry that IAM credentials can be gained over these URLs in an insecure model?  The answer lies in two principles of least privilege and defence in depth.  First, the IAM roles assigned to the instances assigned should offer very limited capability, and ideally none to write or create new data or interfaces.  Second, your application can be built to prevent requests to metadata - if somehow an attacker manages it, other defence mechanisms can be used such as not allowing requests from servers other than localhost or having alarms set when requests are made with credentials outside of a certain time period.

As a useful case for why you would want to utilise a metadata server:
To be able to read or write to a database ordinarily requires credentials to be stored somewhere on the server, normally in a fixed file or memory out of public view.  However, IAM roles can be assigned to an instance to allow an application to fetch these credentials 'on the fly' without storing them, as well as being able to read them after the credentials are rotated on a frequent basis, thus automating what can otherwise be quite a tedious admin task.