Has the wedge security flaw been fixed for credit cards? According to this site http://www.lightbluetouchpaper.org/2009/08/25/defending-against-wedge-attacks/ there is a flaw in EMV. Since then has this flaw been fixed?

Is it the same law as the one exposed by BBC/Cambridge University?
http://events.ccc.de/congress/2010/Fahrplan/events/4211.en.html

http://www.youtube.com/watch?v=1pMuV2o4Lrw

because that later works even when terminal makes a connection to the bank
"remain undetected even when the merchant has an online connection to the banking network"

whereas the first seems not as it is said:

"the wedge attack can be detected if the terminal goes online, because the MAC check will fail."

If not it isn't clearly explained the remediation to that kind of flaw? Can the Bank or user do something to protect against this?

I think they are slightly different attacks, in the lightbluetouchpaper blog the wedge sends a fake MAC back to the terminal, in the other attack the card sends the MAC. This is why the second attack can work online, it uses a genuine MAC that the bank will accept.

The blog is run by the Cambridge researchers, Ross Anderson, Steven Murdoch et al. The original paper which presented the second attack that works online "Chip and PIN is Broken" can be found here:
http://www.cl.cam.ac.uk/research/security/banking/nopin/oakland10chipbroken.pdf

In the paper the researchers suggest some possible fixes and why they would/would not work in the 'VI Solutions and Non-Solutions section'. The main point they make is that to implement an effective solution the EMV standard would have to be changed which would be an incredibly costly thing to do due to large number of merchants, cards and banks using the current implementation and as far as I'm aware there has been no fix rolled out for the standard.

It would be possible for individual banks to fix this by getting the terminal to send the CVMR (Cardholder Verification Method Result) to the bank so the bank could check what the card thought had happened in the transaction and compare it to what the terminal thought had happened, they could then see that the terminal thought a PIN was used and the card thought a signature was used so know something was wrong. As the paper says

  Out of many, we have only seen one EMV card which requests this ﬁeld,
  and it is not clear that the issuer actually validates the CVMR
  against the IAD. Whether this ﬁx works for a given bank will depend on
  its systems; we have not been able to test it, and given that it
  involves reissuing the card base it would take years to roll out.

So the only way to know if fixes have been made is to test newly issued cards, as far as I'm aware there hadn't been anything published on this.


How is a DNS wildcard a security issue for GitHub Pages? GitHub Pages allows to set up a public page under <user>.github.io that can optionally be customized with a personal domain. In order to do so:

GitHub must be set up to recognize that an incoming call referred to by a non-GitHub domain should be handled
the personal domain must have a pointer to GitHub, via a CNAME in the domain's zone

At some point in the documentation, there is a fat warning:

(EDIT: I updated the example below to a more complete zone following Steffen's answer because I do not understand it)
Let's say that I own example.com and the public IP 150.1.1.1, and I have a wildcard DNS entry:
*.example.com. IN CNAME hello.example.com.
hello.example.com. 300 IN A 150.1.1.1
mypageongithub.example.com. IN CNAME myuser.github.io.

In other words, something not otherwise defined in my example.com zone points to hello.example.com.
How can this present a danger of someone using my domain to advertise their GitHub page?
Note: I posted the question in Information Security rather than superuser.com or another similar site as this is more about identity theft (or misrepresentation) than a technical question about DNS

*.example.com. IN CNAME hello.example.com.

A CNAME is resolved in the client to finally get the IP address. This means Github is not aware that you have a CNAME for *.example.com and that whatever.example.com resolves to hello.example.com using this CNAME. All it knows is that somebody wants to access whatever.example.com since this is the name used to access a github.io IP address.
If your <user>.github.io is only mapped to the name hello.example.com then somebody else could create a different <user2>.github.io page and map it to another-hello.example.com. Both domains resolve in the same target IP address (due to the CNAME) but one will show the contents of <user>.github.io while the other will show the contents of <user2>.github.io.
Note that this only relevant if you map all subdomains to github.io using a wildcard - as it seemed to be from your original question. After the edit of the question it came clear that there is only a single name mapped to <user>.github.io and that the wildcard is used for domains which don't map to Github. This is fine and this is also not was Github warned against when reading the warning in the context it was originally published.


What asymetric scheme provides the shortest signature, while being secure? I've had a look at several signature schemes (DSA, ECDSA for the most common ones), and am wondering about whether there exist a scheme that would have the following properties :

Be asymmetric (one need a private key to sign, one can verify with a public key)
Have a very short signature size (less than 50 bits)
Be secure by today's standards (hard to find the private key knowing a signature and the signed text)

I wouldn't even care if several signatures were valid for one text, as long as they are verifiable with the public key.

My intuition is that that "being" secure is inherently linked to the size of the encryption key, which itself has an impact on the size of the signature. As far as I could see, ECDSA gives shorter signatures than DSA with the same level of security, but the signatures are still too big for my use...

Any thoughts / links to signature schemes welcome.

edit: I read about BLS at some point too, but couldn't really find out whether it is doable to get a scheme secure enough with a signature less than 50 bits long.

edit2 : I should add that the goal is to use that for a OTP scheme, so the size of messages to sign would be small (< 512 bytes), and collisions wouldn't be a big problem : assuming the two parties know the message, I'd want for one of them to verify that the other has a private key, using a very short signature.

You cannot have a secure signature scheme in less than 50 bits. Demonstration: the attacker can just enumerate all sequences of 50 bits until a match is found. Indeed, one point of digital signatures is that the verification algorithm can be computed by just everybody, since it uses only the public key (which, by definition, is public).

Best you can hope, theoretically, is a signature of n bits for a security of 2n. Traditional threshold of infeasibility was n = 80 bits, but the relentless advance of technology tends to raise that. Modern cryptographers tend to jump to 128 bits, because that's a power of two, hence beautiful (Kant notwithstanding, most aesthetic judgements are relative). 100 bits ought to be safe for quite some time, though.

Among known signature algorithms which are believed to be secure, BLS is right now the best in class; it will produce signatures of size 2n bits for a security level of 2n, so you are contemplating signatures of size 160 to 200 bits at least. There are algorithms which can go below (down to about 1.4*n) but they have a rather long history of breakage and fixing and breakage again (I am talking about SFLASH and its ilk), so their use is not really recommended, and there's no directly usable standard.

Another possibility is to use RSA with ISO/IEC 9796-2 padding. As the linked article shows, there are some subtleties with regards to its usage. This signature scheme is a scheme "with recovery" meaning that while the signature is rather bulky (1024 bits if you use a 1024-bit RSA key), it can also embed some of the data which is signed; so, if your problem is about appending a signature to a message, then this scheme will induce relatively low overhead. As the article explains, you get 261 protection for a signature overhead of 22 bytes, aka 176 bits; to get good security, you would have to use a hash function with an output size of, say, 224 bits, leading to a signature overhead of 240 bits -- not as good as the 200 bits of an equivalent-strength BLS, but better than the 400 bits of DSA or ECDSA (for still the same strength level).


Risk of routing malicious email through internal email infrastructure This has been a long standing question of mine and I haven't been able to find a satisfactory answer so I hope someone here can help me out.

My question is - Imagine there is an email being routed out to the internet using an organization's internal email infrastructure (Microsoft Exchange, etc). If this email has a malicious attachment or a malicious script embedded in the email body, then I presume the risk of compromise is only to the recipient and not to the email infrastructure itself?

Discussions with colleagues always result in them saying we need to assume there is a risk to the email infrastructure but no one seems to be able to articulate what the risk is and how a compromise of the email infrastructure is possible.

Can someone please help me out here?

This depends if the mail is only routed (i.e. simple MTA) or if any kind of deeper analysis will be done (firewalls, IPS, BDS...). In the first case there is probably not much of an risk. But in the last case it is possible that the malware will be extracted and analyzed by some middleware. Such analysis is a complex issue and often contain bugs. In the worst case the analysis system itself could be compromised this way.

This is not a hypothetical attack. Such attacks happened against FireEye BDS where the passive monitoring of the traffic done by the BDS could be turned into an exploit. And another such issue existed with Symantec Endpoint Protection including Symantec Email Security. And probably others are affected too.


Why aren’t collisions important with HMAC? SHA-1 is broken because collisions can be found in substantially fewer hash operations than naive brute-force would suggest. HMAC-SHA1 is fine, however, because for HMAC “collisions aren’t important.”

Why aren’t collisions important for HMACs?

From RFC 2104 § 6 describing the security requirements for an HMAC:

  The security of the message authentication mechanism presented here depends on cryptographic properties of the hash function H: the resistance to collision finding (limited to the case where the initial value is secret and random, and where the output of the function is not explicitly available to the attacker), and the message authentication property of the compression function of H when applied to single blocks (in HMAC these blocks are partially unknown to an attacker as they contain the result of the inner H computation and, in particular, cannot be fully chosen by the attacker).

So it's not that collisions are not important for an HMAC. It's that a collision attack against a hash function does not affect that hash function when used in an HMAC construction. In particular, an HMAC demands much weaker security guarantees from the hash function than many other applications it may have. It only requires weak collision resistance from the underlying hash.

HMAC is defined as HMACK(m) = H((K ⊕ opad) || H((K ⊕ ipad) || m)) where opad and ipad are constants and H is an at least weakly collision-resistant hash. The key K is not known to an attacker. To trigger a collision with an HMAC, an attacker would need to do one of the following:

Find a collision that is valid for a number of keys.
Perform a successful key recovery attack.

Both of these are extremely unlikely to be possible for even the worst of cryptographic hashes, assuming the authentication tag is sufficiently large (typically at least 128 bits).


How to know if a host has been compromised and re-secure it again? (particular case of a raspberry) I'm running a raspberry PI and I've accidentally left the 22 port open to it from a public IP for about 24 hours. Raspberries' raspbian distro comes by default with a "pi" user and "raspberry" password so I fear that it could have been compromised.

I've just changed the password to it. What's the recommended way now to verify that there was no intruder access which would have removed its fingerprints (i.e. removing entries from /var/log/auth.log, etc)? How can I check if he's not created a user which was not already there by default in the system? Is there a way to secure the server again without the need of re-installing the OS?

It is impossible to prove that an attacker has not compromised your server.  It is always possible that an attacker accessed and installed malware that would be left behind.

The safest thing to do is to reinstall the OS.  This is the only way you can truly know that it is an uncompromised OS.  The password for the account should be changed so with public access an attacker could not login.

From looking at my system logs, my server gets about 1000 bad logins per day with most using the username root, but some using pi.


Is it recommended to drop all traffic by default in iptables after accepting only what is required? I was told using iptables -P OUTPUT DROP after rules such as iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT to accept what is required didn’t do much from a security standpoint. Is that true?
This is what I am been using for some time (planning on implementing some SSH brute force rules shortly):
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -P FORWARD DROP
iptables -P INPUT DROP
iptables -P OUTPUT DROP

Let me be blunt: "default deny" is the best practice. The concept is that the firewall blocks all traffic, and only allows the specific traffic that is approved.
But wait! What could those people mean that it doesn't add anything?
It's logic: without the DROP, if a packet does not match any rule, then the firewall doesn't do anything with it. There is no instruction for what to do with it. So it should just die, right?
However
That assumes that the system will behave in a consistent and predictable way when there is no matching rule. But you cannot be so sure about that.
A default deny rule is a safety net that ensures that the firewall will act like a firewall.


Why do some programming language API's not support private key passwords? Two questions:

I've recently started building a basic Go web-server, and noticed that the API for starting a TLS web-server does not support a symmetrically encrypted private RSA key. The API is included below, and linked here:

func (srv *Server) ListenAndServeTLS(certFile, keyFile string) error

1)
Given that Go is a new programming language, and written with the benefit of experience, I'm wondering why this is the case. Wouldn't the creators want to encourage the use of encrypted key files, and some pseudo-code pattern like this:

