Terminology - entry point, data source, sink In the context of application security, I often heard the terms entry point, data source and sink.
Can you define them for me in simple terms please?

Source and sink are used in a data flow analysis. The source is where data comes from, the sink is where it ends. With regards to application security, source and sink are frequently used for taint analysis.

Data is "tainted" if it comes from an insecure source such as a file, the network, or the user. Any data that touches data also becomes tainted. If tainted data is ever passed to a sensitive sink, then static analysis will flag an issue. For example, if user input from a web form is printed, unescaped, into a log file, then a static analysis tool will report a log forging vulnerability.

I think that entry point is a more general term that refers to the place where a program or event handler begins execution. For example, the main() function of a C program or the doGet() function of an HttpServlet. This is the starting point for data flow analysis.


Forensics - Mounting Drives in RAM From a computer forensics standpoint. If someone were to mount a partition in RAM using something like:
mount -t tmpfs tmpfs /mnt -o size=1024m

How much more difficult would it be to recover data saved there than it would be to recover data saved and erased on a regular harddrive?

It depends.

The kernel can use swapfiles as backing store for a tmpfs filesystem: if the kernel decides that it needs to swap out something to free up physical RAM, the contents of the filesystem are candidates for swapping out, either in whole or in part.  If you're lucky (or unlucky), coherent pieces of data will wind up in the swapfile for an investigator to see.  Even if parts of the filesystem get swapped out, though, recovering data will be difficult: since the filesystem metadata may not be present and data may be in random order, it's more akin to performing forensics on a memory dump than on a filesystem.

If the computer is still running with the filesystem mounted, it may be possible to perform a DMA attack to recover the contents of RAM.  In this case, forensics will be easy, particularly if the swapfile can also be dumped, because the entire structure and contents of the filesystem is accessible.

If the data does not get swapped out and a DMA attack is not possible, the only option is a cold boot attack to try to recover the contents of RAM before it decays.


Hashcat to mask recover variable length password with known suffix I'm struggling with creating a mask to brute-force using Hashcat a password of variable length, but with a known suffix.

Say the known suffix is 123$ but the variable-length "prefix" can contain between 4 and 7 characters (i.e. total length 8 to 11 characters)

Do I need to define a charset? I'm aware of "increment mode", but how do I stipulate a variable length mask - looking at examples it seems to only let me define each character independently, how would this work with a variable length?

You won't need to define a charset if your password uses one of the included ones.

You should use a .hcmask file to define your different lengths.

Like this:

?a?a?a?a123$
?a?a?a?a?a123$
?a?a?a?a?a?a123$
?a?a?a?a?a?a?a123$

There are 96 characters in ?a, so 96⁴ + 96⁵ + 96⁶ + 96⁷ ≈ 2⁴⁶ hash computations are necessary, which would require 10 to 20 minutes at 70 GH/s.


Prevent or detect key copy This question can be classified as somewhat two interrelated questions - or two goals.

Main aim is basically to authenticate client to server, but remain secure even if someone steals the key from client.