var decryptKey = secureNetworkSource.getDecryptionKey();
ListenAndServeTLS(certFile, keyFile, decryptKey);

Did I misunderstand the security benefits of using an encrypted private key file, i.e. it's possible that the above pattern would not be any more secure than just having the unencrypted key file on disk.

2) I'm also wondering why many of these server libraries across languages (Java being the other example that comes to mind) so often rely on the certificate being stored locally on the server; for instance, the Go API requires a path to a file. Why not support any bytestream, so that you could acquire a private key from another source and reduce the blast radius of losing the hard drive on a server?

Encrypted key files do have some value, but generally the value is limited because the practicality of serving a 24/7 operation dictates that the key must be stored on the filesystem somewhere in unencrypted form.  The alternative of the password being typed in by an administrator each time a server is restarted is terribly impractical and creates risk of the server being down if the password can't be remembered, or the administrator doesn't know it.

Being that Go is a new language, it's naturally going to be feature limited.  Not supporting encrypted key files seems a natural omission on a new webserver.


How is Privileged identity management (PIM) different from privileged access management (PAM)? I am very confused about those two, I was trying to understand the difference but it all sounds the same from what I read online.

An identity says who you are while authorization is concerned with validating someones mandate, aka the individual permissions to specific application functionality, data, or service.

Authenticating a person focuses on letting someone prove who they are. One identity can for example be linked to multiple accounts where each account can have different permissions within the system.


Besides MBR & BIOS, is it possible for a rootkit to stay persistent after a format of the hard drive? If a system becomes infected and does not have any other storage units besides the one hard drive.

Is it there any other way for a rootkit to stay on the system besides infecting the BIOS OR the MBR of said drive after a 'nuke from high orbit'?

Normally, no. Not in a self-bootable area. You might have data not overwritten by the disk wipe, in "out-of-band" areas, but those areas aren't normally accessible, and if made so, they also become accessible to the wipe.

Theoretically, for very large values of theoretically, yes. In some hard drives, there may be a third memory area that is accessible, self-booting and capable of hosting a complex malware (as complex as, say, a minimal Linux kernel).

(Update: the above trick has been reported in the wild by Kaspersky)

This area is normally not accessed (for programming) through the data cable by which the hard drive is connected to the host computer, but through a specialized JTAG connector which is only used during the manufacturing process.

Also, the programming instructions must be specifically adapted for the hard drive controller CPU chip; just as the same HTTP protocol may be "spoken" by a Motorola-powered old Mac or an Intel 80386, but the two CPUs won't ever "speak" the same language, so two disks from the same manufacturer may have an Avago chip, or a Marvell one - and they will require different and totally incompatible instructions.

The problem then is that the malware would have to be specifically targeted, and in most if not all cases, hardware physical access to the JTAG connector through a custom cable will be required. So a purely software malware would have no chances. Unless some programming backdoor had been burned in the firmware by the manufacturer, in order to save some bucks and do without the whole JTAG stuff. Which, predictably, it seems to have been the case.

A disk thus hacked is completely untrustworthy. Whatever you do to a hard disk from the SATA cable is actually no more than a polite request to the disk SoC to perform some action on your behalf. Untampered SoCs will obey (or lie to you to your advantage: for example reporting that a sector has been written instantly, while in reality it is being held in a write-back cache to increase performances). A tampered SoC might disobey and lie about it (and will do so, or there would no point in tampering).

You could (ask it to) overwrite the boot loader, read it back and receive an enthusiastic confirmation that it has been zeroed; (ask to) write a clean boot loader in its place, re-read it and receive a haughty confirmation that it has been written and committed. Then power cycle... and still have a malicious boot loader come out of the disk instead of the one you believed should have been there, thus bluepilling the system.

Of course, the malware should be aware of the operating system in use in order to infect it, and gain, through it, a more sophisticated access to files, network, keyboard and so on. It would do so by intercepting the operating system attempts to load its own code from disk, supplying instead modified code containing the infection routines. The modified code would need to be compatible with the operating system, and it would be powerless should the operating system self-check its own code, unless even more advanced techniques were used.

Actual probability is in the low noughts for any reasonably common scenario.

On the other hand... if you just received a brand new desktop as a token of NSA's appreciation for your work, then no - wiping the disk, zeroing its HPA and DCO and Gutmann-blasting every single sector it has, will not be enough.


What is the definition of "sensitive attribute" in the context of k-anonimity? I have encountered the term "sensitive attribute" multiple times when reading up on the concept of k-anonimity -- but the texts never formally define what this term means.
Take this example of a k-anonymized table from Wikipedia:
+------+---------------+--------+-------------------+----------+-------------------+
| Name |      Age      | Gender | State of domicile | Religion |     Disease       |
+------+---------------+--------+-------------------+----------+-------------------+
| *    | 20 < Age ≤ 30 | Female | Tamil Nadu        | *        | Cancer            |
| *    | 20 < Age ≤ 30 | Female | Kerala            | *        | Viral infection   |
| *    | 20 < Age ≤ 30 | Female | Tamil Nadu        | *        | TB                |
| *    | 20 < Age ≤ 30 | Male   | Karnataka         | *        | No illness        |
| *    | 20 < Age ≤ 30 | Female | Kerala            | *        | Heart-related     |
| *    | 20 < Age ≤ 30 | Male   | Karnataka         | *        | TB                |
| *    | Age ≤ 20      | Male   | Kerala            | *        | Cancer            |
| *    | 20 < Age ≤ 30 | Male   | Karnataka         | *        | Heart-related     |
| *    | Age ≤ 20      | Male   | Kerala            | *        | Heart-related     |
| *    | Age ≤ 20      | Male   | Kerala            | *        | Viral infection   |
+------+---------------+--------+-------------------+----------+-------------------+

Where "Disease" is defined as the sensitive attribute. One can observe that this "sensitive attribute" does not hold in any kind of k-anonymity (k > 1)...
Is the sensitive attribute the piece of information which under no circumstances should be mapped to an individual? Or is it the attribute which shall not be generalized/suppressed for the purpose of data mining? Or is it something entirely different?

In the k-Anonymity data model, there are different types of attributes:

Identifiers allow direct identification and must be removed.
Quasi-Identifiers allow linking with other datasets. It is assumed that the data holder knows which attributes are quasi-identifiers. In practice, this can be difficult since this depends on all the other data available in the universe.
Sensitive attributes are those attributes that shouldn't be linkable to an individual. What is sensitive depends on the context. Misjudging of sensitivity can lead to a weaker than expected anonymization.
Other attributes (neither sensitive nor quasi-identifiers) are not relevant.

In the k-anonymized data set you've shown (k=2), the data holder has anonymized attributes like name, age, gender, state, and religion. This indicates that the data holder considers these attributes to be identifiers or quasi-identifiers. However, there is no k-anonymization with regards to the disease attribute. This indicates that the data holder does not consider this attribute to be a quasi-identifier, but likely a sensitive attribute for which linkage should be prevented.
If I have information like “a female patient from Kerala between 20 to 30 years of age”, then I can't be certain about their disease – it could be either a viral infection or a heart-related illness. The anonymization at k=2 holds.
However, if I have information like “a cancer patient from Kerala” then I can easily identify the patient in the dataset. This is because I was able to use the disease attribute as a quasi-identifier, contrary to the assumptions of the data holder. This is an example of a background knowledge attack. Weaker variants of such attacks include background knowledge of correlation or distribution of attributes, allowing probabilistic identification.
This difficulty in determining actual quasi-identifiers is a core weakness in the k-anonymity model. To be safe, everything should be considered to be a quasi-identifier, but this will clearly reduce data quality. From an attacker perspective, understanding the differences between the data holder's assumptions and the actually available information may enable re-identification. Indeed, Sweeney's motivation for developing k-anonymization and similar methods was that she was able to link two supposedly anonymized datasets, since the data holders hadn't considered quasi-identifiers like ZIP code, gender, and date of birth.


How deauth attack works in mkd3 I watched a video on YouTube about it, and the guy did not explain well how mdk3 and its deauth attack works. Can someone please explain me this?
P.s: the guy used the tool aircrack-ng; This tool is from mdk3? If it is not what it is used for and how it works?

mdk3 is not included in aircrack-ng suite at the moment, but it seems they started to collaborate some time ago. Look at this: https://svn.mdk3.aircrack-ng.org/mdk3/docs/Documentation_incomplete.html

Maybe in the future could be integrated. In fact, the new MDK3 uses the osdep injection library from the www.aircrack-ng.org project.

The difference between aireplay-ng (included in aircrack-ng suite) and mdk3 is basically that mdk3 would be sending both disassociation and de-authentication packets, where aireplay-ng only sends de-authentication packets.

Regarding how it works... basically, mdk3 works by exploiting weaknesses in the IEEE 802.11 protocol.

It has a lot of TEST MODES:

b - Beacon Flood Mode

Sends beacon frames to show fake APs at clients. This can sometimes crash network scanners and even drivers!

a - Authentication DoS mode

Sends authentication frames to all APs found in range. Too much clients freeze or reset some APs.

p - Basic probing and ESSID Bruteforce mode

Probes AP and check for answer, useful for checking if SSID has been correctly decloaked or if AP is in your adaptors sending range SSID Brute-forcing is also possible with this test mode.

d - Deauthentication / Disassociation Amok Mode

Kicks everybody found from AP

m - Michael shutdown exploitation (TKIP)

Cancels all traffic continuously

x - 802.1X tests

w - WIDS/WIPS Confusion

Confuse/Abuse Intrusion Detection and Prevention Systems

f - MAC filter bruteforce mode

This test uses a list of known client MAC Adresses and tries to authenticate them to the given AP while dynamically changing its response timeout for best performance. It currently works only on APs who deny an open authentication request properly

g - WPA Downgrade test

Deauthenticates Stations and APs sending WPA encrypted packets. With this test you can check if the sysadmin will try setting his network to WEP or disable encryption.

A Proof of Concept about how to test it, here.


Protection against a fired IT employee Possible Duplicate:
  When a sysadmin leaves what extra precautions need to be taken?

We have some servers on two sites. We use Puppet to allow only SSH key (root denied) and authorize users to connect to each server by policy.

If someone leaves the company, I will just have to change something in Puppet to close the door. Send an email to the subcontractors and tell the news to avoid social engineering.

Have you got any other ideas?

You should always:

Remove his/her SSH-Key
Change all passwords he knew
Lock all his/her accounts on all services
Give certain services extra attention, e.g. mail forwarding rules

Some other measures you should consider, depending on the circumstances,  how much you trusted him or her and your resources:

Let another person with the same knowledge check if the leaving person installed any backdoors on workstations or servers.
Run routine scans for vulnerabilities you took as inexistent and which can be created on purpose in a short time, like SQL-Injection possibilities.
Check all workstations and servers he had access to physically for keyloggers and other malicious hardware.
Change the locks the person had keys to, you can't know if copies were made.

As a precaution it's good to synchronize HR with IT. Make sure that one person can de-activate all accounts at the moment the employee leaves his workstation to go meet with HR. At the very least change his passwords to stop him from accessing the network as he exits HR.


OAuth 2.0 authorization code flow vulnerable to "shoulder surfing"? When using the OAuth authorization code flow in web applications, after successful authentication of the resource owner, the authorization server usually responds with a browser redirect to pass the authorization code back to the client via the redirect URL's query string.

Now, if the redirect URL is short enough, the whole URL (including the authorization code) fits into the visible space of a browser's address bar.
An attacker, who is looking over a victim's shoulder can now see this authorization code.
In theory, if the attacker is faster than the victim's browser, he is able to steal this authorization code and pass it to the redirect endpoint of his own client.

Practical Example:

Someone is live-streaming his browser window to a public audience with low latency. An attacker in the audience has fully automated the attack: The video stream is captured, the authorization code is intercepted and then used to steal the victim's login session.

Questions:

Is there anything the client (or the corresponding back end) can do to prevent this attack?
Or can only the authorization server make the attack more difficult? One idea would be to hide the authorization code at the end of very long redirect URLs. But what if the user's client is currently unavailable? The timed out redirect request's URL is still visible in the victim's browser history and the attack is working as long as the authorization code has not expired.

Is there anything the client (or the corresponding back end) can do to
  prevent this attack?

It seems that the OAuth 2.0 PKCE extension is what I was looking for.
As explained within this thread, the PKCE extension prevents a leaked authorization code from being useful to an attacker.

This is achieved by exchanging a (e.g. user session specific) secret with the authorization server, not only when redeeming the authorization code (similar to the default client secret), but also when creating the authorization request, so that the authorization server can verify that during the whole process the secret (and therefore session) stays the same.


Understanding the Secure Multi-party circuit for Stable Matching I am reading the following paper:

MPCircuits: Optimized Circuit Generation for Secure Multi-Party Computation

link of paper

I have following questions:

why Preference of group1 starts from L_0 where as preference list from group2 starts with L_(n/2+1)?
Any reason why they used the priority encoder?
Is their anything done for security of preference list ?

Somebody please guide me. Zulfi.

This naming is only for illustration purposes to differentiate preference lists from two groups. In the Verilog code, they actually start from index 0:
https://github.com/sadeghriazi/MPCircuits/blob/705fda8ac6e45a2d67bbdd0c81007507742bd4ae/stable_matching_comb/stable_matching_comb.v#L64
You need the priority encoder to identify the 'next free person from group A'. Imagine you have a vector of 0s and 1s and you want to learn the 'index' of the first 0. That's what priority encoder does for you.
The security of the preference lists is guaranteed by the underlying secure computation protocol, here the BMR protocol. To use BMR, you need a Boolean circuit that implements the functionality for you. Any input to the circuit is not revealed to other parties during the protocol execution.


Should login pages be cacheable? I'm considering the relative benefits/disadvantages of making a login page cacheable. Note that here I'm referring to the page containing the form into which the user enters their username and password.

Certainly it doesn't add any protection against SSL stripping (the HTTP page is treated as a seperate entity from the HTTPS age for caching purposes).

It would seem to add some value in protecting the form from modification by rogue certificates and potentially against future issues in SSL - although it can only enhance the integrity of the form for entering the data - which must then be sent over a compromised connection. Does this nulify all the benefits of loading the page from the local cache?

I did find this report which asserts that caching the login page is a vulnerability, on the grounds that "It is not recommended to enable the web browser to save any login information, since this information might be compromised when a vulnerability exists" - however the login page is surely the one form we really don't want to pre-populate before sending to the browser? OTOH there would be issues in using a challenge/response based mechanism where the challenge is issued within the login page - but then it simply won't work rather than compromising the security.

It does not open a new attack vector via the browser cache - this already exists when the page is served as non-cacheable (although it does potentially make an attack by this root a bit simpler if the page is already in the cache).

Is there a significant benefit/disadvantage I have overlooked here?

According to OWASP Application Security any page that can have sensitive information should not be cached if it can be accessed by public shared computers like libraries.

https://www.owasp.org/index.php/OWASP_Application_Security_FAQ

Any page after the user is logged on is much more sensitive and candidate for no-cache than the login page it self (since login page is public).

I think that in the "Cacheable Login Page Found" report they mixed up two concepts. One concept is the caching of sensitive information as included in the page itself. The other is the caching of the login and password information, as part of browser configuration. That I know of, one directive does not affect the other (that is, considering the page as non-cacheable will not affect the ability for the user to store the password on the browser profile).

To ask the browser not to store login information you can use the autocomplete='off' form attribute.

https://stackoverflow.com/questions/32369/disable-browser-save-password-functionality


Could an Smart TV be a threat for a hotel? After some research I found that a Smart TV which is connected on the Internet could be vulnerable to threats such as monitoring, taking control of the tv etc.

I wonder if a Smart TV which is used by a hotel or another big company could be a serious vulnerability for the operation of the organization (e.g. attack the network, steal informations etc) and what impacts could cause ?

Also another concern I had is if Android OS on Smart TVs could be more risky because of android flaws?

SmartTV's have about the same security of other IoT devices like network-capable DVD players, IP cameras, routers, printers etc. This means: while there are some vendors which actually care about security there are others which don't. Specifically with the cheaper devices the chance is higher that the device is insecure but spending lots of money does not guarantee security either.

And if such device gets compromised it can both be a danger for the local network as for the rest of the internet. For one security issues might allow the device to be taken over from outside so that it can be used as part of a botnet to attack other systems, to spread spam and malware etc. But one notably difference between a SmartTV in a hotel and others IoT devices there like IP cameras, routers or printers is that the customer is actually expected to interact with the device and that the customer has physical access to it. If the device is in the same network as sensitive systems it might be used to attack other devices in this network. Putting these potential insecure devices into a different and strictly separated network will mitigate this risk.

It does not matter much what kind of OS is installed on the device. More important is if the software is recent (and not some old Android with known security issues) and if the vendor actually cares about security and provides quickly updates when needed.

For more information about this topic see for example How my TV got infected with ransomware and what you can learn from it or Samsung and Roku Smart TVs Vulnerable to Hacking, Consumer Reports Finds.