Goal 1: Say I am using symmetric key to authenticate my (client's) request to server -e.g. using HMAC.
What are the (modern/secure) ways to store this key on client's HDD so that if someone has access to my HDD, he/she can't copy the key, to use it for his/her purpose. e.g., create malicious request to server. If this Goal is completely and easily achieved we may even drop Goal 2.

Goal 2: Now, Goal 2. Additionally, if someone still managed to get the key, it should be possible to prevent attackers from accessing the server from a different computer from which the key was stolen. This goal can be seen as a way to strengthen our system if Goal 1 was not achieved. If we have good means to achieve Goal 2, our needs are fulfilled.

For example one way to solve our problem (both goals basically), is in addition to HMAC, to let the server accept connections only from some specific IPs (in case someone stole key, he/she can't connect from other PC). But this won't work if the IP isn't static. Any other ideas in this direction? To ensure from other computer (from where key was stolen) attacker can't access server.

Because like I said for example if we have a secure means to prevent attacker to access server form a different computer from which key was stolen, we may relax the requirement a bit on secure key storage as mentioned in Goal 1.

Note: Using passwords each time to encrypt/decrypt the main key is not an option because the software must work on automated fashion.

Software is running on Windows.

PS. To make it clear preferable are solutions which don't rely on HSM (or expensive hardware), if possible.

PPS. The answer with votes doesn't focus enough on Goal 1 and Goal 2.

There are two issues here (just like in your question). I'm going to explore both of them. First, the Conceptual Problem and then the Practical Implementation.

Conceptual Problem

Here's the deal, something that everyone should just know, but I've found is really hard for people to accept.

We cannot protect a computer from itself.

What I mean is that when trying to keep something secret on a computer, especially on the HDD, but really, also in memory, that thing will not really be secret. We can build very complex OSes and data silos, however, in the end, there's a Trusted Computing Base (TCB) and then there's everything else.

In this case, you've got a secret (Message Authentication Code Key or MAC key) or as the other post/commenters have suggested you'll have to use an asymmetric Pub/Priv Key. That key material is just information and you've got to put it somewhere and that location has to be accessible to programs running on the computer without human intervention. That means either it will be in the clear or it will be encrypted with some other Key (password from a human or yet another crypto key). You don't want human intervention, which means that the password or the second crypto key needs to be stored.

Now, we are in a recursive problem and there's no base case!  Why? Because we cannot make a computer keep a secret from itself. At least, not if it has to use that secret, and your program needs to do just that. So, in the end, your key material or that encrypted key plus the second key used to encrypt it will be available to at least one process on the computer, and therefore, be copyable (as information) to any other device on the planet. Security blown.

Really, you might as well keep the key in the clear (unencrypted), in an O/S protected file, harden your servers to attack and monitor the network and servers for problems. Of course, people freak out when you suggest keep it in the clear b/c "OMG, you didn't ENCRYPT it?!" Ok, fine, so protect it with encryption, but don't lie to yourself about how safe it truly is. Laws to keep credit card data protected save Marketing Face, they don't really protect anything. The most important part of the laws are customer notification upon break in and theft of personal data. That is important.

In the end, someone could find a way to steal your MAC Key and whatever else you use to identify the remote server, and therefore, spoof the identity of the remote server. The best you can do is to use the crypto algorithms as they've been designed and for the purposes they were intended and then protect and monitor.

Bruce Schneier discusses this.  (1) Proper algorithm selection and implementation. (2) Proper System configuration. (3) Active Monitoring.

Also, as an aside I recall reading a research paper that showed how to pick keys off a hard disk by scanning and looking for highly entropic regions of short (key) length. The idea is that most stored computer data is of regular form. Sections of data that don't have patterns (appear random) are most likely encrypted data or keys. Encrypted data will tend to be grouped. Keys will tend to be isolated. INOW, stored key data on a hard disk actually jumps out at you if you're looking for it in the right way.

Good luck with that.

Practical Implementation

Your improper use of a crypto algorithm has lowered your security resulting in an attack more likely than the theft of your machine key from your machine.

You're using MAC Keys as a means of identification. Please note that Eve the Eavesdropper could discover your MAC key by watching one exchange and then off line attacking the message+MAC to reveal the key. This could be an expensive attack; however, depending upon the system and the data, it could be worth the cost.

In this case, you've abused one crypto algorithm (Message Authentication) for another purpose - server identification and trust. Instead, you need to separate Authentication of the server from Authentication of the message (which is really misnamed and causes confusion, so I call it Integrity protection, which is what it is).

Any good Authentication algorithm (4 step handshake authenticating both client and server) creates session keys which can be used for Privacy (session encryption) and Integrity (message authentication). Note, I write keys because you shouldn't use the same key for both. The best algorithm you can use provide Perfect Forward Secrecy, which these days means DH at 2048 bits. However, DH is subject to MITM attacks, so you need a way to mitigate that. I would suggest using SPEKE or DHEKE, whichever one is no longer under patent protection. You could also do what TLS does and sign the DH ephemeral with an RSA key, but now you're into PKI.

At this point, I'd say that you could just use TLS+RSA and make sure it's properly configured and limit your root certificates or use two-way authentication in which you don't need Root Certs and each peer validates the other. This will provide exactly the type of security you'd like to have.

So, if you're going to roll your own authentication system, really dig into the philosophy of good crypto system design and do it right. You'll probably wind up replicating Kerberos or TLS, but you'll learn a lot. Here's what happens when you think you understand enough about this and still build it incorrectly.

Or, don't roll your own and just adopt Kerberos or TLS and take advantage of everything they have to offer.

I suspect you know which way I think you should go.


Can Chrome browser history be seen on work wifi, even if not re-loaded? I use the work wifi daily but am always conscious of using work related sites.

However Android tends to keep most apps running in the browser so my windows(tabs) are never essentially closed down. If I take my phone to work and the tabs are still open on the phone from what I was browsing at home or on the train but are not re-loaded, will this show up on the works internet history?

I know that work wifi history sites are checked.

It will only show up in their history if the page loads something.

The problem is there are many things that can cause the page to load something other than explicit user actions. Some sites may auto-refresh on a timer (slashdot used to do this). Some sites may use ajax or websockets to check for new content on the server (stackexchange does this). The traffic generated by such scripts is likely to be visible to anyone monitoring your internet connection.


Updating the SSL fingerprint on an IoT device I'm currently in the process of designing the security model for an IoT product my company is developing.

The device will be connected to the internet via WiFi and shall communicate with our company's server only.

The communication will be done via HTTPS
During physical product assembly, the server's SSL fingerprint will be stored on the device. The device uses this fingerprint to make sure that it actually talks to its "home" server everytime it establishes a connection

A problem with this approach arises as soon as the server's SSL certificate changes. All devices in the field will then no longer be able to connect to the server due to a failing fingerprint check.

A partial solution would be to create a time period in which the server would distribute its new fingerprint to all connected devices, along with the exact time it becomes valid. The devices could store the new key and use it starting from the advertised date. But this doesn't solve the problem for devices which are not online during the fingerprint distribution period.

Is there any potential solution to this problem which I might have overlooked? What is "the right way" to do such a thing? (I can't be the first one to do it, can I?)

This sounds like you haven't created an update mechanism for the product that you are releasing. This is of significant more concern than updating signatures for pinned certificates. How will the product be updated in the event security improvements need to be made or bugs need to be fixed?

The product should be released with an initial signature for all TLS connections. The update mechanism should be capable of pulling down an updated firmware image and deploying it to the device. The device should only request these updates over a TLS encrypted channel. The server side update deployment code should sign all firmware updates with a private key. The public key used for signature validation should be embedded in the firmware when the device is released. This way you are able to update the TLS signatures using the update mechanism as well as the public keys that are used for firmware image validation.

Make sure that you update the TLS signature values and the public keys used for image validation before they expire, this may mean you have a 3 month update period prior to the expiration of either. This period should be defined based off of how long it generally takes users to update the product; you want to give everyone significant time to update their device and a method to perform a manual firmware download/update in the event these values/keys are not updated before they expire.


Why are the gitlab SSH host key fingerprints not matching? I tried to log into my university's gitlab via SSH. As expected, I was warned that the host is not known. Therefore, I tried to find the SSH host key on the "current configuration" page in the manual. However, I found that the key does not match the key that SSH shows me on the first connect.

To demonstrate this, here you can find the respective "instance_configuration" page for gitlab.com. The RSA-SHA256 fingerprint is said to be

  2fdd0c7dfa7d9381f847266c800eafc96f5866fe859c4f1cf87da885c82e333a

Using the script I found on this superuser post (or when connecting via SSH for the first time) I am told that the RSA-SHA256 for the SSH host is

  ROQFvPThGrW4RuWLoL9tq9I9zJ42fK4XywyRtbOz/EQ

which is

  44e405bcf4e11ab5b846e58ba0bf6dabd23dcc9e367cae17cb0c91b5b3b3fc44

in hexadecimal (and hopefully matches what you see… or not).

My questions: Should'nt these be equal? Did I miss something? How can I verify that the SSH connection is secure?

There are a large number of reasons why this can happen:

Hosting location.  Gitlab can be downloaded and hosted elsewhere.
The host keys posted on gitlab's page don't mean anything if your university is hosting their own version of gitlab.  In that case you would never see gitlab's host key - you would see the host key for your university server, and the difference would be meaningless.  You would have to ask the university what their host key is, and you are very unlikely to get an answer from them.
Out of date info The host key for Gitlab may have changed and they simply forgot to update that help page accordingly.
MitM Someone could be executing a MitM attack against your computer and has redirected traffic from gitlab to their own malicious server.

I figure option #1 is worth mentioning because it's not quite clear if your University's gitlab page is hosted with gitlab or your university.
 It sounds like it is gitlab hosted, but it isn't necessarily (obviously the repo URL should make that clear).

The possibility of MitM

Out of all three of these options, #3 is by far the least likely.  A successful MitM attack in this case can be both difficult and has little real benefit (for an attacker), so much so that it wouldn't even occur to me to consider it under normal circumstances.  So unless you are trying to connect to a remote gitlab repository so you can transfer up state secrets, you're probably just dealing with options #1 or #2.

You can also try to verify the likelihood of MitM by checking the IP address that of the server you are connecting to and trying to figure out if it belongs to gitlab.  Gitlab does have a (probably also old) list of their ip addresses:

https://gitlab.com/gitlab-com/infrastructure/issues/434

No guarantees of a match even for a valid gitlab connection because of the possibility of out-of-date docs.  Also no guarantees because someone running a successful MitM could possibly (depending on the details) also spoof an IP address.

Most likely scenario

Regardless, MitM is (IMO) very unlikely, and as a result I would just do your thing.  You should be able to find out soon enough if there is a problem.  Presumably you'll connect to the gitlab server, find the files you are expecting to find, copy up some stuff of your own, and then will be able to verify with whoever you are collaborating with that they received a copy of your work.  If so there is definitely nothing to worry about.

In general, my experience suggests that few organizations bother publishing host keys for verification.  Host keys certainly can be used to verify a server you have never connected to, but in practice I don't find that to be terribly common.  I suspect this is primarily for the reasons I mentioned briefly above: I don't believe this to be a common attack vector and you can usually find out pretty easily if you are connected to the right server simply because there are almost always more parties involved to verify your results.  As a result, I have most commonly used host key verification to detect when the server has changed than anything else, and I rarely (if ever) use it to verify a server on first connection.


Value of Physical Security Vulnerabilities to an Attacker A common trope in cyberpunk fiction is the necessity of physical access to a networked machine in order to execute an attack--the brilliant hacker has to hire a team of meatspace criminals (or vice versa), and the whole team physically enters a secured location.

In current, real-world networks, what benefits would physical access to a networked machine provide a potential attacker?

How do these benefits compare to the risks associated with breaching physical security? For example's sake, let's say at a Tier II center (https://www.colocationamerica.com/data-center/tier-standards-overview.htm) in line with most or all of the security measures outlined in this article.

Finally, are there any network security measures in use today which can effectively prevent remote access by an attacker? Specifically, I'm looking for measures with 1) proven effectiveness, that 2) could be most easily circumvented with physical access to a network machine.

In current, real-world networks, what benefits would physical access to a networked machine provide a potential attacker?

The most obvious example is an 'air gapped' network that is not connected to the internet - there was a real-life example of this in stuxnet where the target facility had no external networking. To physically access the network, the attackers dropped USB drives containing the worm around the facility that facility employees found, picked up, and plugged in, accidentally releasing the worm into their internal network.

You may also frequently hear the term "m&m network" or "m&m security". These terms refer to a network with a hard 'outer shell' and a soft 'chocolate center' - networks that have strong perimeter security but no security features (encryption, authentication, etc) between services or hosts in their network. Physical access to one of these networks can help bypass the hard outer shell.

  How do these benefits compare to the risks associated with breaching physical security at, say, an average data center?

Like other risk questions, this depends on risk/reward. If all you need to do is drop some USB drives near the target network there is low risk. I've been in a few data centers and they all have substantial security - unauthorized physical access is highly unlikely, and employees have been trained against common social engineering tricks and won't disclose information or plug in USB devices. Suffice to say that 99.999% of the time you can be assured that nobody will have unauthorized physical access to the datacenter.

  Finally, are there any network security measures in use today which can effectively prevent remote access by an attacker?

This is too broadly scoped to fully answer, but a good example is the airgapping we discussed before: disconnecting your network from the public internet to prevent anyone remote from even seeing your network. Of course this has the drawback of preventing your network from talking to any other networks or the internet.


SHA and "Bits of Security" I've researched several forms of encryption/hashing and have often come across the term "bits of security".  For example, at least one source claimed SHA-256 = AES128 = ECC256 = 128 bits of security.

My question is, if this is true, can I take a 256-bit SHA-256 digest and compress it down to 128 bits without loss of security? (For example, by just taking the XOR of the upper 128 bits and lower 128 bits of the digest)

In my particular case, it's important that the digest be small.  Thanks in advance for any responses.

Cryptographic hash functions must have several properties:

Resistance to preimages: given x, it should be infeasible to find m such that h(m) = x.
Resistance to second-preimages: given m, it should be infeasible to find m' such that h(m) = h(m').
Resistance to collisions: it should be infeasible to find m and m' such that m ≠ m' and h(m) = h(m').

These properties are not equivalent to each other, and you do not necessarily need all of them. It depends on the protocol in which you are using the hash function. For instance, hash functions are used at the initial step of digital signatures, for which collisions are not a problem -- unless the attacker is in position to choose an exact message to be signed. Details can be subtle.

If the hash function has an output of n bits, then there exist generic attacks which find preimages, second-preimages and collisions with cost, repsectively, 2n, 2n and 2n/2. A "generic" attack means that it works for all hash functions, regardless of how perfect they may be. This sets the maximum achievable security level.

If you "compress" SHA-256 output to 128 bits (whatever compression procedure you may want to use, even a simple truncation), then you are actually defining a new hash function with a 128-bit output. As such, the resistance to preimages and second-preimages of that function will be at best 2128, and resistance to collisions will be at best 264. Therefore, your truncated SHA-256 will offer "128-bit security" only in usage contexts where collisions are not an issue. But since it can be quite hard to ascertain that collisions are indeed not a problem, "compressing" hash function output is not recommended.

In general, we prefer to be safe than sorry; thus, when we want "128-bit security" we use a 256-bit hash function. That way, we don't have to worry about whether collisions could be leveraged into an actual attack or not. SHA-256 collisions are not feasible with existing technology.


Are there any projects/papers on approaching exploit development with AI/automation? I'm looking for research on the topic if at all possible or readings about efforts into this.
Drilling down into binaries via fuzzing/fingerprinting for known vulnerable binary patterns and a little boilerplate shellcode to insert into binary when found seems doable.
I envision it working in layered steps.
Look for fingerprints of known vulnerable binary.
  Vulnerable? loop
    Yes: Insert shellcode at vulnerability. Continue searching.
    No:  Fuzz application, use collected errors as fitness rating.
         If exploitation successful, add to fingerprints, append
         shellcode, continue searching.

This comes with the assumption of having a binary "DNA database" for vulnerability fingerpriting. Fuzzing errors trying to crash in a specific way that can be exploited, which ranks them in the genepool. Some crashes are more valuable than others.

The ACM had a workshop on Artificial Intelligence and Security in 2018 as part of SIGSAC.  They published the proceedings here:  https://dl.acm.org/doi/proceedings/10.1145/3270101


SEToolkit cloned website can be viewed over internet, but does not harvest credentials I've been working with SEToolkit's website cloner/credential harvester. Everything works fine locally: The clone opens on the victim pc, victim inputs credentials, after submitting the victim is redirected to the real page and the credentials are stored in a text file.

However, when I port forward port 80 for the private IP of the Apache server, the website can be viewed but it hangs once the user submits the credentials. The credentials are never stored and the user is never redirected to the real page.

I was wondering if anyone here has encountered this issue as I have not seen this question come up through google searches. Thanks in advance for any help!

Look at the HTML source, where is the form posting to? My guess is that it's configured for an internal address, which would cause your issue, since nobody else will be able to reach it by its internal address. Change the action= attribute in the form tag to be the public facing IP address.


How to check if all PC programs are using the VPN's IP? With browsers you can go to websites that specifically check your IP to see if your VPN's IP is there. But how do you check if all the other programs or applications on your computer are going through the VPN using the VPN's IP address? Is there anything that would cause a program to use your real IP instead of the VPN's IP?

In general, IP routing isn't program specific, but  the next-hop is selected based on the routing table, in this order:

Destination address matches a directly connected network.
The routing table contains specific route for the destination network.
Default gateway.

Depending on the VPN implementation it might add routes that falls into category 2 or a default gateway with a lower metric value. The real IP might be exposed if the routing table contains a better route through that interface. Also, if communication to private networks (10.0.0.0/8, 172.16.0.0/12 and 192.168.0.0/16) is possible, it never uses the VPN.

This also means that the results from whatismyip.com and alternatives might not be globally true even on the web browser. Check your routing table and learn to interpret it.

Also, any program using networking automatically without actions from the user will continue making connections when the VPN is down. Many websites do this, too; don't leave your browser open unattended.


How secure is Libra considering Visa and Mastercard are behind it? Libra is the upcoming cryptocurrency by Facebook which Facebook claims is supported by variety of tech companies including but not limited to Mastercard, Paypal and Visa.
Facebook also enforces a real name policy, and at this stage we all know that Facebook tracks you down and steals data.
Considering the fact that Mastercard and Visa have access to SWIFT which means they could literally track every single transaction of yours and dox you, How truly secure is Libra?
Two first amendments of cryptocurrency were decentralization, anonymity and security, so far based on hypothesis Libra seems to offer none.

At the moment it is impossible to know how secure it is, because it basically doesn't exist yet. It will be launched in 2020. Also, everything that revolves around blockchains tends to be controversial, because the at the moment the "blockchain" is still a solution in search of a problem. So I guess most answers will be based on speculation, and this question might even be closed because it's too "opinion-based". Nevertheless, I'm going to tell you a few things to consider.

Libra is backed by a reserve of assets designed to give it intrinsic value. This is supposed to make its value stable, unlike BitCoins for example. This sounds like a good thing that is absolutely needed (who would want to use a coin that might lose half of its value overnight?). However, at the moment we can't know how well this will work.
Libra will start as a permissioned blockchain. This means that not everybody will be allowed to run a validator node. Citing the whitepaper: "To ensure that Libra is truly open and always operates in the best interest of its users, our ambition is for the Libra network to become permissionless. The challenge is that as of today we do not believe that there is a proven solution that can deliver the scale, stability, and security needed to support billions of people and transactions across the globe through a permissionless network."
The consensus protocol will not work correctly if more than one-third of the nodes get compromised.
The Libra Blockchain is pseudonymous and allows users to hold one or more addresses that are not linked to their real-world identity. But will this be legal? How about money-laundering laws? And taxes? Governments must be able to control the transactions, somehow. Pseudonymous doesn't mean anonymous. But if the blockchain is immutable, if the pseudonymous identifier is leaked, will an "attacker" be able to see how John Doe has ever spent his money? We will see.
Libra is still in prototype stage. Libra is powered by open-source software, and the technology behind the Libra Blockchain will be free for all to inspect, use, modify, and distribute. However, it must not be very mature yet, because, citing the technical paper: "As Libra Core is currently in the prototype stage and does not power a blockchain with a currency that has real-world value, our security procedures are not fully in place."

Sources:

https://libra.org/en-US/white-paper/
https://developers.libra.org/docs/policies/security


What is asymmetric information in relation to information security? I have just finished reading "Why information security is hard - An economic perspective", the term asymmetric information is mentioned. An example in this paper mentions

  "The technical bias in favour of attack is made even worse by
  asymmetric information. Suppose that you head up a U.S. agency with an
  economic intelligence mission, and a computer scientist working for
  you has just discovered a beautiful new exploit on Windows
  2000. If you report this to Microsoft, you will protect 250 million Americans; if you keep quiet, you will be able to conduct operations
  against 400 million Europeans and 100 million Japanese. What’s more,
  you will get credit for operations you conduct successfully against
  foreigners, while the odds are that any operations that they conduct
  successfully against U.S. targets will remain unknown to your
  superiors."

From an economic perspective, how does this quote pertain to economics? Does this mean that the economic benefit is in the hands of the person with the information? What are other examples of asymmetric information and security?

Asymmetric information is an economic term, not an information security term. Asymmetric information is when one party in a market has more information than other parties in the same market. The theory is that asymmetric information is bad because it prevents the market from operating efficiently, and gives few parties advantage over many parties in the market. It is also in contract theory where you have 2 negotiating parties instead of a market.

In the quote above security flaws are a market, and one party has more information about that market than others. My interpretation is that the information asymmetry conveys a benefit to few while allowing all others to be exploited. The costs to the world at large from being exploited by the bug probably outweigh the benefits to the party withholding the information.

Asymmetric information happens whenever one party knows more about something than one or more other parties, and is all around us in the information security world. A few examples are:

Cyber criminals find flaws which they exploit
Exploited parties do not disclose breaches
Vendors do not always share all relevant information on their products

That's just to name a few common examples, there are many more out there.


Can I safely use a physical USB stick inside VirtualBox (isolated) without possibly infecting the host OS? There is a program that I wish to run under VirtualBox in order to avoid possibly infecting my computer because I am not sure I should trust the source. (Based on download location).

It is for interfacing with a device over USB. When I use Virtualbox's ability to connect to a USB device connected to my computer, is it possible for a program to use that to hop through to my actual computer OS?

Short answer: No.

When you use VirtualBox, the USB device first connects to the host. Only then, through the VirtualBox drivers, the device is made available to the guests. This part cannot be circumvented because VirtualBox uses the Host OS capabilities for the most part (i.e., it is not a bare-metal hypervisor).

Most often, if there is a supported file system on the USB device, it is also auto-mounted, giving rise to further security issues. This part alone can be prevented in most OSes (by disabling automount). So if the malware depends on filesystem / file-related actions on the OS, VirtualBox could isolate the malware on the Guest OS (unless the malware uses VirtualBox-specific exploit to escape the VM and access the Host OS).


GET Security over HTTPS I am wondering if using the HTTP GET method over HTTPS to pass a username and password to a middle tier application would be safe.

Essentially I am considering using a PHP include statement to communicate the information between the front end and application server and I am thinking that this information will not be logged into a user's browser history as it is an include statement.

The alternative that I am using is curl and POST, but it is more complex than a simple include.

Any help on this would be greatly appreciated.

Dave

The HTTP GET method should be never be used to transmit sensitive information such as credentials.

I do not see why the HTTP GET method is easier than using the HTTP POST method, see the difference in code below.

I suggest to create an API that handles the authentication and communication to the back-end server.

Since you mentioned you're going to use PHP, have a look at this API framework: http://www.slimframework.com/

Theoretically the parameters in the URL will not show up in log files since you're using HTTPS. However, there are for example, corporate proxies that perform man in the middle attacks to inspect all traffic.

In these cases, the credentials will show up in the proxy logs and this is considered a bad practice.

Here's some PHP code (which requires sanitation):

<?php

  $username = $_GET['username'];
  $password = $_GET['password'];

?>

This example is wrong because:

Sensitive Information is transmitted in the URL
No input validation has been done

This example is a little better, but still requires you to perform input validation:

<?php

  $username = $_POST['username'];
  $password = $_POST['password'];

?>

That's the different usage between the HTTP GET and HTTP POST method using PHP (and of course your form method should be set to POST in stead of GET as well).


Can I isolate a specific computer on my network? My brother gets malware infections practically every week. Apparently he had a infection over the past 24 hours, I only noticed it because I checked the router logs and saw a massive amount of network traffic on his MAC address.

How can I limit the damage on the network when this happens? I try to educate him but nothing ever sticks. I even set up auto updates, EMET, antivirus, OpenDNS familyshield and a few other things but he always manages to get infected. I usually just MAC block him or egress the bandwidth to 1kbps when I see a ton of traffic until I can physically check the computer.

If your router has the features you could create a separate vlan and isolate his computer in that using firewall rules. Other than that MAC address filtering is really the only way.

However what I would do is ban him from your network. He won't learn his lesson because he has you providing free tech support whenever he makes a mess. Kick him off for a week, then limit his access to some very basic sites for another week or so. Charge him for tech support. He'll get the message or take his activities elsewhere.


Credit card aggregation based on open standards? Lately, there have been a couple of projects which aim to replace all the credit cards in your wallet with a single smart device which will hold all of them, sync with your smartphone, etc. (Namely Coin and Protean)

What I specifically don't like, however, is that there are so many points of failure involved:

Both require inputting card information on your smartphone, and both seem to sync card information with their servers. They promise that they "encrypt" all data. Problems:

Do I really trust them with their deploying cryptography properly?
Do I really trust them that they will store things securely?

Both use Bluetooth for communication with your phone, which seems downright dangerous.

Coin additionally uses Bluetooth to develop a sort of proximity sensor which doesn't allow the card to process transactions unless the phone is nearby.

How are they doing this? If they're just doing a Bluetooth MAC search, that's mindlessly simple to spoof.

Bluetooth has a number of security problems.

Are there any solutions out there (or even in the works) which act more like TPM/smartcard devices which work on proven standards and would hold up to audits?

Specifically, I don't like the idea of having so many points of failure (Bluetooth, on-phone "encryption" provided by them, online "encrypted" backups provided by them). I'm really interested in the idea of using a secure single-card device, provided that it actually is secure in an auditable, proven way.

Do you trust the vendors you buy from?  They are all bound by PCI-DSS and the penalties for storing it insecurely can be pretty harsh.  Older versions of Bluetooth had security problems(2.3 and prior), but if they are using current versions, there aren't known security issues, so it is possible to have a trusted pairing.

Is it as strong as having a TPM based system, no, but it also isn't as expensive or complicated to use and it isn't really any less secure than many "stored credit card" options that many consumers still use.  For many, CC transactions are only valid if they made them and disputing invalid transactions is trivially simple, with zero liability, so it simply isn't seen as a risk by many.

Also note that these devices ONLY work on magnetic stripe cards, which are inherently insecure to begin with.  You can't use them with chip based credit cards, so the markets they apply to are already not particularly worried about the security of the card data.

Using a TPM, while nice for us security nuts, is overkill compared to the existing risks in the system for the cards that these devices are designed to work with.  They already provide a comparable or better level of security than the existing system does.  Your cards could be stolen or copied, this system provides a way to know when your card is scanned and to link them all to one device (your phone) which will likely be far quicker to notice if it is stolen.  It uses an optional online backup, but many consumers already do that with vendors.

There is fairly minimal real new security risk introduced by these devices provided they are using a recent, secure version of bluetooth and particularly if they protect the credit card details with a key stored on the card itself (so that malware on the phone can't get access).


Am I actually seeing a Man-in-the-Middle when pushing to GitHub? When I attempt git push origin, I get the following error:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:7zYnlSpxx6z0t477lR5vNYfelxewzWwu8N1X6v+wsZA.
Please contact your system administrator.
Add correct host key in /home/mako/.ssh/known_hosts to get rid of this message.
Offending RSA key in /home/mako/.ssh/known_hosts:1
  remove with:
  ssh-keygen -f "/home/mako/.ssh/known_hosts" -R "github.com"
RSA host key for github.com has changed and you have requested strict checking.
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

This isn't super alarming in itself; it just means the ssh key observed for "github.com" is different this time from the last time I connected.

When I look online to figure out if GitHub has changed their keys lately, I see that their RSA SHA256 fingerprint should be SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8.
Screenshot in case that page change:

When I run ssh-keygen -l -f ~/.ssh/known_hosts -F github.com I get

# Host github.com found: line 1
github.com RSA SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8

The fingerprint saved in my known_hosts file matches the one advertised in GitHub's help pages, and does not match the one I observe when I try to push my work.

At this point, should I suppose that something bad is happening? What should I do about it? What further diagnostics should I run?

Update:

On a different network now (my home wifi), and I now I observe the advertised fingerprint. My impression is that this means there's "something wrong" with the wifi at the coffee-shop I was at earlier.

I'm taking for granted that I shouldn't attempt to bypass the normal ssh protections. If they're really inconvenient I guess I should just use a VPN or my own hotspot?
Should I treat that wifi network as suspect in other ways? Should I trust that my (https) web is secure?
Is this a problem that I should ask/expect the business owner to fix?

Yes, what you are seeing is very likely a man-in-the-middle attack. Without more information on your exact situation, all that we can tell from what you've said is that this specific hotspot is intercepting your SSH connections and presenting you with a different fingerprint. I suggest you try connecting to other SSH servers that you have already trusted fingerprints for (but not completing the connection, for obvious reasons) and seeing if the same behavior occurs.

  I'm taking for granted that I shouldn't attempt to bypass the normal ssh protections. If they're really inconvenient I guess I should just use a VPN or my own hotspot?

Yes, either use an end-to-end encrypted VPN (OpenVPN and IPsec are both good protocols for this), or your own Wi-Fi hotspot, encrypted using WPA2-CCMP with a strong password. You don't need to buy an expensive commercial VPN for this. You could configure your router to act as a VPN server and connect to it from the public Wi-Fi, ensuring that you are always using your home ISP's network.

  Should I treat that wifi network as suspect in other ways? Should I trust that my (https) web is secure?

Consider it to be compromised. You can generally trust websites using HTTPS because their certificates are signed using a trusted Certificate Authority, but an attacker on the network will be able to tell what website you are visiting and would be able to tamper with any unencrypted or weakly encrypted connections. They may also be able to exploit unauthenticated automatic updates as well.

  Is this a problem that I should ask/expect the business owner to fix?

It might be worthwhile alerting them, but remember that they most likely don't even know what SSH is, much less what to do about a potential MITM attacker. It's not like the business owner can do anything about it anyway, even if they are tech-savvy. Even if they are not using open Wi-Fi and have set a strong password, anyone who has that password can treat the Wi-Fi as if it were completely open and unencrypted. This will change when WPA3 with its opportunistic encryption becomes standard, but until then, there's not much that can be done. It's not like you can expect them to track down the source.


Is this a case of simple email spoofing or has my email account been compromised? I just arrived home and when got to my computer I checked my mail box and it was with a message coming from my own email address that was sent almost at the same time I got home.

I promptly identified it as bank scam, but it really worries me that it comes from my own address, so I'm just around an hour looking up the web how mail spoofing works and so and whether it's possible to forge an email address like this. After so many spams, it's a bit strange for me this one slipped through the spam filter, I guess because it's from my own address.

I checked my gmail account activity and it seems all fine, access solely from my cellphone and my macbook when I get home.

This is the email's source: http://pastebin.com/gj6J8CUb

Can anyone confirm whether it's most probably a simple spoof forging my email address or whether it's more potential that my account has been compromised?

None of the IPs in this message are from the range I use, they're all foreign.

Another question is, with such a bunch of authentication failings in the message as can be checked, how can the gmail spam filter let it go into my inbox?

TL;DR: Spoofing sender address is as simple as sending any other e-mail. It's a common practice for scammers to use your or any "reputable" e-mail address as the sender to make the scam look more trustworthy. The timing is likely a coincidence, the mail apparently went through gmail's servers so it must have been sent from the Internet.

Long version:

E-Mail works in many respects just like a regular postal service.

There are two unrelated use cases in using both mail and e-mail:

sending mail
receiving mail

Sending mail is the process of putting a message into an envelope, writing a sender and receiver address on it and giving it to a postal service to deliver. This same happens with e-mail. You can write whatever you want on the envelope and you don't even have to have a mailbox of your own to send a mail - you can just grab a paper and envelope at your local store, write whatever you want and then give it to the Post to deliver. This process usually ends by the postal service delivering the envelope to the specified mailbox. Again this is the same for regular post and e-mail.

Receiving mail is you opening your mailbox and getting all the mails in there to you for reading. You do the same when getting both paper mail and e-mail.

E-mail usually comes in a convenience package where these two separate use cases are bundled together. It's still just a bundle of two separate services, just nicely packaged to look the same.

What I miss here though is how did you receive the e-mail? If you read it through gmail's webmail interface, it's likely a scam. If you received it via some software mail client (such as Thunderbird), there is  (always) a chance your computer is compromised but in this situation I'd bet on a simple scam anyway.


Why can't the FBI read the key embedded in the iPhone's secure chip/ROM directly from hardware (silicon)? As far as I understand, the 4 digit passcode is combined (in some fashion) with a key stored in secure read only memory (e.g. secure enclave chip or similar), where it is directly embedded into silicon wiring to help prevent unauthorized reads.

But no matter how strong or multi-layered or complicated the security is, wouldn't it still be possible to read the key directly from the silicon wiring of the secure chip or ROM, using some electron microscopy technique or similar? If so, surely the FBI could develop the technology for this, without asking Apple for help.

Yes, it is possible.  However, that runs the risk of destroying the device without getting the data off first, which is undesirable.  It also does not achieve the political goals of forcing Apple to assist in decrypting the device, paving the way with precedent for the flurry of future requests of this sort to come, some of which are certain to have less favorable facts and thus are not as suitable as test cases.


TLS replay attack - requirements of the serverHello nonce As you all know, the SSL/TLS protocol requires both client and server to exchange (in clear text) a random number or nonce. This is presumably used to prevent replay attacks.

It is not clear to me what the server-side nonce requirement is. Must it simply be unique? Or must it also be unpredictable? What would be the implications if an attacker could predict the nonces generated on the server side, if any?

I welcome any source of serious work around replay attacks that could help better understand the server side nonce requirements.

Thanks.

Louis

Within SSL/TLS, the nonces are used for generating symmetric keys, and as part of the signatures and checks during the handshake. For all those usages, the nonces are simply concatenated (with some other data) and hashed. Assuming that the hash functions behave like "random oracles" (the mythical perfect hash function), then unique nonces are sufficient.

However, SSL/TLS up to (and including) TLS 1.1 uses MD5 and SHA-1 as hash function, for which weaknesses have been demonstrated. They are not random oracles. I am not aware of any result about turning these weaknesses into attacks on SSL/TLS itself; however, better be safe than sorry: use unpredictable nonces. This will not harm, and both client and servers must already have access to a cryptographically secure source of alea, hence unpredictable nonces should not be a too heavy requirement.


Do password complexity requirements reduce security by limiting search space? I've read that password complexity requirements make passwords easier to guess via brute force attack. The reason for this is that the complexity requirement actually reduce the search space for brute force guessing by eliminating possible passwords. I would take this idea further by suggesting that passwords generated by human users tend to meet complexity requirements exactly. That is, if the requirement is password must be at least 8 characters and contain at least 1 numeric character, then the passwords that people tend to come up with will be exactly 8 characters long and will contain exactly 1 numeric character. This would have the effect of reducing the search space so far as to make it almost trivial to guess passwords that are created in this way.

My question is this:

Is it true that password complexity requirements have the effect of making passwords easier to guess by reducing the number of allowed passwords, and thereby reducing overall security? Extra points for links to detailed analysis and discussion.

This is an important question because if it is true then it is our responsibility as programmers to push back on product management when these kinds of requirements are proposed.

The short answer is yes, but not really. Password complexity requirements do reduce the search space slightly by limiting the number of possible passwords. However, users don't select passwords uniformly over the set of all possible passwords (they're biased toward words, dates, etc...).

Combinatorial Analysis

To keep things simple, let's assume we've asked the user for an eight-character, case-insensitive alphanumeric password (/^[a-z0-9]{8}$/ if you'd like).

Without a complexity requirement, there are 36^8 possible passwords.  This is approximately 2.8 trillion possibilities.

Let's say you then impose the requirement that at exactly one character is a digit. There are just ten choices of digit, but it could appear in any of the eight positions. This leaves 26^7*10*8 possibilities, or approximately 640 billion possibilities.

Of course, users are unlikely to use strange symbols in their passwords without a complexity requirement. If numbers are our stand-in for weird symbols in this case, that means each position really only has 26 likely options.  This leaves 26^8, or approximately 208 billion possible passwords. The password with the complexity requirement is more than 3x better than unrestricted input from a biased user.

Summary

So yes, complexity requirements reduce the space of possible passwords. However, they help when there is a known bias toward a small subset of the possible passwords. Real complexity requirements don't limit users to a single special character, and there are many more than ten special characters possible. The benefit of real complexity requirements (including punctuation, unbounded length, and "at least one" requirements) versus allowing users to input any (possibly biased) password is much greater than what I outlined here.


Howto pass overly protective corporate firewall My Corporate Network was always being monitored, but a few days ago they started to block and censor all HTTPS traffic.
Recently IT guys forged certificates for all major HTTPS web sites and acts as a man in the middle. The rest of the HTTPS does not work at all. I cannot and will not connect to a secure site knowing that they are spoofing everything.
TOR does not work too, because the SOCS port is restricted too.
The only open port seems to be 80, but I am not sure.

What are my options? OpenVPN, SSHTunnel? And How?

Although there are ways to do this I would advise you not to try. Chances are good that circumventing your company's security is against policy and could get you disciplined or fired. If you are having trouble doing your job because of the new policies then talk to your management. If all it does is block facebook then deal with it, and get a smartphone or tablet to do your personal stuff.


Client vs Server security for business critical application (crossplatform) We have the option to develop a software either based on

Java (but then it is only available for desktop clients using Java SE and can run maybe also as tomcat app can be multithreaded, stable, secured ...) or

PHP (which runs then only in the webbrowser or in a local xampp instance but seems also more unstable, insecure, slower ...)

Wich is the better option for the (main) application regarding maintainability, security (we work with some data like email addresses in the application), stability and speed.

In a fight between a polar bear and a white shark, who will win ? Guess what, if this is a pool fight, the shark will munch through the bear in less than two minutes (this site makes unsubstantiated claims to the contrary, but there are strong clues that a shark eating a polar bear really happened). Now put them both on a land, and I will put my money on the bear (here is a video with a huge walrus in the same position, and it is not pretty).

This little analogy is meant to express that it depends on the situation.

If you develop your software in Java with Java code running in the client (as an applet or with Java WebStart), then most of the computing will be done on the client, which is great to make responsive interfaces and lighten the CPU burden on your servers, but also tends to require that the client is somehow trusted. This is the same issue as multi-player games: the more you delegate to the client machines, the more you give them the ability to cheat. Also, Java on the client system requires Java support to be installed, which is not hard but not a given either.

You can also make a Web site where everything happens on the server. You can do that with various languages and frameworks, including Java (that's where Tomcat becomes relevant) and PHP. That the server uses Java does not imply that the client must have Java installed (if you think otherwise then think again). It then becomes a question of "what programming language is better ?" and we know that such questions cannot be really answered. The only generic assertion that can be made is that the most secure language is that which the developer masters most. Writing a secure application requires that the developer knows all the small details of the tools he is using, because security comes from thinking about what happens in unusual conditions. Security, like maintainability and also speed, really depends on what your developers know.


Why aren't there FIPS level 4 devices on the market? While searching for a secure USB to use, I came across the Aegis secure key, which has FIPS Level 3 (140-2) security. I believe that it's the securest flash drive on the market. I found that the highest level is actually level 4, which is only to available to government workers. Why is it only available to them and is FIPS level 3 safe from the government trying to hack into it?

When based on a standard, especially those as stringent as FIPS 140-2, you have to go through the following processes (which are time consuming and expensive):

Design
Testing
Certification

If you take a look at the NIST Implementation Guide for FIPS PUB 140-2, along with the other documents, you can search for the Level 4 implementation which detail that this is designed to be tamper-proof.

It is considered "overkill" for most businesses and even personal use because it protects against "drilling, milling, cutting, burning, melting, grinding or dissolving the epoxy or potting material, in order to gain access to the underlying circuitry." It is also meant to protect against environmental factors. This is your doomsday USB standard, where you under no circumstances can lose or leak the data.

It is a very aggressive set of requirements that is very likely not very economical if you intend to sell it to a consumer, for the same reason a crash-proof car is feasible, but your average person is not willing to pay the price or deal with the complexities involved.

This explains why government entities can have this kind of technology:

They are not a profit seeking entity, technically.
They are not restricted by the requirements of making a product marketable, they are their own customer (and other governments, too).
They have schools, renowned labs, and dedicated facilities at their beck and call to build "cool" things in the name of safety, public service, defense, or what have you.

Bear in mind that building cryptographic devices, especially at the hardware level, is not a fool's errand.


Oauth2 PKCE - What security does "S256" provide over "plain"? The Oauth PKCE protocol flow is as follows, as defined in RFC 7636:

                                             +-------------------+
                                             |   Authz Server    |
   +--------+                                | +---------------+ |
   |        |--(A)- Authorization Request ---->|               | |
   |        |       + t(code_verifier), t_m  | | Authorization | |
   |        |                                | |    Endpoint   | |
   |        |<-(B)---- Authorization Code -----|               | |
   |        |                                | +---------------+ |
   | Client |                                |                   |
   |        |                                | +---------------+ |
   |        |--(C)-- Access Token Request ---->|               | |
   |        |          + code_verifier       | |    Token      | |
   |        |                                | |   Endpoint    | |
   |        |<-(D)------ Access Token ---------|               | |
   +--------+                                | +---------------+ |
                                             +-------------------+

My question is: why do we need to use a trapdoor like S256 in step (A)?

According to the RFC's threat model, a malicious app cannot intercept the outgoing communication in (A) or (C). So why can't an app generate and temporarily store a random value in (A) and re-use it in (C)?

To elaborate: the goal of t(code_verifier) (ie S256(code_verifier)) is to later enable the app to prove to the server that it is indeed the app as it possess code_verifier before the transform.

However, if the app just sent code_verifier and later sent it again, the same guarantee is achieved: the server receives a random value that uniquely identifies the app, and receives it again. No other app can provide this value: as long as the connection isn't intercepted (and it shouldn't be - TLS), S256 seems unnecessary.

I can't read, apparently. The justification is described in the RFC itself:

A number of pre-conditions need to hold for this attack to work:

[...]

  4. Either one of the following condition is met:

      4a. The attacker (via the installed application) is able to
          observe only the responses from the authorization endpoint.
          When "code_challenge_method" value is "plain", only this
          attack is mitigated.

      4b. A more sophisticated attack scenario allows the attacker to
          observe requests (in addition to responses) to the
          authorization endpoint.  The attacker is, however, not able to
          act as a man in the middle.  This was caused by leaking http
          log information in the OS.  To mitigate this,
          "code_challenge_method" value must be set either to "S256" or
          a value defined by a cryptographically secure
          "code_challenge_method" extension.

plain is enough for the threat model described in my question, but S256 is indeed necessary for a more advanced threat model.

Now I am wondering: if the attacker can observe all responses, what is stopping the attacker from observing the final access token response?

Why does this threat model restrict request/response observation vulnerabilities only to the authorization endpoint?


How can I use parabolic antenna to strengthen access point signal for evil-twin penetration testing? I am using TP-LINK TL-WN722N v1.x for evil-twin penetration testing but the signal is not stronger than the target access point, so the attack is easily recognizable. I am trying to figure out how can I the strengthen the signal of the TP-LINK TL-WN722N v1.x.
I have two options:

Wireless Range Extenders and Repeaters
Parabolic Antennas

I have done some research but I don't have any experience using parabolic outdoor antenna to ensure what I am doing and I don't waste my money on antenna if it will not work. Any guidance and advice are appreciated.

Using high-power Ubiquiti wnics or cheaper ALFA variants is simplest. Both offer an effect of ~1W, although Ubiquiti is more trustworthy on specs. Using yagi antennas (google radiation patterns) is best, parabolics have a dot focus. A note on this: use a red laser pointer to aim the parabilic, keep the laser perpendicular to the centre of the dish. RXQ etc on your laptop displays with an annoying delay, so laser really is best if you don’t have a signal-meter (for 2.4/5.8GHz... it’s flooded anyway).

I use a yagi that is quite small, about 15cm long. You can use one with more directors but the focus becomes smaller... 2-3 are adequate. A parabolic dish’s dot focus may be visible to your target router but not target client. They are best for PtP links, not eviltwin against several targets. Note that patch antennas are very good, if placed in an elevated position and pointing down ~25°, so depending on your locale these may be an option... They can be had cheaply, and I recommend you buy one produced by Ubiquiti if possible.

Ubiquiti has MMCX ports, whereas ALFA has RP-SMA. You can use short pigtails to connect MMCX/RP-SMA to the typical N-connector on most quality antennas. The ALFA USB wnics I have used run stupidly hot, I have lost one to just heat. The ones with Ralink chipset seemed to perform best, but Realtek is OK. Add some cheap heatsinks or they won’t perform decently after a few hours.

DD-WRT is highly flexible, with the right router can also output ~1W, and is easily configured as a repeater... Have a look at a few high power Ubiquiti APs on eBay. The default WebGUI on Ubiquiti is complemented with a linux environment accessible via SSH/serial, though DD-WRT (using OpenWRT package repos) has more software available.

Get an FTDI/USB-TTL for 3.3V if you accidentally fail firmware changes, it will help tremendously to have a console when you restore it.


Help to determine what type of encryption has been used? I am performing a security assessment against an application, i would like to recognize the encryption function used to generate the following hash

PWYXFYNRWTYZ
HVZPVPMBBFPB
VXTCHXMHPKVH

As shown above, the hashs are 12 byte alphabets

Regards

It's not clear whether each of the three values that you posted is a result of the hash function in question, or the result of the hash function is all three values concatenated together.

However, it looks like the each of the values that you posted are 55 bits long.  Each of them are made of 12 English uppercase letters.  There are 26 uppercase letters in the English alphabet, so this means that there are 2.54*10^16 (26^12 = 2.54*10^16) possible such combinations.  The equivalent number of bits needed to produce this number of combinations is 55 (2^55 = 3.60*10^16).

Most modern hash functions produce results that are much longer than 55 bits in length (e.g. even the obsolete MD5 hash function produces 128-bit results).  See https://en.wikipedia.org/wiki/List_of_hash_functions, which shows the length of the results produced by various hash functions.  So, my guess is that the result of the hash function in question is all three of the values that you posted concatenated together.

If that's the case, then this means the result is 165 bits in length (55*3=165).  So, it's possible that this could be RIPEMD-160 (160 bits) or MD5 (128 bits), or several others referenced at the link above.


Security of a backup server I am concerned about attacks of the crypto malware which encrypts all storage reachable (for a ransom payment you get the key to decrypt). I use only Linux (Debian) and have a separate ARM computer to write each night a backup to disk.

What is better (more secure against attacks):

to mount the disk with the data to be backed up as read-only (remote mount) on the backup server
use a remote source for rdiff-backup

The backup server is on at all times but not directly accessible with ssh (only locally from computers which are accessible from outside).

How could an attacker get into the backup server (assuming it had gotten into one of the local machines)?

The best way to solve this, is to use LVM Snapshots, to create a "virtual" drive, that is then snapshotted incrementally with regular intervals. This virtual drive is then "shared" through Samba, iSCSI or similar tool to each Windows computer.

Of course, every client can use the same virtual drive.

IF a ransomware then encrypts the files on this "virtual drive", causing all files on the shared Samba/iSCSI disk to be encrypted, you simply delete the snapshot images (which are "diff"s of a drive) until the files are accessible again.

Of course, a good idea is to have the server secured by a firewall such as so it can only be accessed through its Samba/iSCSI ports over the network.

Any console access is to made physically, at the local console.

No other solution is better, as if you mount the drive readonly you must still enforce some sort of versioning on server side, else you will overwrite a perfectly good backup with encrypted rubbish if a ransomware happens to attack.

If you use rdiff, you must still make sure the diff versioning is enforced on server-side and not client-side, else the ransomware can bypass this and overwrite all the diff's.

The best way to enforce versioning on the server side, is to use LVM Snapshots and then just share a "flat iSCSI drive" or a "Samba share" to the client computer. The advantage, is that malware, cannot know that the drive in question is versioned on the server side.

The only disadvantage with a server-side versioned drive, is that you transfer all data over the wire, even unchanged data, but that shouldn't be a problem since you transfer regularly instead of transferring all at once.


Adequate prevention of distributed brute force attacks? What are good ways to prevent distributed brute force attacks on my website?

I think (not sure. if someone can assure me, thanks!) my site is secure against normal brute force attacks as I am using following pattern to throttle continuous login attempts for a single username:

X = Failed Login Attempts
Y = Time, since the last login attempt, for which next login attempt will not be accepted (in minutes)

if X is a multiple of 5
Y = 2^(X/5)

This increases the time delay by some exponent of 2 for every next 5 wrong login attempts.

Then I thought to myself, what if someone tries to distribute this brute force attack over multiple usernames/accounts for a same password? O.O

My first instinct was to search the internet for common practices. I did search and found different solutions. Every solution has had its own cons whereas most of them were too complicated.

And then whaaam! This wild idea crossed my mind:

It doesn't matter if you provide wrong or right credentials, the login script will sleep for 1 second while verifying your credentials.

If I used this method, it would take approximately 14 hours to try a password on 50k accounts or vice versa and hence making the bruteforce little impractical.

Since this my first web app, I am barely confident if this method will be okay to use. I am not sure if it will cause too much serverload or if it is even, at all, safe. Does this method offer a good trade-off between time and resource cost, vs. added security?

If somebody can help me figuring out if this is the right method and help me imroving it and/or suggest a pratical method (in case this isn't okay), maybe I can offer you an additional cookie if we ever meet?

Bit late here but there are a bunch of suggestions here: https://stackoverflow.com/questions/479233/what-is-the-best-distributed-brute-force-countermeasure

A problem with "it would take approximately 14 hours to try a password on 50k accounts" is what if your legitimate user tries to log in after a bot net has put in 50k requests and has to wait the 14 hours? Not happy presumably.


Tricky code to make memory-safe I'm designing a homework challenge for students who are learning about memory safety and writing secure C code.  As part of this, I am looking for a small programming task where it's non-trivial to write C code that is free of buffer overruns, array out-of-bounds errors, and/or other memory safety errors.  What would be a good example of such a task?

In other words: I specify the desired functionality; they implement it in C; and if they're not careful when implementing, there's a significant chance their code will have a memory-safety vulnerability.  Ideally, I'd prefer something that can be implemented concisely (a few hundred lines of code, at most) to keep the task of manageable size, and it'd be extra-cool if the task were somehow industrially or practically relevant or realistic or representative of real-world programming.

To give an example from a different domain, implementing binary search on a sorted list is a classic example of an easily specified programming task where if you're not careful when implementing it, there's a significant chance you will have some sort of logic bug (e.g., an off-by-one error, an infinite loop on some inputs, that sort of thing).  Is there any good corresponding task, for security, and specifically memory-safety vulnerabilities?

A typcial example of non-trivial buffer handling is the parsing of binary files (or network packets) that can contain arbitrary-length strings.
(Is there any ASN.1 parser that didn't have buffer overflows bugs at some time?)

For example, consider the format of textual data chunks in PNG files:

  The keyword and text string are separated by a zero byte (null character). Neither the keyword nor the text string may contain a null character. The text string is not null-terminated (the length of the chunk defines the ending).

So the homework could be a tool that outputs all textual data in a PNG file.

Even plain text can be not quite trivial if you need to handle arbitrarily long lines, and thus need to resize a buffer dynamically.
For example:

  Implement tail without parameters.
  (Lines can be longer than any static buffer. The entire file can be larger than available memory.)


Is this a legitimate Microsoft email or is this a Phishing email and how can I tell? I am a mobile application developer using Microsoft Azure with my MSDN subscription to develop my back-end of the application.

Today I got the following email:

So given my above background this email seems to be correct. But there are a few red flags here for me:

The email was sent from mscloude@clickdimensions.microsoft.com. Doing a WhoIs on clickdimensions.com I can see no connection to Microsoft
The email starts "Dear Customer" instead of "Dear [My Name]" another red flag for me
There is no mention of the name of the VM in question which is strange
It is very strange that I have to reply to an email to keep my VM alive, what am I even supposed to write in the reply?

I haven't clicked the link but it seems to link to a clickdimensions site and I haven't replied to the email. I am confused to what the payload is if this is infact a phishing scam.

Is this a phishing scam or just a badly written Microsoft email?

What should I be looking out for when identifying a phishing email?

The aim of phishing is to obtain information about the victim, to which the attacker is not entitled.

There are two typical ways a phisher would obtain that information:

The victim supplies it by including it in a reply to the phishing email, i.e. by sending the information to an email address controlled by the attacker.
The victim supplies it by first following a link in the phishing email, which takes them to a web page controlled by the attacker, and by then entering the information into that web page.

Regardless of the mechanism, the aim is the same: to persuade the victim to send that information to some external resource (email address or web page) controlled by the attacker.

Therefore, to identify a phishing email, follow these steps:

Establish which mechanism the email is asking you to use: is it asking you to reply by email, or to click a link to a web page?
Establish whether the external resource is owned by a legitimate entity. Here's how:

View the source code of the email you received. If you don't know how to do this, look in your email client's menus for a "View source" or "View original" menu item, or look online for help with this step.
If the email you received asks you to send an email:

Read through the source code to find the email address it is asking you to reply to (e.g. the "reply-to" address). Make a note of the domain name for that email address (typically but not always the whole part after the "@" symbol). For instance, in the case of phisher@example.com, the domain name is example.com.

If the email you received asks you to click a link:

Read through the source code to find the URL it is asking you to visit. Depending upon how the email you received was formatted, this URL might be in an href attribute of an HTML a element. Make a note of the relevant part of the domain name for that URL. The relevant part consists of: the top-level domain or country-code second-level domain (i.e. the rightmost part), and the word and dot preceeding that. Examples:

URL: https://microsoft.odd.com/form/. Relevant part: odd.com.
URL: https://microsoft.odd.co.uk/form/. Relevant part: odd.co.uk.
URL: https://odd.microsoft.com/form/. Relevant part: microsoft.com.
URL: https://www.microsoft.com/form/. Relevant part: microsoft.com.
URL: https://microsoft.com/form/. Relevant part: microsoft.com.

Now that you have the domain name, or at least the relevant part of it, check whether it matches the ostensible sender of the email.

If the domain bears no apparent relation to the ostensible sender, the email is probably phishing. (E.g. email is ostensibly from Microsoft, yet domain is v5fld7s5d1g.com.)
If the domain bears some apparent relation to the ostensible sender, but is not their primary domain, the the email might be phishing. (E.g. email is ostensibly from Microsoft, yet domain is emailsfrommicrosoft.com.) In this case, perform a WHOIS lookup on the domain in order to establish the domain's owner. If WHOIS reports an owner that doesn't match the ostensible sender, the email is probably phishing.
If the domain matches the ostensible sender's primary domain name, then the email is probably not phishing. (E.g. email is ostensibly from Microsoft, and domain is microsoft.com.)

If you are still in doubt, contact the organisation in question after obtaining their contact information from some other, more trusted route (i.e. not using any contact information in the email). For example, in your case, you could look for Azure's customer service team's contact information on the Azure website and contact them to ask whether they sent you the email.


Finished message - TLS1.3-draft(28) In TLS 1.3 , while computing Finished message,

finished_key = HKDF-Expand-Label(BaseKey, "finished", "", Hash.length)

How can "finished" be used for this calculation as it is the objective of this process or it signifies anything other that I am missing.

See https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-7.1 for the definition of HKDF-Expand-Label in TLS 1.3:

  HKDF-Expand-Label(Secret, Label, Context, Length) =
  HKDF-Expand(Secret, HkdfLabel, Length)

  Where HkdfLabel is specified as:

struct {
    uint16 length = Length;
    opaque label<7..255> = "tls13 " + Label;
    opaque context<0..255> = Context;
} HkdfLabel;

The string "finished" is used as part of the label.


Does WhatsApp disclose the sender's IP address? Does WhatsApp disclose the sender's IP address? Is it possible to get it by running netstat -a or via Wireshark?

WhatsApp uses a client/server architecture based on Jabber (XMPP).

For the recipient(s) to see your IP addresses, the application will have to include your IP address in the metadata of the message. But this has no functional role in the design of such an application.

Your packet capture will likely show IP addresses belonging to WhatsApp(or Facebook) and maybe a CDN company like Akamai that stores media.


Security concerns with external MySQL access using tunnelling I have gotten my personal vServer with a standard installation of Ubuntu Server 16.04 and I wanted to install and configure a MySQL server on it. I was considering to disable direct external access, but enable tunnelling so that I can create a secure tunnel using SSH to access it from my computer anyways.

Considering this I would like to know whether there are any caveats of the attempt to secure this.

Well, assuming you are using SSH to access the server anyway, that tunneling is effectively already in place. I would suggest doing a few things to prevent unauthorized access to your VPS:

Give a non-privileged user "sudo" access. Make sure you do this first if you decide to also implement step 2. Otherwise, you'll lose remote access to your server.
Prevent Root Login over SSH. Now you'll only be able to login remotely as the unprivileged user in step 1.
Change the port SSH listens to. I personally use a port number over 10000 that ends with "22". This helps avoid drive-by hacking attempts that hit the standard SSH port (22).

The combination of these three changes will mean that you will need to login as an unprivileged user first, using the custom port you chose in step 3. Then you can issue privileged commands using the sudo command. You'll also need to use the custom port and unprivileged user for SSH tunneling of your MySQL client.


XKCD #936: under what assumptions is 1000 guesses/second over a network plausible? In XKCD #936, a rate of 1000 password guesses/second is proposed as a "plausible attack on a weak remote web service".  Under what assumptions is this rate plausible?  It seems much too high to me.  I would expect TCP handshakes, or waiting on server responses, to be the dominating factor, but I don't know enough about networking to justify these expectations.

My question is related to
XKCD #936: Short complex password, or long dictionary passphrase?,
but is not a duplicate, because no one there questions or explains the 1000 guesses/second assumption.

The only statistics I was able to find are for the THC-Hydra remote password cracking tool.  See "STATISTICS" in http://www.thc.org/thc-hydra/README.  But the services considered there (ftp,imap,pop3,telnet) are presumably not "weak".

Note that the THC-Hydra statistics were made against a machine which is described as running SuSE Linux 7.2. In the history of the S.u.S.E / SuSE / SUSE / openSUSE Linux distributions, this brings us back to mid-2001, so this benchmark was probably done on a machine of that era. Technology has improved since, and computing speeds have grown.

A typical "weak remote web service" will use HTTP basic authentication, possibly within a SSL tunnel (i.e. that's HTTPS, not HTTP). Each password guess then entails the following: sending a HTTP header which contains the presumed password (say 200 bytes for the header) and then obtaining an error response (a 401 error code, with a header which will be probably less streamlined for size than what the attacker chooses; say 1 kB of header). Since HTTP supports keep-alive, the TCP connection (or SSL/TLS tunnel) can be immediately reused for another attempt; in particular, this means that there will be no noticeable overhead in the presence of SSL. 1000 attempts per second then requires a bandwidth of about 200 kB/s to the server, 1 MB/s from the server; that's a 10 Mbit/s bandwidth and even cheap hosting services offer that much. On local networks, 100 MBits/s or greater are the norm. No bandwidth problem here.

Of course, the attacker should try to parallelize in order to avoid latency. There is no need to wait for the server's answer before sending another request. Parallelization, here, means opening a hundred connections to the target server, and running them in parallel. Operating systems, nowadays, can handle many thousands of open connections; one hundred will not starve the machine.

Server-side, since all attempts target the same user the (hashed) password will be in RAM (it is normally stored in a file or database, but RAM is used as cache for frequently accessed data, and during a password-cracking session that data element will be very frequently accessed). Since we are talking about a weak remote web service, the server will store passwords "as is" or hashed with a simple hash function, not something like bcrypt. Rehashing each incoming password will use negligible CPU (an anemic PC can compute millions of hashes per second, so 1,000 hashes per second is nothing). Similarly, the HTTP header parsing will not use much CPU.

So 1000 password guesses per second seems a highly feasible figure; actually, it should not be too hard to exceed it by a large margin. Note the important points in the discussion above:

The attacker can parallelize, since he has many passwords to try.
Authentication occurs very early in the processing of an incoming request, so normal processing costs of requests (for whatever functionality the web service provides) do not apply).
Usage of slow hashing function (like bcrypt) can be effective in such a situation.


How safe is it to open source access to MySQL database on github, only permitting SELECT query? The Setup: Im building an app to model visually world data.  A significant part of this project will be the database since that data is what is interesting.  I should only need to allow SELECT queries, and perhaps eventually CREATE TEMPORARY TABLES should there be collaboration.

<?php
  DEFINE('SERVER_NAME', 'localhost');           //Database server name
  DEFINE('USER_NAME', 'myCPanelName_openSrc');  //Database user name
  DEFINE('PWD', 'opensrc');                     //Database user password
  DEFINE('DB_NAME', 'myDatabase_appName');      //Database name
?>

The Problem:  The data that would be exposed is my CPanel login name, and the database name.  It seems leaving a door open to my database may have unseen consequences.  Even while restricting access and using generic credentials.

The Question:  What is standard practice in this situation?  And how risky is this business of open-sourcing a database?  Is data corruption/theft my only concern?  Or are the consequences more sever?

This is not safe to do. Do not expose MySQL servers to public access.

Any user with SELECT access to a MySQL database can execute a denial-of-service attack by performing queries which generate excessive CPU load. A simple example is SELECT BENCHMARK(1e20,1); performing a series of CROSS JOINs between large tables would have a similar effect.
Allowing an unlimited number of users to connect with these credentials may allow them to consume all available connections on the server, preventing other users from accessing the server.
Information about the source address and current queries being run by other users connected with the same credentials will be leaked through SHOW PROCESSLIST, even if the user does not have the PROCESS privilege.
Allowing any user to access the MySQL server may expose the server to exploits which require access by an authenticated user. No public exploits of this sort are currently known, but it is possible that one will emerge at some point.


Can rootca validity start date be lower than current date? What will happen if we create rootca X509 certificate with validity date lower than current date? Will date of creation taken into account while cms_verify?

What will happen if we change the system time to a lower date but after the validity start date, why will the cms_verify fail?

    Validity
        Not Before: Apr  4 09:26:00 2016 GMT
        Not After : Apr  4 09:26:00 2026 GMT

faketime -f "2017-01-01 01:00:00" bash -l

date

So 1. Jan 01:00:00 IST 2017

openssl smime -verify -in a.cms -CAfile ./../data/CA.pem -out b.cms.xml

Verification failure

140392937076368:error:21075075:PKCS7 routines:PKCS7_verify:certificate verify error:pk7_smime.c:342:Verify error:certificate is not yet valid

A certificate has no record of when it was created, just the validity period, represented as a date (and time) for notBefore and notAfter; and either of them can be set to whatever you like (though there's not a well defined behavior of setting notAfter to a value less than notBefore, other than "not working").


How secure is this communication chat? I have created a chat between two parties (using c#), and I am wondering what kind of weaknesses have I overlooked.

Description of its functionality:
There are two individual applications: Client (2 instances of TcpClient being the communicating parties) and Server (TcpListener, the relayer of encrypted messages).

Note: I am assuming that both computers containing the client application are safe and don't contain any malware or viruses that could tamper/monitor memory, input keys, make screenshots, etc... On the  other hand the Server application can be on any computer which can be potentially 'compromised' for lack of a better term.

Now Clients's functionality is registering the message from the keyboard of the user, encrypting it (Using AES256 c# classes) and sending the data to the server. Although before the messages could be sent the clients are exchanging public keys according to Diffie Hellman key-exchange algorithm, but all the communication between the clients works through the server. Essentially the server is a gateway, a bridge between the clients, [1], after key exchange and secret key generation server only receives encrypted messages, it doesn't bother with its contents, just relays the message to the other client, which decrypts it locally. [2].

I have been thinking to wrap my NetworkStream into an SslStream, to make the communication channel more secure, but even if someone can 'read' the stream they can not read the encryption anyway, so I don't think this is a critical flaw for keeping the SECRET-MESSAGE safe.

I am not protecting my .exe file in any way (neither in server nor in clients) since I do not think there is a 100% protection if the computer has already been compromised. In other words the bad guy can decompile my .exe, how bad is this and should I even take some kind of precautions? Although the secret keys generated by D-H are kept locally in computers (generated anew every time a connection has been established between clients) since I am assuming that the Client computer is safe, there shouldn't be any problems with this, right?

Weaknesses I've noticed:

[1]: It has a direct access to clients information (IP address, when was the message sent, even how many characters the message contained (~ of 8 bytes)).

[2]: The server application can be tempered with, to imitate the second client and capture the channel, sending their own public key and receiving other client's public key, effectively taking the place of second client. This can be easily solved if the parties exchange a greeting in any other communication software (skype, etc) and confirm that they are connected to each other (messages are being received at the same time they are sent, etc).

P.S. I am aware of some weaknesses that I have mentioned above, but those aren't critical, I would like to know are there any critical flaws that I have missed, and how would you rate this setup from 0-10? What can I add/change make improvements to what I already have / fix flaws.

This communication protocol is fairly weak as you do not provide authenticity or integrity. There are a number of attacks it is vulnerable to. The most severe ones I can think of based on what you said are:

Replay attack - A replay attack involves an attacker sending a copy of any part of encrypted data. The recipient will not be aware that the message is a replay of a previous message. The attacker does not need to know the contents of the message to pull off this attack.
Malleability attack - You didn't mention what mode of operation you were using. Assuming it is CTR or CBC, an attacker will be able to modify the ciphertext to change the plaintext in predictable ways. The only solution to this is to use an integrity construct such as an HMAC.
Man-in-the-middle attack - An MITM attack is possible as Diffie-Hellman is unauthenticated. To provide authentication, you would need to use an additional keypair such as RSA or DSA. The DH key exchange must be signed by these keys in order to ensure authenticity. The fingerprints of the private signing keys can be exchanged separately, or exchanged and stored so all subsequent connections are using it (a technique called TOFU, or Trust-On-First-Use).
Semantic insecurity - If you are using ECB mode (or incorrectly using CBC mode, or a mode not designed for this purpose such as XTS), encryptions of the same plaintext has the potential to result in leaking information through duplications visible in the ciphertext.
Metadata leakage - The length of messages of text gives away a surprising amount of valuable information. Unless you are padding your messages to a specific length, or at least padding them up to a multiple, you are allowing an attacker to learn information about the conversation based on the length of the ciphertext. Padding in this context is unrelated to padding in cryptography.

As you can see, there are a lot of variables that come into play when writing a cryptosystem. Real cryptographic protocols are quite complex. This complexity is absolutely necessary for mitigating a variety of common and not-so-common attacks. As you asked for a 0-10 rating scale, I would give this protocol around a 3. If you use ECB mode or you generate AES keys improperly (e.g. using a poor PRNG), it would be even lower. If you want to write an application that does encrypted chat, I would suggest using the OTR library, called libotr. The library provides secure end-to-end encrypted communication and repudiation (plausible deniability in regards to message contents), and more.


SAML2 vs. OAuth - What are some reasonable relationships? I have a service that allows SSO via SAML2. When SAML2 is used, we delegate the entire authentication process to the Identity Provider.

We are considering adding OAuth in order to support some mobile applications. (We don't want the user to have to log in constantly.)

It's pretty obvious how it will all work together when we are using our own Username/Password authentication, since we are in control of the entire stack.

How will OAuth interact with SAML2 SSO though? For instance, what should be done to invalidate OAuth grants if the Identity Provider removes a user? What other gotchas (and hopefully standard solutions) are there?

Bridging the SAML and OAuth 2.0 frameworks is a well understood problem. The following stack of IETF specs provides a standard solution:

If you look at the core OAuth 2.0 spec (RFC 6749) and its token endpoint definition - this is basically an OAuth server endpoint which returns an access token in exchange for a "grant" -- an open-ended concept of something deemed appropriate to grant the client app the issue of an access token. In the typical OAuth scenario this is an authorisation code signifying that the user has been previously authenticated and given their consent. But the grant could also be something else.
There is a further IETF spec called draft-ietf-oauth-assertions-16 that builds on the core RFC 6749 standard which says that the grant can also be an assertion (a signed proof of something) and defines the necessary token request parameters for that.
Finally, there is draft-ietf-oauth-saml2-bearer-20, which specifies how this assertion can be a SAML 2.0 Bearer Assertion.

This standard mechanism for converting a SAML assertion into an OAuth 2.0 access token is essentially all that is needed to bridge the two frameworks.

To ensure removal of users is properly reflected by the authorisation systems there are two approaches, which can be combined:

Make the OAuth 2.0 access tokens short lived. This will force the client to repeat the authorisation process when the token expires, and if the user no longer exists authentication will fail and no grant (SAML assertion) will be issued.
Provide an API for revoking issued OAuth 2.0 access tokens, see RFC 7009 for details.


Any problems with UCC (multidomain) SSL certs on iOS and Windows Phones? Are they any known issues with UCC (multidomain) SSL certs on iOS or Windows Phone?

Let's say I want to have Exchange server under outlook.mycompany.com and RemoteApp Portal under portal.mycompany.com.

So cert will be look like:

mycompany.com (primary domain)
outlook.mycompany.com (additional name)
portal.mycompany.com (additional name)

Will iOS or WP complain on my SSL cert because of fact Exchange server name is given as additional name in cert?

After checking on real world example, answer is NO: iOS and WP are NOT complaining on additional name in SSL certs. They act as correct certs. Tested with GoDaddy certs.


Do the organisational policies need to have ownership to ensure accountability? Policies are the high-level statement from Senior Management. It's a philosophy for the management to be guided by, and management has the direction to plan, build, run and monitor the activities to achieve the enterprise objectives from the policies.
Is it possible to judge/assign accountability on the policy level?
My company hired a consultant who made the statement, and I'm looking for perspectives that will justify it.

Even after your comments, I'm still not sure what you are asking, but I will attempt to provide an answer.
High-level policies are set and "owned" by Senior Management.
Policies exist to assure that business objectives are met. Risks can affect those objectives. There are then risk owners to ensure that there is someone ultimately accountable and resourced to manage those risks.
But there are multiple levels of policies that can apply at different layers of the business. The policies written to be closely tied to the activities that mitigate risks tend to be owned by the risk owner.
So, it is possible to have policies that have a single, named owner, and others that are "owned" by Senior Management. Policies that set a philosophy are high-level policies and are difficult to assign accountability to.