Why does windows defender scan my computer multiple times Occasionally, Windows Defender sends me a notification that my device was scanned. This occurrence is quite ordinary and boring, but I actually devoted two seconds to reading the entire message once, and it says it scanned my device x times. For example, the most recent notification told me my device was scanned four times. Why is one scan not sufficient?

On this Microsoft help page there is an explanation how to schedule tasks. Windows Defender should not scan more often than it is scheduled to scan.

It reads:

  Search for and open Schedule tasks.
  In the left pane, expand Task Scheduler Library > Microsoft > Windows, and then scroll down and select the Windows Defender folder.
  In the top center pane, double-click Windows Defender Scheduled Scan.
  In the Windows Defender Scheduled Scan Properties (Local Computer) window, select the Triggers tab, go to the bottom of the window, and then select New.
  Specify how often you want scans to run and when you’d like them to
  start.

You should also be able to check how often Windows Defender is scheduled to run now.


Does RSA encryption always pad small amounts of data to some larger size? If I encrypt 160 bits (20 bytes) of data using an RSA 1024 private key, will the result always be 128 bytes? This seems to be the case in my experiements, but I want to be sure.

For example,

/bin/echo -n "foo" | openssl dgst -sha1 -sign privateKey.der -keyform DER > enc.txt

always seems to result in a 128 byte file enc.txt even after I generate new public/private keys (the private key saved into the file privateKey.der).

Basically yes. That's how RSA works, as described in the standard.

On encryption, the input data is first "padded", i.e. expanded with some randomness and structure, and then turned into a big integer value m in the 0..n-1 range (n being the modulus). That value is then raised to the power e (the public exponent) modulo n, yielding another integer in the 0..n-1 range. The result is encoded into bytes with what the RFC calls I2OSP (big-endian unsigned convention). For a 1024-bit RSA modulus, you will always get a 128-byte result.

Similarly, a RSA signature, for a 1024-bit key, always has length exactly 128 bytes.

Mandatory reminder: no, you are not "encrypting with the private key". The whole notion of "encrypting with the private key" is a flawed analogy, which works only for RSA, and actually does not work for RSA, precisely because it completely fails at taking padding into account. You are signing. And, indeed, you use the -sign command-line flag. RSA is two algorithms, which happen to share some common mathematical structure, but not all of it; things will be clearer if you keep thinking about RSA encryption and RSA signatures as distinct process.


My WiFi (with my own password) is connected to our office network. Is it secure? Is there a possibility that they can see my browsing history, media transfers, Skype sessions and even FaceTime?

Given that your IT staff are oblivious enough to allow to install your own WiFi access point, it's safe to assume they're not conducting advanced network analysis to figure out patterns in your encrypted Skype sessions or extract secrets from your HTTPS sessions.

Please note that the traffic is coming out of your laptop into the WiFi access point which is connected to your Office's router and then to the internet. The inbound traffic is coming from the Internet to your Office's router which will pass it to your access point and finally to your laptop. Whatever you're browsing or doing online can be logged and observed by their router.

Luckily for you, FaceTime and Skype encrypt their traffic. As for your other "media transfer" activities, if they're not over HTTPS then assume your employer knows about them and act accordingly.


Security testing plan template or example What does a security testing plan look like?

Can anyone point out a template for such a document or an example?


Has my server been compromised? --thanks everyone this has been resolved, see my answer below--

I created an Debian/OpenVPN server several months ago for private use but in the last two days I've noticed something extremely unsettling and strange.

It happens just with a single google search, but it can only be recreated while connected over OpenVPN.  I've already tried changing DNS servers/different computers/etc...

This is what happens:

I go to news.google.com , search for the string 'russia syria'.  When I click the link "Explore in Depth", a page of results comes up.

However, this page now seems to include links redirecting to "search.news.cn".

It only seems to do this for this particular search.

When I access the google page via wget on the server, it pulls down HTML including similar links.

The OpenVPN server is located in Canada, and I'm not in China.

Any ideas on what might be going on?

I've also run rkhunter which detected no threats

I can only assume that you have created an OpenVPN Server using a template or accessing said VPN Server through Proxy or the Server is infected, if they by any chance are affiliated by whatever unruly problem, that is the probable answer.

If you want to create an OpenVPN Server, I suggest a SeedBox which is in the Netherlands as to provide anonymity and no bandwith issues. (Assuming the OpenVPN is the fault)

If you want a proxy, don't try unless you have to as it is leakable.

If it is infected (which is most probable) then in that case you need to reset your VPS Server to Block 1 (New Install).


Once established, are sockets on localhost secure? Once a TCP socket has been established on localhost, and a connection made using accept, is it possible for a non-privileged user to intercept or modify bytes sent over this connection, or can this connection be guaranteed secure?

Operating systems in question are Windows and any modern variation on Unix.  Windows is the most important as I can use Unix domain sockets on other platforms.

I will use authentication (16 byte random key stored in a file) to ensure that malicious connections are immediately dropped.

You are safe regarding the described threat since in any case intercepting and altering network traffic at a low-level always requires the user to have elevated privileges on the local machine. An unprivileged end-user being unable intercept or tamper with them, you can therefore consider local connections as secure.

However, your question raises an interesting point I would-like to deepen a bit, especially if we lax a bit the "unprivileged end-user" perspective. Indeed, you mention Windows and Unix in your question, but the situation is quite different for these.

On Windows (and a few Unixes, namely Solaris and HP-UX), for optimization purposes (I guess) loopback communications do not go through a full IP stack. Therefore, under normal circumstances it is not possible to intercept, and even more so to alter local communication.

I say "under normal circumstances" because there is still the possibility to force the Windows host to route its local traffic through a nearby router, effectively forcing the data to travel through the full host's IP stack. This can be used to investigate a communication which could not be intercepted otherwise, however it would require to be administrator of the local machine to enforce such routing and the operation will not be discreet at all (route table with a new entry, the switch/router which will see unusual traffic, the application which will suddenly become very slow, etc.).

Alternatively, there is still the possibility to access raw socket communication and there are also a few commercial software offering IP sniffing on local interfaces. I'm not sure whether such solution can allow the communication to be altered and it seems it would require far more work anyway. You can find more information on the subject on the Wireshark website.

At the opposite, most Unix and Unix-like systems implement the loopback as any other network device, allowing to intercept the communication occurring on it as you would do with any other network interface, and thus allowing at least theorically the communication to be altered. I remind though that this would still require the potential attacker to have already acquired enough privileges on the host, at such point chances are that there are easier ways to exploit your application.


How to protect and detect DNS manipulations from browser side? After reading the question about a manipulated google analytics script I wonder how you would protect against this kind of attack.

What comes to mind is setting DNS IP fixed in network configuration or using a tunnel, but in both cases you would not detect the attack.

Is there a way to protect yourself and also be able to detect the attack?

I'm afraid we won't have a proper solution until we get everyone to use DNSSEC.

However, I predict that unless someone discovers a really critical flaw in DNS protocol forcing everyone to implement it, it will take many many years ☹ (just look at IPv6).

As a partial solution, you could have the DNS resolver set to a trusted DNS resolver which also signs all unsigned responses with its own key. That won't detect that the dns server provided on the DHCP response is malicious/poisoned, but -adding the appropiate code on the stub resolver- if all DNS queries where answered by the evil DNS server, you could notice that.


CORS REST API whitelist I have a REST API. I want to use this API from multiple web applications. I want to only allow requests from Whitelisted clients. My first point of call would be to add the necessary headers to the REST API Web Server (allowed domains) all good. But does this only whitelist clients that use browsers?. Is there any way to actually prevent scripted access to the API? By scripted access I mean PHP, JAVA, .NET or some other server side language making a web call directly to the REST API url, and of course since the request is manually constructed they can add any headers they want (ORIGIN etc), so could fake a domain request. I don't even think you need a script, a composed request from fiddler would achieve the same result.

Is it possible allow only requests from browsers (that pass the CORS config) and deny all others.

Ultimately is a REST API that enables CORS intrinsically insecure. Even though CORS headers give you a mechanism for whitelisting clients it is based on HTTP and manually constructed HTTP requests can easily circumvent this.

Granted a CORS config will prevent arbitrary embedding in website you don't want, so is that all its good for.

It has been a topic that has come up within my team a few times. These days we are writing more and more Web (REST) API kind of applications, which is kinda good cause functionality can be reused in a new application simply, but thoughts about security have been raised. Not security in data exposure, but only allowing access to the API based on allowed clients, that we whitelist.

TLDR: Nope, and if you think you need that, you're probably doing something wrong.

There is literally no possible way to prevent non-browser access to anything that is also exposed to browsers. As far as a server is concerned, a web browser is just a program that sends and receives HTTP (and related protocols) traffic. That's it. You can do that using curl, you can do that using any of the many sorts of WebRequest object available to different programming frameworks, you can do that by opening a simple TCP socket to the server and manually typing out the bytes to send (see the nc/ncat/netcat program). Any information that a browser normally provides - cookies, the User-Agent header, browser-specific HTTPS and URL quirks, HTTP Authorization, TLS client certificates, JavaScript parsing, etc. - can all be spoofed by some other program. That absolutely includes all the CORS headers and behaviors.

What you can do is require authentication. If the consumer of your web service is authenticated, who cares whether they are using a normal web browser, a screen reader for blind people, a mobile application, PHP web server, a telnet program on a Commodore 64, or tapping out the bits individually very quickly by semaphore?

In theory, cross-origin auth isn't that hard. You have to either send the Access-Control-Allow-Credentials: true CORS response header (which permits HTTP Authorization headers and cookies) or the Access-Control-Allow-Headers: <HEADERNAME> CORS response header (with a custom auth header). In either case, you also need to provide some way for a client to gain a valid authentication token (which could be via a web app, or a web service, or some other means; it could even be another CORS-enabled web service). Of course, you similarly have no way of preventing scripted access to the auth service, so anybody/anything with credentials can get a valid token and then use it.

What is your use case, here? Why are you trying to block scripted access? Why do you even expect this would work? I mean web browsers can run scripts, so there's nothing at all preventing a web browser from loading a page that contains JavaScript to access your web service, retrieve the results, and send them to a desktop or server application.

EDIT:

  Ultimately is a REST API that enables CORS intrinsically insecure

Either you don't understand what "secure" means, or you don't understand what web servers do. Web servers parse incoming HTTP requests (HTTP being a text-based protocol typically sent on TCP port 80, or wrapped inside a SSL/TLS stream sent to TCP port 443) and, based on the contents of the HTTP request, send back an HTTP response. Web servers are "inherently insecure" in the sense that, if you expose sensitive information on one, anybody who can connect to it over the network and can send the right string of bytes can get back that data. Of course, that's how approximately every network server for every protocol in the world operates, so...

As a side note, this isn't a CORS problem. If you don't allow CORS at all, it will make absolutely no difference to the type of "attacker" you're envisioning. CORS is a way to open a hole in a critical part of the browser security model (called "same-origin policy"), but it is utterly irrelevant to things that are not browsers.


For an HTTPS web application, is it worthwhile to encrypt the password before POSTing it, to keep a MITM attacker from harversting it? Our application has recently gone through penetration testing. The test found one critical security breach, which is essentially:
The problem:

Attacker sets up a WiFi spot.
User enters our site (which is HTTPS).
Using a tool like Cain, the attacker either redirects the user to HTTP, or keeps them in HTTPS with a spoofed certificate. (Either way, the user had to go through the "get me out of here"/"add exception" page)
User enters her user name and password.
The password is posted to the MITM attacker, who can see it. Apparently Cain has a feature to automatically harvest user name and passwords, and our password would be easily caught there.

Suggested solution
The report recommends encrypting or hashing the password in the client side (using JavaScript), in a way that cannot be replayed (e.g. using one-time pad / time stamp). They could not recommend a specific schema (they did mention client certificates, which might be unpractical for a large application).
Is is worthwhile encrypting or hashing the password before posting it? It is common practice?

This recommendation makes no sense:
The JavaScript code used to hash or encrypt the password has to be transferred to the client too. If the attacker is able to mount a man-in-the-middle attack he will be able to inspect the JavaScript code used for encryption too or might even replace it with something else (like no encryption).

Hashing instead of encryption makes even less sense, because this would only work if the server accepts the hashed password instead of the real password. In this case the attacker would not even need to know the password, he only needs to know the hash.

What might help would be client certificates because you cannot mount an SSL man-in-the-middle attack which preserves the client certificate (and a downgrade to plain HTTP would not send the certificate either). But, because you have to distribute the certificates to the clients first and make them install it inside the browser, this solution works only when you have few clients.

Apart from that: if the attacker is in the middle he might not need the password at all. All he needs is that the victim has logged in and then the attacker can take over the existing session.

It might also be useful to detect such a man-in-the-middle situation, so that you can inform the user and deny login from compromised networks. Some ideas to detect connection downgrades (that is http to attacker which than forwards it as https):

Check the method of the current location with JavaScript.
Create a secure cookie with JavaScript. It should only be send back if the site is served with https (that is no downgrade).
Include a script as HTTP which servers an image and check at the server side how the image was included. If it was included as HTTPS you can assume a HTTP downgrade attack because you've explicitly included it with HTTP. If it gets accessed with HTTP you have a downgrade attack too (but with a smarter attacker) or the browser does not care about mixed content.

And on how to detect man-in-the-middle with faked certificates:

Setup a second https site (with a different hostname) and construct an ajax request to this site in a way, which is not simple for the attacker to change to http (e.g. create URL dynamically). If the attacker just tries to MITM any site this ajax request will fail at least with some browsers, because the certificate is not trusted and the browser will only prompt the user for the primary certificates of a site.

Of course all of this only helps against an attacker which is not really determined to hack especially you, but just takes the easiest targets. In this case all you need to have to do is to be a bit harder to attack than the rest.


Security attacks on PHP web applications I know about following security attacks on php applications (html,php,js).

XSS

SQL Injection

CSFR

Session Hijacking /Fixation

Code Injection

Remote file injection
Should i know about any other or have i missed any?

Yes, there's definitely a lot more.  I suggest that you start by reading about the OWASP Top 10.  Every web developer needs to be familiar with each of those categories of threats.

In addition, here are some good introductions to web security:

An excellent overview for developers -- this should be a must-read for every programmer doing web development.
Web security tutorials at Google Code University

P.S. Some other categories to make sure you know about: path traversal, session management, secure password storage, clickjacking, phishing, site-wide SSL.


Why is no cloud allowed in this brief? I couldn't find a better place on StackExchange for this question, but please point me in the right direction if there is a better place for it.

My company is bidding for some work, and in the invitation to quote (under the Data Protection section) they state that there can be no "public or private cloud elements" to our solution.

This has baffled me - does anyone have any idea what they might have against using cloud servers (and, presumably, other products like a CDN)?

There are lots of reasons to be against cloud. First, cloud is a meaningless marketing phrase. Whenever you want to have a real technical discussion at least use IaaS, PaaS, SaaS, etc. so we have some idea of what you are actually talking about. Second, I won't store my stuff in the cloud. Especially after all of the revelations about the NSA compromising all of the cloud providers by sniffing their inter-datacenter connections etc. Third, you have no idea what security controls are being employed and I've never seen a single cloud provider that would actually tell you. There are many more...


Open ports with no services bound to them I have been wondering: if a port is open for inbound connections on the firewall yet there is no service bound to it, would that be considered a security vulnerability?

...would that be considered a security vulnerability?

No since there is no application behind that port to be exploited. (This port is actually called closed)

Do not mix up an unfiltered port with an open port. A unfiltered port is just a port which has no specific configuration (rule) in a firewall. It can still be either open or closed.


How to escape a cookie to cause split response? A website takes the following request and sets the "_Add_User" as a cookie in the response:

Request

GET /cgi-bin/webscr?cmd=_Add_User HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 Firefox/8.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Referer: https://www.example.com/myaccount/home

Response:

HTTP/1.1 200 OK
Server: Apache
X-Frame-Options: SAMEORIGIN
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Pragma: no-cache
Cache-Control: max-age=0, no-cache, no-store, must-revalidate
Pragma: no-cache
Content-Type: text/html; charset=UTF-8
DC: slc-a-origin-www-2.example.com
Content-Length: 55293
X-EdgeConnect-MidMile-RTT: 127
X-EdgeConnect-Origin-MEX-Latency: 1011
Date: Tue, 19 May 2015 15:47:18 GMT
Connection: keep-alive
Vary: Accept-Encoding
Set-Cookie: navcmd=_Add_User
Strict-Transport-Security: max-age=63072000

I can change "_Add_User" to "TEST" and cookie will be changed to "TEST".

Is it possible to escape the cookie and cause split response? Can I exploit this behavior in any way?

While the exact answer will depend on the technology you're using to process the request, the odds are that you can't split the header because modern frameworks have protection against response splitting.

To exploit you need to find or create a vulnerable server that somehow allows the user to inject a CRLF into a cookie. Frequently this would be done with the HTML encoding of %0D%0A but the exact encoding mechanism will vary depending on the vulnerability you have found. For example, if the server processes backslash escapes, \n\r would be appropriate.


Fake server certificate attack in SSL/TLS I have a server with a self-signed certificate server.crt that the client trusts by adding the self-created authority to his browser's trusted authorities. Now, upon connecting to the server's IP address through https://, the browser will say the connection is secure as the certificate shown is trusted. But how can the client be sure that the certificate that was shown is actually this specific self-signed server.crt, and not another certificate that was for example signed by Verisign?

Maybe my question comes down to this: How easy is it for an attacker to get a signature from the other (standard) trusted authorities in a browser?

Of course the client can always check manually in his browser which certificate was actually shown, but this seems like a step that shouldn't have to be done every time he connects to the server.

You can use HPKP to pin the public key of your self-created authority, thus after the first connection the client will refuse any certificate signed by another trusted CA.


How to securely load data to a database in vendor server such that vendor does not see raw data at all? Scenario: client will be uploading files with sensitive information to a vendor server for loading into a database. Due to the confidential nature of the files, the client does not want any archiving of the raw files in the vendor server. In fact, the client wants a solution wherein the vendor will not be able to see the raw files at all.

A proposed solution is for the client to encrypt the files and then a program on the vendor server side to handle:

decryption,
trigger of database upload, and then
deletion of the files.

Would you know of any technologies/techniques that would elegantly address this problem?

There is no point in sending up the files encrypted to then have the vendor decrypt and process them. If you don't want the vendor to access them then the only options are to not send them up in the first place or send them up encrypted without giving the vendors the keys.

If the vendor can decrypt the files then, by definition, they have full access to the files, and there is no way you can also not give them the files. Your goals are mutually contradictory.  Either send the vendor the files and trust them to abide by the terms of your business agreement, or send the files encrypted and don't give them the keys. There is literally no middle ground here.


WPA vulnerabilities for pentest As I am a network&IT enthusiast, I was asked by a friend to pentest his WPA network.

I'm wondering if there is anything else I can do beside a bruteforce attack, trying the KARMA attack on workstations and hoping for TKIP with QoS for exploiting it's DoS vulnerability?

A good piece of pen testing on wireless networks is around configurations. Is his network set up for mutual authentication? If not, could someone connecting be spoofed into connecting to a rogue access point?

Also have a read of this question re WPA and WPA2

In addition, carry out a site survey, just to see how far the signal goes - it might sound basic, but if it is easy for an attacker to connect from somewhere safe and unobtrusive, they will have more time to attempt an attack.


Download webcrawler output from Dirbuster Hello security experts,

I've made a wordlist to search some content on a specific webserver. DirBuster found a list of 500 images, is there a way to download them all on my computer.

Kind regards

A quick pipe into cut into xargs wget or any other simple scripting should do the trick. Google is very capable of helping with the sort of problems.


Any known protocol for establishing trust between an inherently untrustworthy source and a server without a 3rd party? Is there any kind of protocol, scheme, or theoretical paper out there that implements or examines the problem of establishing trust between two parties (communicating, listening) where the communicating party initiates contact and does not have a key/secret/password known by the listening listening party; but the listener needs to somehow verify that the communicating party is trustworthy in order to return some sensitive information without interrogating a 3rd party. Personally, this sounds near impossible, but I have tasked with investigating the feasibility. The problem we are trying to solve is provisioning devices into an environment where the devices need zero initial configuration other than being pointed at the proper remote endpoint.

Consider a situation where we have a Device (D) and a Server (S):

D sends initial Message M[0] to S containing D's alleged identity (name)
S verifies D identity using (???) and returns Key K to D
D uses K for all subsequent messages M[1..N-1].

The majority of this problem is in <2> where (???) occurs. Device may be as small as an 8-bit micro with limited storage options.

As usual, the problem is one of definition. Namely, what makes the device 'D' more "genuine" than a PC run by some ill-intentioned individual ? If you get down to it, you will say something like: device D is genuine because that's the true piece of tangible hardware, the accumulation of atoms which came out from the factory. This is fine as far as definition goes, but it does not map well to network configurations. From the point of view of the server S, there are only IP packets; zeros and ones; the server has no access whatsoever to the manifestation of the device in the physical world, but only to what it sends.

In the abstract world of networks, you are what you know. What allows a server S to recognize a remote device D as a "true device D" is that D can do things (i.e. compute things) that require some knowledge than only D possesses.

This means that you have mostly two ways out of your conundrum:

At some point in the building process where the device D is still on secure premises (e.g. in the factory), inject some secret key into the device. At that point, you can procedurally (with eye witnesses) make sure that only a true, genuine device will obtain such a secret key. The key can then be used later on by D to demonstrate that it is a real device.
Do the initial pairing between D and S under the physical control of a trusted (sworn) agent, who makes sure that the true device is used. In practice, the said agent would plug the device in his laptop computer, use some authentication mechanism to talk to S (as an authorized agent), and forward data in both directions.

I have seen (actually done) both kinds where devices were payment terminals, with a lot of money at stake, justifying the overhead of sworn agents. If your device is of the cheaper kind, then this overhead may unbearable to you. On the other hand, if you inject "sensitive information" in a cheap device, then maybe you are running to your doom: if the information is worthwhile, then some device owners will try to open it and extract the information. They do that for mere music and video files !


Do hashes contain any of the original file’s data? I am not a computer scientist, but would like to understand hashes such as SHA-256 more.
Am I right in believing that a hash is simply a statement that a file produced a specific output (the hash), and that it does not contain the original file’s data in any way? Therefore, if someone had the hash of a file, the only way that they could recreate the original file, even with all the computing power in the world, would be to recreate files themselves randomly until they had one with the same hash?

Or more simply:

A hash is a unique serial number for a unique computer file. The serial number contains nothing about the file. The only way to know anything about the file is to recreate it independently through trial and error, where the hash offers nothing but confirmation that the created file matches the original.

May contain, or may not. For example, taking the first letter of a message as a hash is possible. It may be a good hash algorithm for a particular purpose, but definitely it is not a good cryptographic hash.

So I will suppose that your question is about the cryptographic hash.

Ideal cryptographic hash algorithm have (beside other) these properties:

It is infeasible to generate a message from its hash value except by trying all possible messages.
A small change to a message should change the hash value so extensively that the new hash value appears uncorrelated with the old hash value.
It is infeasible to find two different messages with the same hash value.

(In real world, replace the word "infeasible" with "highly improbably".)

So, just the first of these properties shows that you are almost correct in your statement

  The only way to know anything about the file is to recreate it independently through trial and error, where the hash offers nothing but confirmation that the created file matches the original.

as there are some issues with it:

The set of all messages is infinite, so there is no possibility to perform an exhaustive search.
In the context of the blind searching the hash don't offer confirmation that the created file matches the original as there are inherently many and many collisions (same hashes for different messages).
It is highly improbable that you find even 1 file (message) with the given hash, so the "trial and error" method will give you nothing but errors.


HTTP Response Splitting Is this apart of a HTTP Response Splitting attack ? Here below is some code that gets put into a web browser after clearing the url while on the website

javascript: var xhr = new XMLHttpRequest(); xhr.open( "GET" , "google.com", false);
xhr.send(); document.write(xhr.getAllResponseHeaders());

and the out put of this code will look like something like this

Date: Fri, 18 Jan 2013 10:40:10 GMT Content-Encoding: gzip Transfer-Encoding: chunked
Connection: close Server: Apache/2.2.3 (Red Hat) Vary: Cookie,Accept-Language,
Accept-EncodingContent-Language: en-us Content-Type: text/html; charset=utf-8

If using more AJAX and JavaScript and setting header

setRequestHeader(header,value)

is this a security risk for all browsers on every web application ?

HTTP response splitting attacks work when user data (including newlines) can be injected into HTTP headers.

For example, let's take this response:

 HTTP/1.1 200 OK
 Date: Mon, 23 May 2005 22:38:34 GMT
 Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
 Last-Modified: Wed, 09 Jan 2013 23:11:55 GMT
 Accept-Ranges:  none
 Content-Length: 1234
 Connection: close
 Content-Type: text/html; charset=UTF-8
 Cookie: test=123&username=Polynomial

 <html>
 ...

Now let's assume I can change my username arbitrarily, and include CRLF (newlines) in the field. I could then inject my own content into the page.

For example, I might set my username to Polynomial\r\n\r\n<script>alert(document.cookie)</script>, which would result in the following HTTP response:

 HTTP/1.1 200 OK
 Date: Mon, 23 May 2005 22:38:34 GMT
 Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
 Last-Modified: Wed, 09 Jan 2013 23:11:55 GMT
 Accept-Ranges:  none
 Content-Length: 1234
 Connection: close
 Content-Type: text/html; charset=UTF-8
 Cookie: test=123&username=Polynomial

 <script>alert(document.cookie)</script>
 <html>
 ...

As you can see, the JavaScript was injected into the page. This is a form of XSS / DOM injection via the splitting attack.

Including user data in a request isn't quite as bad, since the server should treat user requests as untrusted anyway. As such, AJAX requests shouldn't be an issue. This becomes even less of a problem when you consider the fact that most major browsers have disabled or limited the javascript: handler in the URL bar, in order to limit the potential for attacks.


Is it possible to catch public key certificate in network and hack the public key so you could pretend that you were someone else? I am very confused about the way of sending the CA's certificate to another party. What if some hacker is monitoring the network in the moment you send a certificate to other party and hacks the public key from that certificate? He could then pretend that he is you and encrypt the messages using that public key...If anybody can explain a matter of this issue, I would be very grateful!

The public key is contained in the certificate which gets sent from the server to the client inside the TLS handshake, so that the client can check if it speaks to the correct server to prevent man in the middle attacks. The certificate is signed by the issuer CA. This signature also includes the public key.

If the public key gets replaced by an attacker the signature of the certificate will therefore be invalid. In this case certificate validation fails and the TLS handshake will be aborted. This means the attacker not also needs to replace the public key but also needs to recreate the signature of the certificate so that it gets valid again. But, to do this he would need to have the private key of a CA which is trusted by the client, i.e. needs to have either compromised such a CA to get to the private key or needs to have compromised the client to install a new trusted CA.


Security of cross-origin XMLHttpRequest Javascript I am building a Chrome extension that will be making cross origin "get" and "post" requests to a few third party websites. I have been researching this process for hours and I am becoming increasingly concerned with security.

I need to get the "add to bag" URL info and post user information to that page to fill out the required fields. My Chrome extension has a background JavaScript page, a popup JavaScript page, a HTML page with user info, and a popup HTML page. The HTTP request will occur on the background JavaScript page and send a cross origin request to the website that user is currently visiting.

I am worried about the security when posting user data and the possibility of retrieving malicious info when I use the get request, to get data from the page, possibly an image, and the add to bag URL. I have read about escaping; but I am not really sure how this process works. Do I simply use encodeuricomponent()?

function httpGetAsync(theUrl, callback){
    var xmlHttp = new XMLHttpRequest();
    xmlHttp.onreadystatechange = function() {
        if (xmlHttp.readyState == 4 && xmlHttp.status == 200)
            var resp = encodeURIComponent(xmlHttp.responseText)
            callback(resp);
    }
    xmlHttp.open("GET", theUrl, true);
};

I found this website covering how to prevent XSS attacks: XSS (Cross Site Scripting) Prevention Cheat Sheet

Should I use JsonP coupled with an escaping function such as, this function nestled under the if statement?

function (xmlHttp) {
    // function to escape data? not sure how to do this
    var resp = encodeURIComponent(xmlHttp.responseText)
    callback(resp);
}

The developers Chrome website states that:

document.getElementById("resp").innerText = xhr.responseText;
or: resp = JSON.parse(xhr.responseText);

are safe practices and to simply avoid using .innerhtml.

Any advice or suggested reading material for further research will help me out immensely.

Don't use encodeuricomponent - this is for percent encoding values for insertion into URIs (as suggested by its name).

Data itself cannot be malicious. It can only be "malicious" in the context where it is used. If all you are doing is displaying it on the page, go with the recommendation of setting text rather than HTML, as any characters with special meaning will be properly encoded using this property.

Use textContent rather than innerText as the latter is specific to Internet Explorer, with a few other browsers tagging along rather than a web standard.

JSONP is less secure than CORS, as you have to trust that the external domain is not injecting malicious script into your site (whether the external domain is malicious or has been itself compromised).


Can someone steal money from my bank account if they know my IBAN and personal details? To deposit money into your account, some websites require that you provide them with a lot of details about your bank account: name, complete address and IBAN which includes your account number and identifies the exact bank.

Can a skilled cracker use this information to steal money from an account? How safe is it to provide these details?

This question is likely to be country-specific.  In the US, an account number is generally not enough to steal money from someone's account.  This is fortunate, because every time you write a check or make a bank payment to someone, they receive your account number.

However, learning someone's the bank account number is enough to learn their account balance.  There is an attack that is not widely known:

Most banks have a phone number that merchants can call and, via an automated voice response system, learn whether a particular account has enough money that a check for a particular amount will clear.  Basically, you just call up, hit a few digits to go through the phone tree to the merchant check verification option, then type in the account number and the amount, and the phone system will respond with whether the account balance is at least as much as the amount you've provided.

This allows an attacker who knows your account number to learn your bank account balance, by using binary search.  This is a confidentiality breach that is not widely known.

If this bothers you, you may be able to protect your own account against this by calling up your bank and asking them to put a fraud alert on your account.  At least for my own bank, when the bank does this, it disables the merchant check verification service for your bank account.


Why shouldn't a certificate's Common Name be used for identification? I understand that using a Subject Alternative Name is to be used for identification, and using Common Name has been deprecated under RFC 2818.

I'm trying to understand the logic behind that decision. Why shouldn't a certificate's Common Name be used for identification?

According to this it's because the usage of Common Name is ambiguous, while Subject Alternative Name is unambiguous. Due to the ambiguity of its usage, checking it is more complicated and has resulted in security bugs in the past.


How to figure out which open ports or services are insecure? We have around one thousand machines on internet. We do port scanning with nmap, and find many ports open on these machines. Sometime we found administrative website using HTTP instead of HTTPS, we would block it.

But there are many other ports open, and we have no idea what services they are. Is there any way to figure out which are insecure?

Step one - close all the ports you do not have an explicit business need for!

All open ports add potential insecurity - a closed port is a safe port.

If you don't know why a port is open, I would be worried - find out what service is running on it. If there is no business need, shut it down! If you can't find out what service it is, shut it down!

There are services lists for the most common services which run on particular ports, but really, anything can run on any port (pretty much) so you need to have a register detailing the port, the service, the business reason/function, the owner, the date it was implemented.

If you can't shut down services, use a firewall to explicitly block access to all but the services you do need.

Once you have done that, make sure that all your services are patched. One of the biggest sources of vulnerabilities is unpatched services/applications. Get yourself up to date now!


What are the risk implications of not verifying referer header on login form? Imagine a generic web application with a login form to access the application. Regardless of how the actual authentication is performed, what are the implications of not checking the referer header to verify the submit request is coming from within the same application/domain/approved URLs?

Another way to think about this is if you drop the referer header check and are checking something that verifies its coming from a known source. What are the implications of not checking the form data source?

Specifically in a passive scenario, e.g. purely browser based.

The biggest implication I see is that I can submit the credentials from another site and log in successfully.

But what risks are there in this? I realize it depends on each application and the threat models for it, but can this be generalized?

A CSRF attack tries to exploit "the trust that a site has in a user's browser" (so says the Wikipedia page, and it is well said). It is about the server accepting a request from the client, on virtue of the request coming with some authentication characteristic which makes the server believe that it comes from the genuine user (which it does) and under the conscious control of the genuine user (which is false). The "authentication characteristic" would classically be a cookie value (acceptable for the server), or HTTPS with certificate-based client authentication.

For a login page, the server does not trust the request from the client. That's the point of a login page: to initialize trust. The login page expects a login and a password precisely because there won't be anything that the request can come with, which will make the server happier and distract it from its intended action, which is to verify the login+password pair. As such, CSRF attacks don't apply to this page.

You can still check the Referer field to check for "fishy business" (if it is absent or wrong, then something is definitely amiss), but it won't really change the security.


ASN.1 BIT STRING can be any length, so the DER/BER encoding rounds up to a multiple of 8 (an integral number of octets) and prefixes one octet containing the count of added padding bits. Since this BIT STRING value is itself a DER encoding and thus already a multiple of 8 bits, the padding count is 00.

ASN.1 INTEGER is signed, and the DER/BER encoding is two's complement big-endian. Your N value 9BFC...5307 has a magnitude that is an exact multiple of 8 bits; this is common since most RSA moduli are deliberately chosen to make their size in bits a power of 2 higher than 23, or a small multiple thereof, in your case 512. For this to be represented as a signed number a 0-bit must be prefixed, and since the encoding must be integral octets in fact we prefix a full 00 octet.

Back in the 1990s when RSADSI established a series of Public Key Cryptographic Standards (PKCS) using a good deal of ASN.1, Burt Kaliski wrote a "Layman's Guide" that covered a lot of useful details about ASN.1 quickly; see especially 5.4 and 5.7 in this apparently definitive reference or this more convenient but uncertainly permanent one.


How to convert my cert chain to PFX without a password I am trying to enable an Azure Front Door instance on the front of my website using my EV cert (Extended Validation Certificate).

However, from Azure Front Door Cert Instructions,

  Azure Front Door Service currently only supports certificates uploaded with a PFX without a password.

I have this cert chain in .cer format and .pfx format with a password, how do I convert it in to the necessary format?

I'm not sure what Azure means by 'without a password'. OpenSSL can create a PKCS12 with the contents unencrypted, but it still has a PBMAC which uses a password -- but which a reader that violates the standard can ignore. If that is close enough, if you have the separate key and cert both in PEM:

 openssl pkcs12 -export -keypbe NONE -certpbe NONE -in cert.pem -inkey key.pem -out out.p12
 # if you need to add chain cert(s), see the man page or ask further

otherwise since you have an existing pfx:

 openssl pkcs12 -in old.pfx -nodes | openssl pkcs12 -export -keypbe NONE -certpbe NONE -out new.p12


Problem with Snort rule alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"Get2 method"; flow: to_server, established; dsize: >20; sid:1000006; priority: 15)

Snort does not generate any alert, whereas when I write the following rule:

alert tcp $HOME_NET any -> $EXTERNAL_NET 80 (msg:"Get1 method"; flow: to_server, established; dsize: <20; sid:1000005; priority: 15)

it does generate alert

As Snort manual is claiming:

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

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


Is there any way to alter a caller's voice just enough to make voice recognition impossible? I did search and found this post:

Is it possible to identify mobile phone user with voice recognition

It does not answer my question, however.

Is there any way to alter a person's voice just enough to make the cell call unrecognizable with voice recognition techniques?

Sure. @VipulNair is right. There is a lot of such software.

Regarding "to make voice recognition impossible?":
It depends on the quality of the voice changer and the quality of the voice recognition software. The simple voice recognition software calculates a few statistical patterns and is easy to foul.


What makes TPM chip Endorsement Key Non-migratable? I know that the endorsement key (EK) of TPM is stored in non-volatile memory (e.g. EEPROM), which is non-migratable to ouside the TPM. Like EK, the Storage Root Key (SRK) is also non-migratable.

What makes them non-migratable? It is achieved by some protective code or the design of the internal IC structure?

Careful, the terminology is really getting fishy here.

I know the mistake is an honest one, but it doesn't make sense to even ask about the migratability of these keys.

The Endorsement Key is not "non-migratable".  The idea of migration doesn't even apply to this keys.  It is special.  Its private portion is completely inaccessible outside of the TPM.  Discussing its candidacy for migration is patently incorrect, imho.

That said, your question becomes ambiguous.

If you are asking "why can't I transfer the EK to another TPM", that is enforced by the TPM spec from TCG, the design abstractly considers this key as the root identity of a discrete chip.

If you are asking "how does a TPM keep this special key safe", then the other answers addressed this; the implementation is vendor specific.  A physical IC TPM will probably be designed to physically secure the key in some way, and a software TPM will obviously have (well tested I hope) code that doesn't provide a code-path to output the key.

EDIT: I have edited my answer above to only discuss the EK.  Previously I included the SRK also in those terms.  However in A Practical Guide to Trusted Computing, chapter 3, the authors do discuss the SRK in terms of being non-migrateble.  They do not, however, discuss the EK in these terms, suggesting, as I propose, that this key is unique.


How do I protect myself from ARP spoofing as a client? Network topology:

Public AP <-WiFi-> Raspberry Pi (NAT #1) <-Ethernet-> WiFi AP (NAT #2) <-WiFi-> Clients

Situation: I'm connecting to a dormitory access point that's shared with a lot of other people. When the going gets tough, I do an ARP-spoof attack on the network using an Android app called "NetCut", or wifikill/netcut on Linux.

Lately, I've noticed someone else has apparently learned how to do such an attack.

As a client, with no access to the router (but root access on my own Linux machine), how do I circumvent an ARP spoof done by someone greedy?

Possible (but not applicable) duplicates:

Admin access to router: How to figure out that someone is ARP spoofing me and what to do against it?
This admin has full access to their router: arp spoofing protection on LAN
Possibly outdated information: How to tell if you're being ARP poisoned?
Does not seem applicable: How should this system be protected from ARP spoofing?
Describes attack, not defense: Arp Spoofing Causing Dropped Connections
Describes attack, not defense: ARP poisoning attack consequences
Windows: How to prevent an arp poisoning attack (from the client's POV)

You could disable ARP completely:
(assuming your network device is eth0)
ip link set dev eth0 arp off
Then, you will need to manually add static ARP entities to any host you want to talk to using the arp command.

However, the attacker could still spoof your address, such that the gateway or other hosts thinks that the attacker is you.


Using RSA-SHA as/instead HMAC in OpenVPN? While reading the manual of OpenVPN 2.3, I came across the --auth alg option. The manual says:

  Authenticate packets with HMAC using message digest algorithm alg. (The default is SHA1 ). HMAC is a commonly used message authentication algorithm (MAC) that uses a data string, a secure hash algorithm, and a key, to produce a digital signature.

From what I understand, HMAC is just a preferred way of making a MAC from a hash function, while potentially avoiding the length-extension properties of some hash functions.

So the algorithm specified in the --auth option should be a hash function.

Now if I do openvpn --show-digests to know what algorithms I can use with the --auth option I got also entries like:

RSA-SHA, DSA-SHA, ECDSA-WITH-SHA1... etc.

These are the digital signature algorithms, why they are supposed to be used in the HMAC? To get sort of "double authentication"? Isn't it a bit of an overkill?

Or does it mean in this case the HMAC is actually replaced by digital signature to achive authentication? If this is the case, what is better to use in terms of security?

Looking at OpenVPN's source code, this appears to be a cosmetic quirk of OpenSSL.

When using --show-digests, OpenVPN calls OpenSSL's EVP_get_digestbynid() with, as parameter, all integers from 0 to 999. For some of these values, EVP_get_digestbynid() returns a non-NULL pointer that identifies the corresponding hash function implementation, and then OpenVPN prints out the corresponding name.

It so happens that with ID = 64, you get a structure that implements SHA-1, and the name corresponding to the ID value 64 is "SHA1". However, with ID = 65, you get the exact same structure (same pointer in RAM), i.e. the very same implementation of SHA-1. But the name corresponding to the ID value 65 is "RSA-SHA1".

When you use --auth, the same applies: OpenVPN uses the EVP_get_digestbyname() on the provided string. With "SHA1", you get a pointer to the structure that implements SHA-1. With "RSA-SHA1", you again get the exact same pointer value.

In other words, you see some "alternate names" with some RSA or ECDSA but that's just a consequence of how OpenSSL names things, and if you use these names you just obtain the underlying hash function (to be used in HMAC) and nothing more. Thus, --auth SHA1 and --auth RSA-SHA1 are completely equivalent.


How does a debit/credit card reader verify the PIN so quickly? I understand that the associated PIN for a given card is not stored on the card itself in any way. So I am wondering then, when I use my cards how does it seem to be able to verify the PIN quite quickly and yet sometimes take a long time to complete the transaction. I always assumed the delay was in getting a connection with the financial servers, but the timing seems to indicate otherwise. Is the PIN verified without access to those servers?

In fact, in many cases, the PIN is in the card. There are a lot of possible situations, not all of them well documented, and they are subject to evolution over time.

Some cards do not have the PIN code on the card in any way; at least, that was the case for Amex cards about 15 years ago, because you could change the PIN over a phone call.

Some cards have an encrypted copy of the PIN on the magnetic stripe. This can be decrypted into some secured facilities that have a copy of the relevant decryption key; an ATM or selling point could maintain a live connection to one of these facilities, and still take some time to contact the bank that actually manages the account.

Smart cards, with a chip, know the PIN code and can verify it. That's the main point of smart cards: the chip is tamper-resistant, thus can hold secrets; these secrets can be unlocked through authentication with a PIN code; the chip will autolock itself if too many wrong PIN values are presented. When the card is a smart card, PIN verification goes as fast as the card chip can do it, normally a fraction of a second.

(A tamper-resistant smart card does not prevent the overall protocol from doing something stupid which nullifies security; e.g., see this recent article that describes an actual case of fraud due to a protocol flaw.)


Parsing a PKCS7 detached signature hash I'm trying to manually verify signatures of Apple iOS Passbook files, which are PKCS #7 detached signatures of the RSA key of the Apple developer who created the file.

Which means there's a file "signature" which is the detached signature of a "manifest.json" file. I'm using the novelty "Titanic boarding pass" pkpass file from http://www.flonsolutions.com/fantastic_voyages.html for testing. Doing:

openssl smime -verify -in signature -content manifest.json -inform der -noverify

comes back with success, so I know the signature should be valid. Now, parsing apart the signature file, I can have decoded the DER-encoded ASN.1 data and shows that the attribute being signed is a SHA1 digest of the message, resulting in 733538fde88843c7ad24fb71674dbdd372df7b4d1. Running openssl sha1 manifest.json shows that indeed the SHA1 of that file is indeed 7335...b4d1.

Now, parsing out the SignerInfo bits of signature, I can grab the OctetString that's the RSA encryption of their signature:

BC C5 F9 F2 53 FD 2C 13 EA CE 64 BB 89 85 60 82 78 63 5B 04 FA F8 BF 7E 2A 6C 20
5D C3 C8 E8 8A 2F E3 4D B9 8E 1C A1 42 DF 2B 46 89 76 63 0B 8A DD E5 8A 69 4E D0
CF 3F E7 36 1E F8 7F 49 0D 27 EC 0F 73 76 5D 62 A1 4E 8A 43 AB EC ED 2E CD E7 69
3F AD 32 48 0A 79 52 DB 36 5B 61 94 71 3F B3 09 1E 80 17 94 31 06 AF E6 A3 A5 A0
D6 B7 71 31 ED 4C 6F C1 5C B6 4B 79 E5 7A BA BC 1D AD BB D2 F7 39 05 16 73 2C AE
74 E3 9C 4F 7E A7 B1 90 38 FC 92 78 9F 70 C0 D0 94 83 83 EC 01 F4 B6 16 36 4B EE
BC BA DD AC 23 64 4B C2 93 21 9E 9B 21 64 9E 7C 1B 72 87 0B C1 7D 9C 6A 9B AA AB
36 67 F8 7C 7B 8D 9E 88 FC 95 C8 29 57 8B EB B9 5C F6 AB 59 64 CA 87 ED DE 50 BA
67 C0 26 F8 5B FD 47 10 B0 A6 4E D8 D6 F0 E9 A0 DE 2B 6B D4 84 2A 91 A6 A7 27 22
CE D6 5F D2 C7 87 56 A4 E6 E4 D6 D3 C9

Using the certificate's Public Key from earlier in the signature file:

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAzEjQiB/QgOWX2QF6CGtCiq1ZDyRzJJKJ
4ZW6cuF2MdtOi4If+IhTHcVkdeJ+/cacuRFcscNOXODjriCbAbmTVYTFx290n4vQ1qvPuu3/T41f
4dZHvAM9dmUHuN7M/f/SyGWJiFSYj3VY7S+jyH5zvskGp84YNkHB/Uky3ZFZElOwoOltRNVL25Rw
52nIMVrqO+Cyn2T2LSkk/6yjSll46TyjYuTDEev4XvYhIQBfbraP9rUabRkf1k0EuXl7qM2GeKGM
vq9sQwMRPVFFM2Fa/8xUeA4D/4AWR4S4shuVUxWOx8bq57RNRDogTr4rotaAOyDACu0aS37fWJmQ
zExr3QIDAQAB
-----END PUBLIC KEY-----

I can successfully decode the RSA encryption and get a result. The result of the decryption is another ASN.1 DER-encoded string, which is:

30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14 5B AC 45 51 B9 A5 51 68 28 89
51 59 1F 62 31 9B A7 15 50 CB

Parsing that out, it's indicating that 5bac4551b9a55168288951591f62319ba71550cb is the SHA1 hash of something. But that's not the SHA1 of manifest.json (5bac...50cb !=
7335...b4d1).

So, what am I supposed to be comparing that decrypted SHA1 to? I know that the owner of that certificate encrypted this particular DER-encoded string, but I don't see how they match. What part of the RSA/PKCS7 process am I missing here?

The digest calculation is described in CMS (the new name for PKCS#7), section 5.4. Namely, when there are signed attributes, then what is signed is an encoding of the set of attributes; since one of the attributes contains the hash of the data file on which the signature object applies, this signature extends to the data file. See this paragraph:

  A separate encoding
     of the signedAttrs field is performed for message digest calculation.
     The IMPLICIT [0] tag in the signedAttrs is not used for the DER
     encoding, rather an EXPLICIT SET OF tag is used.  That is, the DER
     encoding of the EXPLICIT SET OF tag, rather than of the IMPLICIT [0]
     tag, MUST be included in the message digest calculation along with
     the length and content octets of the SignedAttributes value.

so the hash should be computed over the complete encoding of the SignedAttributes value, except that you replace the first byte (which should be 0xA0) with the byte which encodes a universal tag SET OF (that's 0x31, if I remember correctly).


How secure is the apt-get install command against man in the middle attacks I think the title says everything,
how secure is it to use apt-get in a network with an attacker who injects his own packets and blocks the original packets (man in the middle).

All of packages within the Ubuntu and Debian apt repositories are signed using SecureApt.  Asymmetric cryptography is very secure and its highly unlikely that you will be compromised in this way.   3rd party repositories are hit and miss, they may or may not be singed.  If they aren't signed,  apt should throw a warning informing you that you are installing an unsigned package.  But if its from a 3rd party you could also just be installing a backdoor,  so make sure you trust that source.

On a side note,  people don't really "inject packets" to perform MITM.  They are going to use something like DNS cache poisoning or ARP table poisoning so that you download the package from an HTTP server that they control.  This isn't an injection attack.