Security of port forwarding when the target is turned off I recently set up a server from an old computer case. I use docker to install and use different services on different ports and I would like to access some services from outside of my house.

I have a domain from namecheap and I set up dynamic dns which successfully sends my public IP to my domain periodically. Here’s the docker.

To reach different services on different ports with subdomains, I set up an nginx reverse proxy server with the help of a docker container.
I only forwarded port 80 and port 443 from my router.

Now my setup works like a charm. Let’s say I want to reach service1 which is on port 2525, I go to service1.mydomain.com and my nginx server redirects me to localhost:2525

Here is where my concerns started; I shut down the server at nights. Even though it is shut down, when I ping service1.mydomain.com, it shows my home’s IP address. It doesn’t lead to anywhere on the browser, however, it can still be pinged.

What problems can occur with this setup?
Or does any problem occur at all?
Can someone reach into my home network?

[Note that I use a standard router with low-level firewall. And although my IP is not static (I didn’t buy), it hasn’t changed in months as I observed.]

Even though [the server] is shut down, when I ping
  service1.mydomain.com, it shows my home’s IP address.

Your router is the actual device using your public IP address, and it will respond when the server's name is pinged (since the server's name resolves to the router's public IP address).

If you turn off your router and manage some way to test without using the router to reach the Internet, you'll find your IP no longer responds to ping.


Need an explanation of Cross-Site Flashing? I found this - can anyone provide me examples of how these issues are exploited?

Flash is jailed by the some-origin policy and can only act upon a site that loads the flash applet with scripting access enabled.

However,  flash can become a vector for XSS.  The demo above lists various XSS vectors.  So for example in the extremely unlikely condition where you are loading a flash applet where the attacker can control the loadMovieNumVar variable then an attacker could execute JavaScript in the context of the site by setting this variable to javascript:alert('gotcha!').

XSS is extremely common and there are many ways that this attack can manifest. Flash based XSS is one way,  and its also extremely uncommon.


What are best practices for letting employees use a web app, but never actually know the password? That is, is it possible with a Single-Sign-On tool to give employee "Joe Smith" access to app "SocialMedia App1" for him to do this job. But when Joe leaves the company, can I have complete confidence he does not have the password and there is no need to change it?

Generally, when a user departs, you can never have complete confidence they don't have passwords or other confidential information saved.  As a result, your offboarding process needs to have controls for all the contingencies.

There are various systems (e.g. the proprietary OneLogin) that allow you to integrate a corporate identity management service (e.g. Active Directory) with logins to social media sites/other web applications.   However, this works similar to LastPass in that it stores a randomly-generated password in a vault; and this password can be intercepted.

The issue is that it is always technically possible, if the user is an administrator to the computer and has access to some technical savvy, to obtain the password.

There are ways to mitigate this: e.g. enable login notifications on Facebook and two-factor authentication.   Only setup a non-rooted phone with the correct 2FA token.  Still, the user might take steps to migrate the 2FA token to another device, so you can't be 100% confident this system will work.

In the end, the best practice will always be to reset passwords for any and all accounts that the former employee had access to. If the app is directly integrated with a directory service you can be certain that when the directory account is disabled access is denied (e.g. Google+ using OAuth) -- but, if there's separate logins to external sites those will always need to be changed. Even if you're 99% confident that they don't have the password or they won't be logging in, the 1% exception is surely motivation enough to lock things down.


Should I ever sign a project's PGP key? If I want to verify a the signatures on a project whose packages I download & verify frequently, would it be reasonable to for me to sign that project's signing key?

Currently, I verify the signature using GPG, I then have to manually check the signature fingerprint against the fingerprint published online. Is this a correct use case for signing a key? I have no friends in the web of trust through which I can trust these keys.

Of course, I've never met anyone in person to verify the key, but I've verified several signatures of the same key over a period of a couple of weeks. I think I can be reasonably certain that the signing key is theirs.

If you trust your projects downloads and their signature, you can reflect this trust by signing the project's PGP key. So, later you'll know that you trusted this key.

If, however, you're not sure that you trust this project key, don't sign it.

Whether you trust the project's key or not is your choice alone. Using PGP is just a way to keep a trace of your trust.


Bypass PHP strtoupper() to perform SQL-injection on MySQL database? I encountered a particularly weird situation where I have an SQL Injection vulnerability in the ORDER BY clause. The query is forged on backend and the injection payload is converted to upper case with the strtoupper() PHP function as can be seen bellow:

$sql="select something from table order by ".strtoupper($injection);

The problem is that I can extract from information_schema and variable names but I can't extract data from other tables because the table name in the select query is defined in lowercase.

For example:

SELECT * FROM mysql.user   -- Will work.
SELECT * FROM MYSQL.USER   -- Cannot find MYSQL.USER.

Apparently, INFROMATION_SCHEMA is the same thing as information_schema. But this does not apply to the other tables as well.

To extract data I used the following injection:

if(1=1,0,~0*2)

If the query returns true nothing happens, when is FALSE a generic message is revealed.

The MySQL server version is 5.7.19, the user is running as root but as I'v seen in the latest updates the server must be started with a special argument in order to use load_file or INTO OUTFILE statements.

I managed to sort of "bypass" the strtoupper() function by providing Cyrillic input characters but the MySQL does not recognize the table name because it's in Cyrillic.

Any advice on how to bypass this?

Use the sql CHAR() fonction for every character that needs to be lower case, put the whole request in a string using concat.

SET @T = CONCAT(CHAR(109),  CHAR(121),  [...]);
PREPARE A FROM @T;
EXECUTE A;
DEALLOCATE PREPARE A;

I tested it and it works well.

edit: showed the wrapping in proc


Does it really improve a password if at least one character of each group (a-z,A-Z,0-9) is included? Many password policies required at least one character of each group (upper case, lower case, symbols, and numbers) in the password.

Does this really improve a passwords strength?

e.g.: Is (number included)

  3i{M?tofQPI.'C`dfmSK

really stronger than  (no number)

  ni{M?tofQPI.'C`dfmSK

Please try to keep answers simple. As the question may indicate, I'm not really skilled in cryptographic science.

For the people who just pick the simplest allowable password, this is indeed an improvement on entropy, such as password to pa55word (the first being about as bad as you can get, the second being significantly better yet still unacceptably simple).  Password1 is ten times as complex as Password, but only because it is longer, though Passworda would be 26 times as complex as the original Password.

For the people who pick secure passwords, this is a hindrance.  It forces passwords like ni{M?tofQPI.'C\`dfmSK to become 3i{M?tofQPI.'C\`dfmSK.  From a sheer entropy perspective, there are fewer possibilities in digits (10) than in lowercase (26), uppercase (26), or special characters (~32).  That n… password arguably* has 2.6 times as much entropy as the 3… password (26∕10).

Consider a more strict password scheme:  you must have one uppercase, one digit, and one special character.  An attacker therefore knows that there are a very large number of passwords that are impossible and therefore do not need to be tested in a brute force attack.

Using psychology, the attacker will also prioritize the first character as being uppercase and the last character as being either a digit or a special character, meaning that 1pa*sswoRd is much stronger than Password1* (but again, unacceptably simple).  This is called "password topology" (learn more from Rick Redman's PathWell: Password Topology research).

* Calculating password entropy is very very difficult and nobody does it correctly (it's impossible to do "correctly" unless you're talking about measuring an automatic password generator).  One must assume the worst-case scenario, that your password generation scheme is fully known to the attacker, since you cannot rely on security through obscurity.  I've got my own way of calculating entropy that I like better than others I've seen, but it's imperfect as well.  The best password generation advice is therefore to make a very long passcode that meets most recommended password guidelines even ignoring the first and last characters of the code.

When changing e.g. password to Password, you're doubling the entropy because it's the most common location to make uppercase (and upper-vs-lower has two options), whereas changing password to pAssword at least implies that the uppercase could be anywhere, instead increasing the complexity by 16x in this example (eight characters times two case possibilities).

Don't forget words.  A word is worth 2-3 "random characters" and no more.  Super obscure words (especially from rarer languages) may be worth up to four characters (see my entropy link above), but it's better to be conservative in your estimate.  I say if it's in a spelling dictionary for any language you're known to speak, it's worth 2.  Any other nontrivial word is worth 3.  Password and other common passwords (even 1qaz2wsx; look at your keyboard) are worth 1, so Password1 is about as secure as K%.  Since attackers can comb through your drives, any "word" found anywhere on your computer (excluding dictionaries) is worth 2 characters at most.

Random is hard for humans to come up with and harder still to remember (and, contrary to human intuition, arbitrary/obscure/clever is not "random").  That's why password managers offer to do it for you, creating a system in which you only ever need to remember one big fat password which you could e.g. memorize half of and stick the other half in your wallet.


Why do password creation/login screens hide the typed password? I realize that the concept behind obscuring a password on a screen is to prevent someone "shoulder surfing" behind a user and seeing the typed in password. As a fairly good typist I have no problems with dealing with this, but this causes a lot of pain for people I know who are very slow typists (Dilbert strip).

Can't we just assume that people entering a password are checking to see if anyone is trying to look at their screen before they enter a password? Or is there some other reason for obscuring a screen password?

The primary protection provided by password masking is against shoulder surfing, as you suggest. Typing speeds are a factor, but a reality is that screens could be captured by video recording devices as well (which exposes passwords to typed on mobile phones, where each character is visible for a few hundred milliseconds before being masked). As the exact environment around a user is not known, it makes sense to have a default masked view, with an option to preview as suggested by  @William Mariager. This is also true in case of shared screens, projectors... Some simplistic malicious software do perform periodic image/video screengrabs, which is also defended by password masking.

Hence we can't assume that people can always check to see if their screen is obscured.

But, another reason for doing this now is historical-- users are now so used to seeing masked passwords that websites using unmasked passwords are perceived to be insecure
(Source). The masking also informs all users that the information being entered is sensitive.

Also read: Schneier about password masking

Studies that argue against password masking: [1][2]


Challenges in Information security management Information security management involves challenges that are
  essentially unique due to the combination of technical and
  organizational constraints. Identify two such challenges and discuss
  in depth how these can affect the way information security management
  is performed within an organization.

I have an essay to write on the above. Can anyone spare some ideas on how I can tackle this? In the terms of technical and organizational constraints?

I think technical limitation refers to things that you have to do that are system based, but that you are unable to achieve due to some reason?

Organisation should be like, for example, your CEO requesting for information that he has no access to and demands that he has access granted?

Please enlighten me if I'm wrong.

In my opinion the main problem is that most of the technical solutions reduce the comfort or efficiency of the users. So you have a strong organisational support from the top-level managment. You can only reach good acceptance of information security if all users understand the importance of information security.


Outlook was redirected to the server clblgn.sceur.ch to get new settings I (that is, we, our company) has clicked on "Allow" when Outlook has presented us with a redirect to autodiscover-s.outlook.com on our macs to get new settings. Today, we got a popup asking to connect to clblgn.sceur.ch to get new settings. I fear some security breach, can someone tell me what this might be?

Thank you.

The serving IP for that URL is 83.97.124.41.  That is an IP owned by HoistGroup SA.  They provide networking and communication services for the global hospitality industry.  I definitely wouldn't trust that link.

For this particular issue with outlook check out Microsoft's page to probe connectivity issues. testconnectivity.microsoft.com


Does eliminating the possibility of repeat words make Diceware passwords significantly less secure? I read about Diceware passphrases and whipped up a little program to generate passwords in that style.  I do this by taking the list of dictionary words to create passwords and "ordering them" by a random number (one produced by System.Security.Cryptography.RNGCryptoServiceProvider), in essence shuffling them.  I then pass that into a queue and dequeue words when a password is to be generated.

This is a little bit different from the pen-and-paper version, since there is a chance there, however remote, that a word may be repeated.  So clearly we reduce the number of possible passwords somewhat.  Does this reduction in possible passwords significantly change the susceptibility of such passwords to cracking?  Would it be better to read the dictionary into an array and get words by generating a random number and accessing the array at that index?

This might get better responses in crypto.stackexchange.com or math.stackexchange.com, but I think I can give you the gist of it.
If we step away from words and take a look at some numbers it might help to illustrate.
Take for example a four-digit code for a lock.
There are 10 possible digits (0-9) and four spaces where they can be entered, so there are 10 * 10 * 10 * 10 = 10^4 = 10,000 possible combinations.
If you say there can be no repeating digits, then on the first space you would have 10 possible digits, on the second 9, on the third 8, and finally 7 possible digits on the last space. This leaves 10 * 9 * 8 * 7 = 5,040 possible combinations, or, about half.
If we apply this to your password maker, we would take the total number of words you are using as possibilities (most Unix systems come with an English dictionary with around 200,000, so we can use this number for now), and the total number of words in your password (using 6 as the minimum Diceware recommends).
This means that without any restrictions on repetition, there are exactly 200,000^6 = 64 nonillion possible password combinations.
If you were to disallow any repeating words, there would be 200,000 * 199,999 * 199,998 * 199,997 * 199,996 * 199,995 ≈ 63.995 nonillion possible password combinations.
That is a difference of approximately .00008%.
As you can see, with a dictionary of at least 200,000 unique words and a keyspace of six words, the difference between no password restrictions and and limiting repeating words is negligible.
This difference would then have an equally negligible effect on the password's resistance to cracking.
EDIT
LieRyan has pointed out Diceware uses a wordlist of 7776 common, easy to type words. If we wanted to see the difference with a list of that size, it would look something like:
No Restrictions: 7776^6 ≈ 2.21 sextillion possible combinations.
No Repeats: 7776 * 7775 * 7774 * 7773 * 7772 * 7771 ≈ 2.2064 sextillion possible combinations.
Difference: ~0.19%
Let's take a look at what that means to someone trying to crack your password.

Assume your adversary is capable of one trillion guesses per second.
-Edward Snowden, 2014

If we take this estimate (emphasis), we would divide the total number of possible combinations by the number of guesses/second to get the total seconds taken to bruteforce every combination of the wordlist.
That is, 2.2 sextillion combinations / 1 trillion guesses/sec = 2.2 billion seconds = 69.72 years (compared to 70.03 years without password restrictions)
This is the average time it would take a well-funded and equipped password cracker (with access to a copy of your wordlist) to bruteforce a password made with this method.


Are web scrapers fooled by obscured emails anymore? It's a common practice online that instead of writing your email as someone@example.com people will instead write it as someone AT example.com in an attempt to make it harder for web scrapers to find your email address on a web site.

Is this even that effective anymore? I would imagine anyone scraping the web for emails could just as easily check for a pattern like that and transform it to an email address.

I'm sure that some strategies of obscuring the email address are more effective than others, as not every combination that is legible to a human could be accounted for in a program, but common ones like the one I describe above could be found just as easily.

If trying to obfuscate an email, what kind of strategies could be used to ensure that a human reader can understand but a program would not? Couldn't the scraper just continue to be updated to understand new patterns as its author finds them?

You've got multiple methods really, you should of course consider that such bots harvesting this content are essentially scraping whatever pages they come across and searching for patterns that look like email addresses. As you say, it's a bit of an arms race and there's nothing stopping the people developing such scrapers from implementing these methods (wait, is that why you're asking?)

You're going to want to avoid actually creating a hyperlink out of your email address in most cases, and you certainly want to avoid using mailto: - that's basically announcing to anybody reading the page "hey, I'm an email address".

Let's start of nice and simple, spacing:

m y e m a i l @ m y d o m a i n . c o m

It's obviously an email address to a human, looks like a bunch of random letters with spaces to a scraper. Don't like spacing? Much less common but far more foolproof is to convert your email address into an image. It's still human readable but it's not going to be something that most email scrapers are looking for, let alone able to parse.

How about converting your punctuation (@ and period) into their HTML equivalents (&#64; and &#46; respectively)?

myemail&#64;mydomain&#46;com

This still looks like an email address when rendered by the browser, but it isn't going to be all that difficult to work around from the point of view of scraping since you'd just look for the &#46; and &#64; - but why stop there? Why not go all the way and just encode the entire email address? This can be done quite easily with a tool like Rumkin's Mailto Encoder, suddenly your email address looks like this:

&#109;&#121;&#101;ma%69&#108;&#64;my%64%6fma%69&#110;%2e%63&#111;m

This still renders like you'd expect in a browser, but is basically gibberish as far as any scraper that doesn't take the encoding into consideration.

You can also do this with CSS if you're so inclined with something like this:

<style>
  my-email::after { content: attr(data-domain); }
  my-email::before { content: attr(data-user); }
</style>

<my-email data-user="myemail" data-domain="mydomain.com">@</my-email>

Or, as already discussed on Stack Overflow, you could just use JavaScript.


URL escape before inserting user data into HTML URL parameter values? Suggestion from OWASP Cross Site Scripting Prevention Cheat Sheet:

RULE #5 - URL Escape Before Inserting Untrusted Data into HTML URL Parameter Values
Rule #5 is for when you want to put untrusted data into HTTP GET parameter value.
link

Once a victim clicks on the encoded url, he will hit that link. But when the server reads (e.g. $_GET['name']; in PHP) the get parameter value, it will read in plain text e.g. if url?name=alert%28123%29, $_GET['name'] will return alert(123). If the server reflects the string in a browser, the XSS will still be executed.
So, what is the point of the encoding suggested in the above quote?

This isn't to prevent possible future attacks after clicking on the link. Instead, it prevents attacks on this page, where the link is inserted (at the same time, it preserves the correctness of the link, because - as you noted - the server will properly URL-decode the values).

If you would not encode the data here, an attacker could perform XSS, eg via ">[XSS].

If - after you click the link - the parameter is again inserted into the page, you need to again take preventative matters matching the context it is inserted into.


Finding an up to date website with detailed information on viruses Is there a website with the ability to search through viruses that will return detailed information on them?  I can't seem to find one and I'm tired of only getting forums when I search for a specific virus on Google.  I want to be able to look up a particular virus and read information about what that particular virus does/tries to do.  Thanks guys.

It sounds like you are interested in something similar to the National Vulnerability Database (NVD), except for malware.  I am not sure such a thing exists, but here are some similar repositories:

http://home.mcafee.com/virusinfo/
http://www.microsoft.com/security/portal/Threat/Views.aspx
http://www.virustotal.com/search.html
http://about-threats.trendmicro.com/threatencyclopedia.aspx?language=us&tab=malware
http://www.f-secure.com/en/web/labs_global/threats/descriptions
http://www.sophos.com/en-us/threat-center/threat-analyses/viruses-and-spyware.aspx

Perhaps it would be a good project to stand up a site that  queries all of these repos and provides results from all of them in one place.


Can my internet administrator see what I'm uploading? Can the internet administrator on my school where I teach see what I'm uploading to my students on Blackboard. I.e. if I upload a file: "exercises_class1A.pdf", would they be able to see and open the files that I upload to my students? Or would they only be able to see some "activity" from my side?

Too many missing pieces of information so instead of peppering you with questions I'll go with a Straw Man then take it apart.
Assuming a baseline configuration of a secure HTTPS to the server you are uploading to, then no, the school admin would see only encrypted traffic to the server.
If it's not HTTPs (or otherwise secure connected) then the school admins (here after referred to as "They") are capable of seeing full content.
If They have access to the server with appropriate permissions then They can of course see the content.
If They have an agreement with the server to provide logs or such, then They can determine content.
If your use of the school network requires a school supplied cert to get through the school gateway, odds are They are decrypting as a Man in The Middle (MiTM) and can see full content.
Third parties, such as the students, can forward content to anyone.
The school supplied computer you are using may have monitoring software capable of providing content and activities as monitoring logs.
Short answer: They probably don't but best to assume that They can and do!


Need some recommendations on good IR hands-on training Does anyone know if there is any good hands-on training for incident response and digital forensics, or certification I need to take in order to gain more hands-on experience? Thanks and any helpful information is appreciated.

One good place to start is Open Security Training. Despite the site design, they have some quality material there for you to work through.

As you noted, you'll want some hands-on experience as well. Finding challenges online can help with this. You can look at test images (some will be old but still useful!) or, if you're looking more into incident response than digital forensics, the Honeynet Challenges and Malware Traffic Analysis exercises.


Is there any way to crack a Bitlocker drive? We have disk drive that encrypt with BitLocker. My key is lost, and we haven't any backup of the data. Is there any way to hack or crack and recover our data?

Unlikely. It's AES-CBC-128, so there's no chance of you cracking the key.

There are a few tools (e.g. Volatility, or Elcomsoft's forensics suite) that can recover the master key from a system memory dump, but that only works if the drive is already mounted and unlocked.


Why do many websites hide input when entering an OTP? I've noticed that on many sites, when they ask for a one-time password (OTP) (usually sent by SMS), the input is hidden in the same way as a password field is.

My understanding is that once an OTP is used, then it is no longer useful for anything.

Is there a valid reason for hiding the input for these fields?

I'm basing my answer on the assumption that a One-Time Password is used as a second factor, in addition to a traditional username/password combination. If this is not the case, and the One-Time Password is the only factor, then Gilles' Answer is certainly more applicable.

Most likely due to Cargo Cult Programming, which means blindly following patterns that have been observed elsewhere, without understanding the real meaning behind them.

A developer may see the "password" in "One-time password" and happily make it <input type="password">. Afterall, that's what it's there for, right?

Is there a disadvantage?

Security-wise, no. Disclosing a one-time password to a third party (e.g. through shoulder surfing) is not as problematic, because the password loses validity after one use, or after a certain amount of time.

The only imaginable downside would be a lesser user experience, as a user might have trouble ensuring that what they have typed actually matches the password they received.


How bad is it to truncate a hash? I'm wondering how bad it is to truncate a SHA1 and only compare, say, the first 10/12 bytes, etc.
I'm working with a fixed length of 8 bytes that I need to hash for uniqueness but store with the smallest footprint possible (8 other bytes would be nice, but I guess not feasible).

A bit more information without sacrificing professional secrets:

Some blackbox take a 8 byte value, transforms it and transmits it to a server, where it is checked for validity against a table of know items.
Neither the blackbox nor the server should be able to know the original 8 bytes.

Best solution would be some kind of 1 to 1, one way relation, like asymmetrical encryption. But I don't think any encryption mechanism outputs so little bytes.

There is no absolute answer, because it depends on the attack model. By truncating the hash, you make some operations easier; this is bad if the attacker wants to perform these operations, and making them easier actually makes them feasible.

There are three main characteristics that cryptographic hash functions try to fulfil:

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

For a perfect hash function that has an output of n bits, costs of finding preimages, second preimages or collisions will be, respectively, 2n, 2n and 2n/2. By truncating the hash output, you lower these costs correspondingly. As a rule of thumb, a cost of 264 is very hard (feasible, but it takes more than a dozen PC) and 280 is infeasible.

In your case, if a collision is interesting for the attacker, and he gets to choose what is hashed, then the attacker will try to input two data elements that imply a hash collision (on your truncated hash). Truncating to 12 bytes makes the attack quite feasible, easy if you go down to 8 bytes. On the other hand, if all the attacker can do is to try to find some data element matching a given truncated hash (second preimage), then at 10 or 12 bytes this is still too hard to be feasible, and at 8 bytes it is merely "very expensive" (so probably not worth the effort).

If there is no attacker and you are just fighting bad luck, then truncating to 8 bytes incurs the risk of spurious collisions; you should reach your first collision after (on average) entering a few billions of entries. Depending on your situation, this may or may not be tolerable.


Is CentOS a good choice from a security perspective? How secure is the CentOS Linux distribution?  I noticed there were times when there were no up-to-date patches for some version of CentOS (e.g., 5.6). I read this on some mailing list that I can't find now. I seem to recall the problem was that CentOS 6 was not stable yet, and the 5.6 users were left without updates, but I'm not sure. I apologize if my information is bad.

The lifespan of a version is very attractive: http://wiki.centos.org/Download

Are there any other Linux distros that has such a long lifespan, and have a good security track record?

The short answer is this: No, CentOS 5.6 is inherently no more or less secure than any other modern supported operating system. The long answer is a bit more complicated.

CentOS is the "Community" release of RedHat Enterprise Linux (RHEL). The differences between the two are fairly small so you can think of them as functionally equivalent, see the Wikipedia page for more information. The relationship between them is best described as a workflow; as RedHat releases packages, the CentOS maintainers full down the source rpms (ignoring any packages they need to for licensing reasons), rebrand and repackage for their own releases while maintaining version numbers. This history and workflow is important to your question.

RedHat's business is selling a stable product with support. Each major release of RedHat Linux is defined by a single kernel version, and often the versions of big packages such as Apache remain fairly stable. The RHEL team does, however, backport relevant security fixes. These backports are what allow the RHEL 5.x series to use kernel version 2.6.18 but still be patched. Due to the above relationship, this work also translates back to CentOS.

All that being said, given the work required to translate the packages one must expect a time lag between a RHEL release and a CentOS release. Normally the lag is fairly small, occasionally you will run into the situation that we had earlier this year when there was a couple of month lag between RHEL 5.6 and CentOS 5.6.

Going back to your question: Is CentOS a secure distribution? Is pinot grigio a good wine? How good is your admin? As I said in the beginning, "CentOS is inherently no more or less secure than any other modern, supported operating system." Any system can be hacked into. Just make sure you are following good practices and all of your other layers are in place.


Connect with a WPA2 hash instead of cracking it When stealing a WPA2 hash from a packet, why do you need to use brute force to find out the original password instead of just sending the router the hash itself and connect with it to the router?

With WPA2, the hash of the WPA2 key is never sent over the network.  Instead, the client derives an encryption key from the password, then the access point is able to verify that the client is in possession of the password cryptographically using the key derived from the password and nonces/ephemeral keys to prevent replay attacks. See https://superuser.com/questions/1068126/router-wifi-password-encryption-types-and-why-do-they-matter for more information.


What is the strength of the key derivation function on Android device encryption? What is is strength of the key derivation? Specifically, how many milliseconds or microseconds would it take a desktop computer to check a guessed password to see if it is a match? I am aware this varies by computer, so I want a ballpark, and I'd give a 3GHz single core computer as an example, but take your pick.

Assuming there are no significant flaws in the implementation, and the symmetric encryption is of good quality, then I can use your answer combined with knowledge of my password strength to estimate the cost for an attacker to decrypt my Android.

Obviously there are caveats. If the phone is still on, the attacker could follow a procedure to bypass the encryption obstacle (using a freezer, and swapped ROM, or other technique). There may be other caveats worth mentioning.

Slide 23 of this presentation claims that the key derivation for "Android Encryption" is PBKDF2 (presumably with HMAC/SHA-1) and 2000 iterations. Since each iteration implies one HMAC call, which itself uses two nest SHA-1 invocations, this amounts to 4000 SHA-1 calls to check one password.

A 2.4 GHz Core2 quad CPU can compute about 48 millions SHA-1 per second (source: me), translating to about 12000 tried passwords per second. If the password is a four-digit PIN code, it will not last long...

With a GPU, you can go to the billions of SHA-1 instances per second. OclHashcat claims measured performance of 27 billions of SHA-1 on a PC with eight big GPU; this would translate to more than 6 millions tried passwords per second with PBKDF2 as used in Android.


Why do we need IdP when directory services already authenticate and authorize users? Why do we need Identity Providers when enabling SSO? Why can't directory services do it itself when they already have users identity and can verify it (I'm thinking here about MS AD and the need of AD FS to enable SSO).

Thanks

I think the main reason is that Directory Services that have been around for a while such as AD and LDAP were designed strictly as authentication stores for client applications to leverage. SSO was a later development that is application driven. This is why Microsoft developed ADFS to address the integration of SSO with their native AD services to enable third-party applications.


How to handle root passwords for a number of embedded linux boxes? Let's say I create a device which has an embedded Linux box in it (for example, a Raspberry Pi). After booting up, it starts the main application which is designed to provide the UI for the device.

The simplest way to produce more of them, is just to set up everything on one specific device, set the users, privileges, configure the booting process, install my software, and then create an image of the SD card. Installing that image to other SD cards gets me identical clones of the original device, which I can now ship.

However, this can lead to a serious vulnerability. As all the users will have exactly the same root password, all it takes is one user figuring it out (having access to the physical devices counts, as far as I know, for completely compromised security), and that one user might then use this knowledge to compromise the devices of other users (the device is expected to be used while connected to a network)

How can one mitigate this risk?

The software also needs to know the root password (as it needs to configure some hardware registers for the peripherals), so does this mean I have to compile the executable for each of the physical devices separately with separate root passwords, and create the users on each device separately, then manage to copy the correct software to the correct machine? This seems like a management nightmare.

Consider to build your application in a way that hardware access and other
high privileged actions are done by a service which is running as a privileged user (Try to avoid using root) and has a stable and well defined interface while all other logic is done without this privileges. This will reduce the attack surface and you don't need to store non-hashed passwords on the device.

Another simplified way could be to create a minimalist binary which handles the hardware interaction which you could call from your application. This binary could have the setuid permission for root set like @paj28 already suggested. However this will have some impact on the performance of the whole process since calling a external binary creates more overhead.

As @SmokeDispenser already stated it's best practice to harden the root account by disabling local and remote login and by randomly generating individual passwords for every single device. This can be done by using a setup script.


What is the race condition in the Heartbleed attack? A race condition occurs when two or more threads access shared data and try to do so at the same time.

The Heartbleed attack is a vulnerability in OpenSSL, where a Client sends heartbeat requests to a Server. The heartbeat requests can be of variable length, the length of the request is specified, however not checked for. Therefore when manipulating the size field of the heartbeat request, the server would return a reply that could be very long and therefore contain security relevant information.

Now, how on earth is this vulnerability related to two threads trying to access shared data at the same time?
This question has been asked in one of our previous exams and I really cannot answer this. Can somebody help?

Also, very much related to this question is the following: Can type-safety prevent race-conditions?  Type-safety basically means: The programmer is no longer in charge of memory management. And since race-conditions arise whenever two or more threads are trying to access shared memory, type-safety provides a way to at least minimize race-conditions, doesn't it?

Heartbleed was not an exploitation of a race condition... though you could argue the non-deterministic nature of the data returned is an outcome of a race condition. The exploit was a case of improperly placed trust (and improper bounds checking).  The victim trusted the attacker to tell it how large it's heartbeat response payload should be (because the server code was written to write a response of the same length (asserted length via the payload_length field)).

In heartbleed the "hacker" sends a four-byte HeartbeatMessage with a 1 byte payload.
this is the normal/correct length but the "hacker" claims the payload is huge in the payload_length field... lets say 65535 bytes in size. The victim reads 65535 bytes from its memory (instead of the 1 byte is should read).  This read starts from the received HeartbeatMessage payload.  It thus sends far more data than it should, leaking potentially useful/dangerous information.

Using the above a "hacker" can repeat this process as often as they like to try to find juicy info from a target.


How can I access a website without it being able to identify me as a previous visitor? Phone is rooted
Basically I want to be able to access a website without it being able to determine any of the things it dermined about me (my device, ip address etc) when I accessed it last, no matter how advanced of a tracking mechanism it uses.
I want it to seem as if it is being accessed from a different device, completely unrelated to the device which I accessed it from previously. No connection between the two could be made.
An app called XprivacyLuna through Xposed comes to mind, but not sure if it could get around fingerprinting.

What you expect can be done, but will not be convenient.
It's not needed to create a new fingerprint for every connection, but have one fingerprint that are so generic it cannot be linked to you.
You can buy a popular phone - a cheap Samsung (for example) running the stock ROM (not rooted), and access the site using your provider. For the next access, factory reset, access the site using a WiFi connection. Even if the device is the same, the factory reset will delete every identifier linked to the device, and more than a dozen popular Android devices running the stock firmware will have accessed the site, so neither access can be linked to you.
That's why Tor browser recommends you to not change the browser resolution and not used it maximized, so every user will have the same settings and same resolution.


Are there any security measures that are resistant to a brute force attack? I'm not talking in particular about encryption, but security as a whole. Are there any security measures that can be put in place to protect data and/or a system that can withstand even a hypothetical amount of resources being pitted against it over a hypothetical amount of time?

I think the answer is no, but I thought I'd double check before saying this out loud to people because I'm no security expert.

I should point out, I'm not asking this because I need to implement something. It's idle curiosity. I should also mention that I'm ok dealing with hypotheticals here. Feel free to bring things like quantum computing into the equation if there's any relevance.

One-Time Pad and Shamir's Secret Sharing are two examples of cryptographic algorithms, where some secret value is involved, and which are nonetheless immune to brute force, even against attackers with unlimited computing abilities. Their key feature is "lack of key redundancy": there is no way to filter out "bad" keys. This shows in the fact that OTP requires the secret key to be as long as the encrypted data, and for Shamir's Secret Sharing the total size of the "shares" is even longer than the shared data.

Probabilistically speaking, you get the same property from an AES encryption, as long as you encrypt a single block, and use a key larger than that (e.g. AES-256 for encrypting a single 128-bit data element). The idea is that for a given ciphertext, any plaintext can match (given C and P, there are quite a few keys K such that AESK(P) = C). Hence the attacker cannot choose the "right" plaintext, even if exploring the whole key space. Of course, reusing the same key for anything else, even encrypting another 128-bit block with AES, would give to the attacker all the redundancy he needs to filter out keys, making brute force viable again (for our hypothetical attacker with a computer bigger than a galaxy, that is).

Algorithms which resist brute force have limited applicability, precisely because of the need for very long keys. In practice, against attackers with earth-based technology, brute force attacks are thwarted by using "long enough" keys. If you consider than an attacker may muster enough computing power to perform 2n "elementary operations", then you use keys of at least n bits; if you fear quantum computers, you use 2n bits (for anything symmetric, like symmetric encryption or hashing, a quantum computer may theoretically explore a key space of size N with effort sqrt(N), but no better; hence, it suffices to use a twice larger key). Traditionally, we set n=80 but constant progress in technology availability is beginning to force us to bump that value a bit, if we want to keep a convincingly large security margin. Since powers of two are good, it is now customary to use n=128, although the actual limit for Mankind as a whole (in an improbable sci-fi scenario in which all humans cooperate and work for that goal) can be estimated to be somewhere between 90 and 100.

Asymmetric algorithms (asymmetric encryption, signatures...) are much weaker, in that there are known attacks which are much better than "brute force" -- and a quantum computer makes the attacks trivial, for most of them. But since this is not brute force anymore, it is out of scope of your question.


What does it mean to sign a public key and what's wrong with signing someone else's key? I just stumbled upon this comic and I'm not sure if I understand what's going on. I googled and I figured that somehow people can sign other people's public keys and then they that person is genuine.

I wanted to ask what exactly does that mean, what would be the consequences and how does that comic relate to real world. For example, do people accidentally sign those keys?

As explained over at explain xkcd, key signing parties are a way to meet a lot of people and check their IDs easily in order to sign their (GPG) public keys.

Signing public keys is essentially vouching for the identity of the key holder, as not everyone can make sure it's actually the key of the real person they'd like to talk to.

Thus, the so called "web of trust" is a way to establish trust in otherwise unknown keys - if a lot of people signed the key, the idea is those can not all be fooled, identity-wise.

Hence, signing a strangers key without checking their ID (or somehow else establish trust in that this key belongs to that person) is a bad thing for the web of trust.

Additionally, there might be a word play regarding "key signing parties" and "key parties", the latter being a lifestyle party where men put keys in a bowl and women draw keys as random from that bowl, leaving the party with the key's owner.


Why is the Web so complicated? Hope it does not sound as a surprise to anyone that modern Web and its security, with the many layers and technologies, is pretty confusing and difficult to learn well. For someone with a good perspective on the history of Web's design and development, was there anything that, in hindsight, could have been made simpler; or does the Web have to be so complex because of the requirements it has to meet?

I realize that the question might be broad, but any bits and pieces would be very welcome.

The reason for this is mostly that "the web" is not a singular thing, with a singular designer.

It's a complex structure, who's purpose shifted over decades. We want more from the web today than we wanted back in the 80's, just like we want more from our phones today than we did back in the 80's.

Furthermore, the architectural idea that a server instructs a client to do something, and that client may or may not understand what the server wants, is another reason why the web is so complicated. It's the reason why Internet Explorer is so crappy, and why all web developers rejoiced when Microsoft announced they would finally retire it.

As far as historical data goes, hindsight is always clearer. There are many technologies that we thought were pretty neat (ActiveX, Flash, Java Applets, etc.), but turned out to be horrible in hindsight. Of course, you may look at those things from today's point of view and notice all the problems, but these were designed in a different era, where people had different expectations.

To summarize

The Web is complex because

It grew over decades and is one of the most legacy-loaded things there is.
It was never designed at one point by one individual or company.
It had to support many different clients, some of which may be grossly outdated.
It's not possible to "start over". We can only work with what we have.
Different companies tried different things, often duplicating work instead of working on open standards.


Are there security (esp. privacy) benefits to deleting cookies? As the title says, I'm wondering if there are any security/privacy benefits to managing cookies - that is, managing by deleting cookies you don't want or need.

I deleted all my cookies about a week ago and since then I've left a tab open in Chrome with the list of cookies.  (chrome://settings/cookies)  A few times a day (when I think of it), I refresh the list and go through it and delete any cookies I don't really need.  In my case, other than a bunch of StackExchange sites and a couple of others that I like to stay logged in to, I've been deleting almost every site's cookies.

This doesn't take very much time and it's been interesting to see which sites lead to cookies from various advertising sites, but is it doing me any good in terms of maintaining a bit more privacy on the Internet?

I would say yes and no at the same time.

Advertising company are using some clever techniques (including cookies) to identify your browser :

Your classic cookies (which are now gone).
Flash cookies : you can store content in flash which can be using for cookies (very common now).
Your browser fingerprint (HTTP Header fingerprint, fonts installed, OS, browser version, Time location) with your ip address can be used to retreive information from deleted cookies.
You can store things directly with HTTP headers (HTTP cache) but I don't know a lot about it.
Css visited links (via faux links with data).
Browser cache can also be used for storing cookies

I suggest looking at the evercookie project, its quite interesting.


Does unpatched software comply with PCI DSS 3.1? Can some one help me to confirm that unpatched software complies with PCI DSS 3.1 or not?

The software developer has already released the security patches to fix the vulnerabilities but the organisation which is using it has not applied the patches.

Also what do the PCI guidelines say about software for which any kind of support is not available because the product is in EOL (end of life cycle)?

For critical bugs, the PCI DSS 3.1 Quick Reference Guide covers this in no uncertain terms:

  6.2: Protect all system components and software from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

This is mirrored in the official documentation for PCI DSS 3.2 (I couldn't find a v3.1 PDF) which says exactly the same thing:

  6.2: Ensure that all system components and software are protected from known vulnerabilities by installing applicable vendor-supplied security patches. Install critical security patches within one month of release.

  Note: Critical security patches should be identified according to the risk ranking process defined in Requirement 6.1.

To save you a long read, the TL;DR of requirement 6.1 is that criticality should be measured based on industry provided CVSS scores amplified by business factors.

In more general terms, the question of whether or not they are in violation of PCI DSS when they are running outdated and vulnerable software depends on the decision of their QSA. If the bug is minor, such as a static content injection issue or minor information disclosure, then the QSA may consider it appropriate that the organisation identified the issue and placed it on their risk register for future resolution. If the bug is more severe but not considered critical (e.g. reflective XSS requiring user interaction), the QSA may still consider this a violation of PCI DSS at their discretion.

With regards to EOL software, PCI DSS does not mention it specifically, but simply states that

  All systems must have all appropriate software patches to protect against the exploitation and compromise of cardholder data by malicious individuals and malicious software.

This indicates that using EOL software becomes the responsibility of the organisation handling cardholder data. Should a vulnerability be found in the application, it is up to the organisation to mitigate this. This may require them to manually patch the application (difficult, expensive), provide secondary controls (e.g. placing the application in an isolated container environment such as XenApp), or replace the software entirely.

For more information, I suggest you give the PCI DSS documentation a read for yourself. It's quite a long document, but you can skip to sections applicable to your concerns, and the language is quite clear and readable. Also keep in mind that PCI DSS is a standard designed only to encourage sensible security practices around the handling of payment card data - it is not a recipe for strong security on its own, so "PCI compliant" doesn't necessarily mean "secure".


Why do phones send wifi probes? They could just listen to beacons. Why do they probe for every network you've ever connected to?

Do other wireless devices do this? Does Windows, Linux esp. Kali, do this?

That is because listening for a beacon and not getting it just might mean that the network has a private ("hidden") SSID. From this article (emphasis mine):

  The 802.11 standard allows APs to beacon with the SSID field set to
  null - this is referred to as a hidden SSID. A client that wishes to
  associate with an AP using a hidden SSID must first send out a Probe
  Request that contains the SSID of that network, which will then cause
  the AP to provide a Probe Response. For any client that does not
  provide the correct SSID, the AP does not respond.

I believe that probing can be deactivated in Linux; not sure about Windows, but given their history I'd wager that probing is on by default, and may perhaps be disabled through some obscure registry hack.


Will Ad Block Plus block the ads that give someone Cryptowall 2.0? Now I already know that making sure your browser plugins are either non-existent or up-to-date is one way of being on the safe side against ransomeware like Cryptowall 2.0; but since clicking ads are the way this thing is distributed, would ad-block plus be an effective plugin against such threats?

Zedo and Double Click have been effected by this thing in the past, and this time around I believe it might have been on yahoo.com or msn.com (not completely sure though).

It can't hurt.  ABP (and similar software) blocks known ad providers and patterns that look like ad providers.  If one of them gets popped and starts serving up malware, ABP will save you.  If the site you're on is the compromised one, ABP can't help (unless the compromise is to point at a compromised ad network that's already blocked... seems complicated).  Better than nothing :)


Too much requests on the Nginx Server I'm receiving a lot of requests like these

[server] zcat access*gz | grep 404 | awk '{print $1" "$7}' | sort | uniq -c | less
:
      2 103.193.242.137 /MCLi.php
      1 103.193.242.137 /Moxin.PHP
      1 103.193.242.137 /MyAdmin/index.php
      1 103.193.242.137 /MyAdmin/scripts/db___.init.php
      1 103.193.242.137 /MyAdmin/scripts/setup.php
      1 103.193.242.137 /MySQLAdmin/index.php
      1 103.193.242.137 /PMA/index.php
      1 103.193.242.137 /PMA/scripts/db___.init.php
      1 103.193.242.137 /PMA/scripts/setup.php
      1 103.193.242.137 /PMA2/index.php
      1 103.193.242.137 /Pings.php
      1 103.193.242.137 /SQL/index.php
      1 103.193.242.137 /Skri.php
      1 103.193.242.137 /Ss.php
      1 103.193.242.137 /Updata.php
      1 103.193.242.137 /WWW/phpMyAdmin/index.php
:

The hosted server is plain and simple HTML/CSS server. The server in Nginx.

Are these requests going to have any impact on the server?

Should I use rate limit? Will rate limit impact SEO bots?

Are these requests going to have any impact on the server?

Everything has some impact but if this impact is relevant depends on  how many requests these are, how much your server can handle and if these requests trigger some kind of expensive actions in the server - none of this is known.

But in general such "noise" is very common on the internet so you better should be able to handle such requests and handle these as cheap as possible. If your server is configured to only handled static pages and just responds with 404 to these requests then this should be cheap enough.

  Should I use rate limit?

I don't think that this helps in these cases since it will only result in another error response to the client, which is about the same effort as the 404 response. The client will likely not care about this error as much as it did not care about the 404 response, i.e. it will not slow down the client.

What I do is redirect such requests to a different port on same domain and have an iptables DROP rule on this port. Many will actually follow these redirects and try to access the new URL without success, i.e. they will run into a timeout after a while since they cannot connect to the new port (due to the DROP rule). This will slow them down.


How are ACK storms created and what's a good mitigation strategy for them? The context is network based load balancers. It would be nice if someone could explain how TCP ACK storms are generated in real life and practical mitigation strategies for them.

Edit: Clarification on "mitigation strategies". The platform consists of nginx web servers/load balancers running on Linux. So would appreciate the relevant switch to toggle (if any) to thwart it.

When a client and a server connect to each other, they know the connection by its source and address IP addresses, and its port numbers (on client and on server). There are two sequence numbers for both directions of the connection flow; their initial values are chosen randomly. Whenever one of the parties sends a packet, that packet may talk about both sequence numbers: a packet from the client may include information about the sequence number for the client-to-server flow (e.g. a "PUSH") but also information about the sequence number for the server-to-client flow (an "ACK").

If the attacker can make it so that the client and the server disagree by a wide margin on both sequence numbers, then a ACK storm may occur. Basically, the client sends a packet to the server with a server-to-client value that the server finds ludicrously off-the-mark. The server responds with a packet which says "dear client, you are sorely mistaken about the current server-to-client sequence number, pray be so kind as to amend your ways". However (that's the nifty point), that packet will also include an ACK from the server which documents the server's notion of the current client-to-server sequence number... that the client will find preposterously invalid. This will prompt the client to respond with a packet that says "dear server, you are sorely mistaken about the current client-to-server sequence number, pray be so kind as to amend your ways". That packet will also contain an ACK. And the loop goes on...

The storm rages until one of the ACK packets is lost, ending the ping-pong match. However, it will start again the next time the client or the server has anything to say, because they are still desynchronized.

ACK storms thus rely on the ability to desynchronize the client and the server for both sequence numbers. This can be done with semi-MitM abilities: e.g., the attacker can observe the packets between client and server, and also inject some fake packets, but not block existing packets. This is the model of "the attacker is on the same LAN, and the switch is in fact a hub (or has been demoted to hub-like behaviour after having been spammed to death with random junk packets from the attacker)". When the attacker sees a connection from client to server, he immediately sends a fake RST packet (as if the client had closed the connection) then a new fake SYN purportedly originating from the client, with the same port numbers, but widely different sequence numbers.

See this presentation for some details.

Defence is relatively easy: either of the systems engaged in a ACK storm can detect that it receives and sends inordinate amounts of error packets for a given connection, and simply drop it. The ACK storm can keep on only as long as both systems are ready to respond an ACK for an ACK; at the first lost packet, the storm ceases. If a storm is detected, then: 1. the system who detects the storm can stop it by refusing to participate to it any longer, and 2. the connection being unsalvageable, it can be unceremoniously dropped.


What are the security risk of enabling cors on localhost? I have a Cordova based mobile app that is hitting some API via a local server on mobile. The mobile app sets origin as Localhost. Here cors kicks in and I can't make the request. Now these API's can be used via a terminal, postman and other non-browser environments without triggering CORS.

Now in this scenario what are the risks of enabling cors on localhost?
Just to clarify I want to whitelist cors for localhost in production.

The answer really depends on what API you created and how it works.
This site gives a very good explanation on the goods and bads of CORS. In short, the author creates a fictional API that is used to send e-mails from another domain. He states:

If you are using authentication based on session cookies, you probably shouldn’t allow CORS requests by everyone. A malicious website can issue e-mail sending requests to api.yoursebsite.com via an AJAX request without the specific permission of your user.

This is (in his hypothetical case) the answer to the question "what are the risks of enabling cors"? In that case, he also gives some more information about how to think of mitigation:

If the user has valid session cookies in their browser, they will be used to authenticate on api.yoursebsite.com and that would lead to unwanted e-mail sending. In most cases, dangerous requests will be “preflighted,” which means the domain needs to be approved before they can even send a request. This will prevent any malicious activities from happening.

This states (in a slightly hidden way) what dandavis already said: CORS has not much to do with security. The security is done on server side. The SOP won't be obeyed by hackers anyway.
In your case, from what I understand, you want to enable localhost as a domain via CORS so that requests can be made through some different domain?
If that is correct, I think that you will face no real security issue. Under the precondition that you opened some socket bound only to the loopback address (localhost), the only way someone would be able to access that (in a malicious or in another way) would be: He already has access to the loopback address. That means: He already gained access to the device.
Based on Conor Mancone's quite right comment: CORS primarily protects against unauthorized read requests. It is not protecting the server from writes or triggering unauthorized actions. This has to be enforced by an authorization concept.


Are MAC addresses of hosts always visible to other hosts on a WLAN? Is there a way of completely hiding one's MAC address so it does not appear in the ARP caches of other hosts? Or is periodically changing it the only solution to achieve anonymity with regards to a MAC address?

Yes, MAC addresses are always visible to other hosts on the same LAN, regardless of whether or not it is wireless. In fact, they are fundamentally necessary, as they are how two local devices communicate with each other. There is no way to disable the usage of MAC addresses, however you can spoof them, essentially assigning a new, arbitrary address to a device. As long as it does not collide with any other existing addresses, it will be used to route traffic to it as usual.

Note, however, that an attacker-controlled wireless access point may not be fooled by a spoofed MAC address, since all devices have their own unique quirks when it comes to establishing a wireless connection. This WiFi fingerprinting can correlate the identity of two devices even if the MAC address has been changed. Anonymity may be hard to achieve when you are connecting to a router that is not under your control. Assume that that router knows which machine is yours. If you just want to avoid appearing in hosts' ARP caches, then changing your MAC address is sufficient.


Modifying requests using Burpsuite considered to be valid security vulnerability? I would like to know if intercepting and modifying requests using Burpsuite before reaching server is considered as vulnerability.

In our web based and mobile applications, adequate security measures are in place to avoid replay attack and data integrity etc.,

Now the same is being evaluated by one of the application security teams, they use burpsuite to intercept the request payload and have raised few security vulnerabilities which aren't reproducible without using Burpsuite.

So using such tools is still a valid case and considered to be vulnerable?

Let me explain test case which i am trying to find a solution, to avoid replay attack i use client and server nonce in my web application. Requests are intercepted using burp-suite and only the client nonce is changed and forwarded to the server and its obvious request will be processed. It is raised to be a vulnerability.

What Burp does is intercepting a request and allowing the user/pentester to modify it. Technically it acts as a proxy, allowing the user to send pretty much arbitrary input to your application (server-side).

You seem to assume, that requests can only be sent using your app. This is not true and generally pretty dangerous to rely on. Keep in mind, that everybody can do a "Bash-Fu-1-Liner" using cURL and send literally anything to your server. Your webservice has to be prepared for that! If the only input checks you perform are client-side (which is untrusted code as users can mess with it), you have to overthink your security measures.

Separate client-side and server-side. Think of them as two pieces of software which have to be secure on their own.

Edit: As you added a test case to your question, I'll add the answer here. Penetration Tests flag a lot of things as potentially dangerous. It may be true and little bugs, which don't look like they can wreck havoc on your server, will do so, if exploited properly. However, a Penetration Tester will scan your app, test around, find bugs and report everything which looks dangerous. Keep in mind, that he does not know the application as well as you (or the Software Engineers/Developers) do.

Bugs found by him/her might be false positives and it's on you (and the tester) to verify bugs and prioritize them (irrelevant - critical) according to their damage potential (and other factors). Once in my environment, a pentester's scanner found a document which was reported as "Privilege Escalation" as its regular link is behind a login. False Positive, as it was an unimportant document.


Drupal filters XSS with regexes. What could bypass it? Drupal filters HTML strings against XSS attacks using regexes: http://api.drupal.org/api/drupal/includes%21common.inc/function/filter_xss/7

However, as a lot of people know, HTML can't be parsed with regex.

Which makes me think that the filter_xss function could let some invalid HTML pass a script tag in it, thus being a security flaw.

But I'm not efficient enough with regexes. Maybe somebody can find something that passes? If there is, I'd make a patch to use simplexml (or something better if there is) instead of regexes.

FWIW, here is the code of the function:

function filter_xss($string, $allowed_tags = array('a', 'em', 'strong', 'cite', 'blockquote', 'code', 'ul', 'ol', 'li', 'dl', 'dt', 'dd')) {
  // Only operate on valid UTF-8 strings. This is necessary to prevent cross
  // site scripting issues on Internet Explorer 6.
  if (!drupal_validate_utf8($string)) {
    return '';
  }
  // Store the text format.
  _filter_xss_split($allowed_tags, TRUE);
  // Remove NULL characters (ignored by some browsers).
  $string = str_replace(chr(0), '', $string);
  // Remove Netscape 4 JS entities.
  $string = preg_replace('%&\s*\{[^}]*(\}\s*;?|$)%', '', $string);

  // Defuse all HTML entities.
  $string = str_replace('&', '&amp;', $string);
  // Change back only well-formed entities in our whitelist:
  // Decimal numeric entities.
  $string = preg_replace('/&amp;#([0-9]+;)/', '&#\1', $string);
  // Hexadecimal numeric entities.
  $string = preg_replace('/&amp;#[Xx]0*((?:[0-9A-Fa-f]{2})+;)/', '&#x\1', $string);
  // Named entities.
  $string = preg_replace('/&amp;([A-Za-z][A-Za-z0-9]*;)/', '&\1', $string);

  return preg_replace_callback('%
    (
    <(?=[^a-zA-Z!/])  # a lone <
    |                 # or
    <!--.*?-->        # a comment
    |                 # or
    <[^>]*(>|$)       # a string that starts with a <, up until the > or the end of the string
    |                 # or
    >                 # just a >
    )%x', '_filter_xss_split', $string);
}

And this function uses _filter_xss_split:

function _filter_xss_split($m, $store = FALSE) {
  static $allowed_html;

  if ($store) {
    $allowed_html = array_flip($m);
    return;
  }

  $string = $m[1];

  if (substr($string, 0, 1) != '<') {
    // We matched a lone ">" character.
    return '&gt;';
  }
  elseif (strlen($string) == 1) {
    // We matched a lone "<" character.
    return '&lt;';
  }

  if (!preg_match('%^<\s*(/\s*)?([a-zA-Z0-9]+)([^>]*)>?|(<!--.*?-->)$%', $string, $matches)) {
    // Seriously malformed.
    return '';
  }

  $slash = trim($matches[1]);
  $elem = &$matches[2];
  $attrlist = &$matches[3];
  $comment = &$matches[4];

  if ($comment) {
    $elem = '!--';
  }

  if (!isset($allowed_html[strtolower($elem)])) {
    // Disallowed HTML element.
    return '';
  }

  if ($comment) {
    return $comment;
  }

  if ($slash != '') {
    return "</$elem>";
  }

  // Is there a closing XHTML slash at the end of the attributes?
  $attrlist = preg_replace('%(\s?)/\s*$%', '\1', $attrlist, -1, $count);
  $xhtml_slash = $count ? ' /' : '';

  // Clean up attributes.
  $attr2 = implode(' ', _filter_xss_attributes($attrlist));
  $attr2 = preg_replace('/[<>]/', '', $attr2);
  $attr2 = strlen($attr2) ? ' ' . $attr2 : '';

  return "<$elem$attr2$xhtml_slash>";
}

See Is Drupal's filter_xss enough for filtering HTML?, which has some discussion of the security of Drupal's filter_xss().  Make sure to read Mike Samuel's analysis, which identifies a number of shortcomings of filter_xss().  I don't know whether you would classify them as vulnerabilities, exactly, but they are design flaws/shortcomings that could make filter_xss() less effective than developers might expect.

The developer documentation for filter_xss() is atrociously bad.

There's a sum total of two sentences: "Filters HTML to prevent cross-site-scripting (XSS) vulnerabilities." and "Use check_markup or filter_xss for markup containing text.".  When the documentation doesn't explain how to use filter_xss() properly, you shouldn't be surprised if developers fail to use it correctly.  This could lead to vulnerabilities, e.g., of the sort that Rook identifies.

(Drupal also has a document entitled Handle text in a secure fashion, but it doesn't even mention filter_xss().)

I would also suggest that anyone who calls filter_xss() should make sure not to include !-- in the list of allowed tags.  The code for validating comments (which is enabled if you add !-- to the list of allowed tags) looks super-sketchy to me: it doesn't do anything to validate the contents of the comment, which intuitively feels like it can't possibly be safe.


Which signing strategy? I have a device which should lock and unlock something after receiving a signed server response.

So in the best case a loop would lock like this:

User locks device
User wants to unlock device
User authenticates to a webservice
User receives a key
User sends key to the device
Device checks if key is valid
Device unlocks

The main problem is around step six. I am unsure which strategy to use to achieve the signing.

One thing I imagine would be:

Device has a global id
Device has a private key
Server has a public key
User authenticates to the server
Server creates a JSON object with global id, timeout date (and something else?)
Server encrypts and signs the JSON object and sends it back to the user
User sends JSON object to device
Device decrypts JSON object, checks signing and checks timeout
If everything seems good it opens the lock

So finally my questions:

Is this a good strategy? Are there pitfalls?
Which algorithm should I use for step five and eight (HMAC)?

There are two main points to your situations.

1. Does the lock should know how to unlock itself ?

There are basically two kinds of "signature" systems, and only one of them is really a signature. In your situation, the server will send to the device some sort of token which the device will verify. So the question is: is it a problem if the device would have the technical power of producing a valid token ? Or should things be such that the device contains nothing which would allow it to make such new tokens ?

In the former case, you can work with a MAC, and HMAC/SHA-256 is not a bad choice for that. However, this means that the device and the server share some secret key, which is used to both produce and verify unlock tokens. If there are several devices, then each should have its own device-specific key, and the server should then know all device keys -- otherwise, ripping apart one device would allow an attacker to learn enough to unlock all other devices.

In the latter case, the server has an asymmetric key pair; unlock tokens are signed with the server's private key, and devices verify tokens with the server's public key. RSA is a popular digital signature algorithm; the verification part is inexpensive, and thus can be performed by most devices, even power-limited devices.

2. What about replay attacks ?

A "replay attack" is, in your case, when an attacker observes an unlock token, and sends it again at some later point. There are several ways to avoid such issues, but they all imply some sort of extra capability on the device:

Time-limited tokens. The token includes an issuance date and the device won't accept a token which is "too old". This method requires the device to have a reasonably accurate embedded clock.
Duplicate tracking. The device remembers previously seen unlock tokens, and refuses to act upon a token which it has already seen. This requires some sort of memory which cannot be reset.
Nonces. The device first emits a random value, and expects the unlock token to contain a copy of that specific value. This makes the protocol more complex and requires the device to be able to emit data as well as receiving tokens. This will not map well to all situations; for instance, if the device is a door lock, with a keypad, and the user contacts the server through his smartphone. Typically, the device would need a small LCD screen to display its nonce.

You may want to consider HOTP: this is a MAC-based protocol, thus with a key shared between "server" and "device". Both server and device remember only a short counter value (say, 32 bits) and this is sufficient to protect against replay attacks. The communication is one-way (the device needs not emit anything). This protocol (or any similar variant) is what is used to unlock your car: the car is the "device" and the remote control attached to the key ring is the "server".

All of the above is about the token sent from server to device. Of course, the server should not produce the token unless it has good assurance that it is token to the right user (the device owner). You thus need authentication which, in practice, will mean SSL. Let the user open a SSL connection with the server (say HTTPS) and authenticate with the server. The SSL layer will take care of integrity and encryption so you do not have to encrypt the token itself. Actually, encryption would not be needed for an unlock token at all -- you may want to use encryption only to deter eavesdroppers, and you want to thwart eavesdroppers only if your token-verification protocol is weak against replay attacks. In any case, encryption is best left to a layer where all the tricky details have been smoothed out through years of teeth cringing toil, and that's SSL.


Disable or bypass SSL Pinning/Certificate Pinning on Android 6.0.1 Previously I have been able to bypass SSL Pinning by using the program JustTrustMe with the Xposed framework for nearly every app.

https://github.com/Fuzion24/JustTrustMe

However it has started to fail on more and more apps recently. The more I read it seems like I have to disassemble every app and patch them one by one.

Is there some application that I have missed that can disable SSL Pinning by hooking onto system commands?

Programs that I have tried:

https://github.com/Fuzion24/JustTrustMe

https://github.com/iSECPartners/Android-SSL-TrustKiller

https://github.com/ac-pm/SSLUnpinning_Xposed

If there is no such program, what is the best way to go?

What I have identified so far:

Try to disassemble the APK and search for keywords such as "X509TrustManager", "cert", "pinning" etc and modify it accordingly. Like this article: http://blog.dewhurstsecurity.com/2015/11/10/mobile-security-certificate-pining.html
However it seems that at least one of the apps that I have trouble proxying (Facebook Messenger) is using SSL Pinning in the native layer as well as the Java layer. This is probably the case in many other applications as well since they have worked before with JustTrustMe but has now stopped working. https://serializethoughts.com/2016/08/18/bypassing-ssl-pinning-in-android-applications/

Did you go through these procedures to get JustTrustMe to bypass the cert pinning -- http://www.welivesecurity.com/2016/09/08/avoid-certificate-pinning-latest-versions-android/ -- ?

If you are just looking to intercept WebViews, then the Frida extension, appmon (which allows for API interception), using these techniques will work well -- https://youtu.be/QjLRaIB-97E

If you do end up having to rewrite some code, try to keep it really simple. I found this technique which doesn't mess with the existing cert-pinning code and instead just adds the HTTP traffic to the logging system -- https://blog.securityevaluators.com/how-to-view-tls-traffic-in-androids-logs-6a42ca7a6e55

For a series on repackaging Android apps, be sure to check out:

https://pen-testing.sans.org/blog/pen-testing/2015/06/30/modifying-android-apps-a-sec575-hands-on-exercise-part-1
https://pen-testing.sans.org/blog/pen-testing/2015/07/07/modifying-android-apps-a-sec575-hands-on-exercise-part-2


How to choose a stream cipher Are there high-speed ciphers designed for things like internet streams without sacrificing security?  There are so many options that operate in stream mode.  How would one choose a cipher?

By default use AES. AES is a block cipher, i.e. a function which, given a key, maps block values (of 128 bits, in the case of AES) to other block values of the same size. To encrypt a message, one must use the block cipher in a chaining mode which tells how the input data should be split and encrypted and assembled again. Almost all modes allow for streaming (encrypting a huge message on the go, without having to store it entirely in RAM or disk). The good modes combine encryption and integrity check, see EAX and GCM. Among traditional encryption-only modes, the current one is CBC, the newer being CTR; CTR has the advantage of not requiring padding, because it encrypts a sequence of x bytes into exactly x bytes, for all x, whereas CBC requires an input with a length multiple of the block size.

I have a 2.4 GHz Core2 Intel CPU on my PC. This is far from being the best available out there, and will soon verge on the "obsolete", at least commercially speaking. Nevertheless, when I run the OpenSSL benchmark tool:

$ openssl speed aes-128-cbc
(...)
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-128 cbc     108028.29k   147211.99k   161986.82k   166308.90k   167286.10k

so the processor can encrypt data at the whooping speed of 167 MB per second; and that's using a single core. My PC has four cores, so even encrypting data at the maximum bandwidth which could go through gigabit Ethernet would use only 15% of the CPU resources. It would take a quite special application to actually make encryption a bottleneck.

Things will go even an order of magnitude faster on a newer x86 processor, one with the AES-NI instructions. These instructions allow for encrypting data at a rate of less than 2 clock cycles per data byte; if you prefer, it goes beyond the gigabyte per second. Note that this is about 10 times faster than what a typical harddisk can do. The AES-NI instructions also include the pclmulqdq opcode, which helps quite a lot when dealing with the GCM mode.

Nevertheless, there are conceivable, specialized situations where the raw speed of AES is not sufficient (involving machines which do not have AES-NI instructions, of course). For these, one could remark that a block cipher is a versatile primitive, and that maybe an algorithm designed specifically to encrypt long streams, but unable to do anything else, could possibly crunch data a bit more faster. These are called stream ciphers. An old, well-known, slightly weak and actually not that fast stream cipher is RC4. The eSTREAM project ran from 2004 to 2008 as a kind of open competition, with stream cipher candidates and open comments and workshops, and resulted in a portfolio of stream ciphers which "look good" from both security and performance point of views (they did not receive at much scrutiny than AES, but they got a fair share nonetheless). There are four ciphers optimized for software platforms, and three for hardware designs. They are all unpatented and free for any use (Rabbit was patent pending, but in October 2008 it was released to public domain).

An example of application where a stream cipher gives an edge over a block cipher is actually not security related: this is heavy numeric simulation, which requires a steady stream of random values of high quality. Stream ciphers produce high-quality randomness (they are designed so that no bias can be found, even by looking for them on purpose, whereas custom non-cryptographic random number generators tend to rely on luck -- that the problem at hand does not happen to hit one of the known biases of the RNG). For such a purpose, I have successfully used Sosemanuk, one of the eSTREAM portfolio stream ciphers.

Either way, block ciphers and stream ciphers both need proper IV management. The IV is a parameter which needs not be secret, but which must have some specific properties. For some ciphers, it suffices that no two messages are ever encrypted with the same key and the same IV. Some others (including CBC mode) require a bit more, namely that the IV is chosen for each message with uniform probability among the space of possible IV. Anyway, the IV must be known by the receiver, so it is customary to send it in the header of the encrypted message. The RC4 stream cipher has no IV: a given key must never be used for more than one message. IV management is where you will have security issues, because it is often overlooked and not that easy to get right.

Summary: use AES with a proper encryption mode; you also need integrity checks, so a combined mode such as GCM is a good idea. Mind your IV. Envision switching to something else only if you find out that AES is an inevitable bottleneck, because there is very high probability that this will not turn out to be the case.


Will an ISP give out network/traffic info upon request? Nothing big, just a fear of embarrassment. I use my mom's (she pays for it) internet service to connect online and stuff. The thing is, I am nervous that she may possibly ask the ISP for some traffic analysis of where, like, I've been surfing to and worried that she might find out I often visit, uh, ...... dirty sites. I know it's nothing of a serious problem aside from major embarrassment to worry about, but I know it's going to be MAJOR embarrassment because she would find out about my ... kinks and preferences in that department.

So my basic question can worded down to: If requested, will an ISP give all info about where people have been on their infrastructure, and is there any chance they'd be likely to do this without being asked?

Many ISP's log DNS requests, so could have a record of what sites you have browsed to. This is mostly for law enforcement requirements, not generally for giving back to customers, as they should be expected to do their own logging if they want it.

That said - if you are concerned, have you checked to see if your mother is logging all DNS requests? Your router might keep logs.

More importantly, if you are going to be embarrassed about where you go online, do what Lighty suggests and protect yourself. Otherwise, I suppose you could do worse than just be prepared to have an interesting conversation with your mother :-)


Is it possible for my password to have more than one password combination? Can my password have more than one password combination?

I read up on physical combination locks (the lock you open with numbers) and I learned that a combination lock can have more than one possible combinations.

Also I had my first phone, a normal Nokia phone (not a smartphone) that was password protected and I was able to open the device with a password that was not really the exact password for the phone. Like, if the password was set to 4545 and I typed 1111 the phone still unlocked. Or if the phone password was set to 4114 and I typed, let's say, 2141, the phone still unlocked.

The question is, if my password for my Laptop PC was !78ghA,NJ58*#3&*, is it possible that a next combination will work behind my back or will it work only if there is a vulnerability?

In most password-protected systems it usually is possible, but very unlikely.

Behind many password validation mechanisms is the use of salted hash functions. For the sake of simplicity, let's forget about salt for a moment.

When a user sets its password, hash(password) is stored in the database
When the user logs in presenting password', hash(password') is compared to hash(password). If it matches, the user is allowed to log in.

Let's remember, however, that hash functions get data of unlimited length and transform it to data of limited size, ex. 128 bits. Therefore, it is not hard to understand that there can be more than one message that produces the same hash from a given function. That is called collision and it is what you are concerned about.

The thing is that hash functions are produced to be so random that you should not find or produce a collision easily. It is theoretically "possible", but practically "impossible", if you are using a good modern hash function.


Account Recovery: Displaying username without verification I'm not a security guy, so bear with me. As discussed in other topics, usernames in and of themselves are valid forms of verification, and there's nothing particularly sensitive or secure about usernames. For example, in most registration flows, when selecting a username, the system will tell the user whether a username is taken - thus potentially giving malicious users a list of valid usernames. And that's okay, the same things happen in most password recovery flows.

A suggested flow for a user that is trying to recover their forgotten username would be to allow them to type in their phone or email, and the system would instantly return their username in the UI without verification.

The main problem that I could see is that this may allow a malicious user to not only obtain the username, but also to associate it with phone/email. Maybe that's okay too though, because that doesn't give any vital information. To access an account, they would still need access to that phone or email to reset the password. In that respect I don't believe the account would be compromised.

Help me out, what are the flaws in my thinking here?

As a developer you must make sure that your customers Email-ID/Phone are not given away to any unauthorized people.

For any valid email input you just show the user irrespective if he/she is registered or not.

  username send to the email.

This way attacker can never find out if user is registered or not. Email is sent only to registered user via backend.

If you feel that message is bit confusing for user. You can display

  If your account is found in the system, we will mail you the username.


How do I setup SELinux to act a as a true whitelisting solution? I am working on an appliance device running Linux.  I would like to utilize the work done so far with the targeted policy in SELinux space.  Since I own everything that should be installed and running on this system I will know exactly what applications will be running at any given time.

I don't want to re-write a full SELinux policy from scratch and instead I'd like to have the targeted policy moved into a "strict" policy to enable application white-listing and process control.

Then just write the policies for my newly created services that aren't part of the targeted policy.

How would I do that?

Disable or remove the "unconfined" module.

Reference policy is, in my view, not optimal for embedded systems, or appliances with exotic requirements as it written in the old module language. This module language is, unlike the name implies, not so modular in practice.

You will end up with a much bigger policy than strictly needed.

I wrote a base and minimal policy model that leverages the new SELinux Intermediate policy language. The minimal policy was designed for just this purpose: to provide policy to build on top of and to make as little assumptions as possible.

This allows for smaller policy that builds faster and requires less resources.

DSSP2-minimal is DSSP2-base with an addition "minimal.cil" module to make it "just" work. That means that the sole process type is made unconfined. By just excluding the "minimal.cil" module by either removing it from the makefile or by running semodule -d minimal will give you a policy with as little rules possible, and even the rules that are in there can easily be removed.

The policy is not perfect, and it requires knowledge of the CIL language to leverage it but in my view it could be an idea base for any project with exotic requirements.

https://github.com/DefenSec/dssp2-minimal


Windows Scheduled Task passwords When you create a Scheduled Task in Windows, it gives you the option of running the task as a different user, including saving the password.

How secure is the password that is stored?

I have not verified that, but the obvious way on windows would be to use CryptProtectData with CRYPTPROTECT_LOCAL_MACHINE.

At least that is the way passwords are stored in SQL Server Management Studio... reversable... ;-)


Custom EXE Template Metasploit 64-bit ASM PE Syntax I asked this previously then deleted since I think I asked the question without gearing it towards msfvenom and custom EXE templates.

There is a 64-bit Windows PE written in assembly that ships with Metasploit that I am trying to compile to an EXE and use as a custom template for msfvenom. How do I compile/link/include windows DLL in Kali? I have Mingw installed.

I have tried this:

nasm -fwin64 -o 64exetemplate.o 64exetemplate.nasm

Then tried to link with Mingw like :

86_64-w64-mingw32-ld -o 64exetemplate.exe 64exetemplate.o

How do I get the asm to compile/link? I think there is a path to kernel32.dll missing and I am not sure of the syntax.

Both give errors. From the previous question, I understand I need to tell Mingw/gcc where the windows DLL or kernel32.dll are?

root@box:/ nasm -f win64 64exetemplate.asm -o tiny.o
64exetemplate.asm:7: error: parser: instruction expected
64exetemplate.asm:8: error: symbol `extrn' redefined
64exetemplate.asm:8: error: parser: instruction expected
64exetemplate.asm:12: error: parser: instruction expected
64exetemplate.asm:26: error: symbol `main' redefined
64exetemplate.asm:26: error: parser: instruction expected
64exetemplate.asm:28: error: parser: instruction expected
64exetemplate.asm:29: error: parser: instruction expected
64exetemplate.asm:30: error: comma expected after operand 1
64exetemplate.asm:31: error: symbol `payload' redefined
64exetemplate.asm:31: error: parser: instruction expected

root@box:/ x86_64-w64-mingw32-ld -o 64exetemplate.exe 64exetemplate.o
64exetemplate.o:(.text+0x1d): undefined reference to `VirtualAlloc'
64exetemplate.o:(.text+0x3d): undefined reference to `ExitProcess'

Original assembly file that was used to create the 64-bit Windows portable execution.

; Author: Stephen Fewer (stephen_fewer[at]harmonysecurity[dot]com)
; Architecture: x64
;
; Assemble and link with the following command:
; "C:\Program Files\Microsoft Visual Studio 9.0\VC\bin\x86_amd64\ml64" template_x64_windows.asm /link /su$

extrn ExitProcess : proc
extrn VirtualAlloc : proc

.code

        main proc
                sub rsp, 40        ;
                mov r9, 40h        ;
                mov r8, 3000h      ;
                mov rdx, 4096      ;
                xor rcx, rcx       ;
                call VirtualAlloc  ; lpPayload = VirtualAlloc( NULL, 4096, MEM_COMMIT | MEM_RESERVE, PAGE$
                mov rcx, 4096      ;
                mov rsi, payload   ;
                mov rdi, rax       ;
                rep movsb          ; memcpy( lpPayload, payload, 4096 );
                call rax           ; lpPayload();
 xor rcx, rcx       ;
                call ExitProcess   ; ExitProcess( 0 );
        main endp

        payload proc
                A byte 'PAYLOAD:'
                B db 4096-8 dup ( 0 )
        payload endp
end

Again, I know that I asked this before (now deleted) but this is a great question for people wanting to edit the PE ASM to create custom EXE templates with msfvenom. I hope I framed this question better.

Unfortunately, there exists no single standard for assembly language files.
 (While the instructions are obviously part of the ISA, the specific syntax of the files and particularly the features like extrn are specific to each assembler.) To compile this on linux, you would need to adjust the syntax of the assembly source to use nasm or gas syntax.  The existing file is designed for MASM (the Microsoft Assembler).


Intercepting Bluetooth LE communication with an app on the same mobile device I'm thinking about man-in-the-middle attacks on a BLE connection ... normally when people talk about MITM attacks it's a separate device that sits between the mobile phone/tablet and the BLE device, which immediately limits its effectiveness (the attacker must be physically near the two devices).  Can an attacker write an app that gets installed on the same mobile phone/tablet as the real app, and somehow intercepts the BLE SDK calls and thus becomes a man-in-the-middle that is always there?

I'm writing an ionic cordova app and stumbled upon this. I'm trying to simply connect my bluetooth headset to my android and set up a SCO channel (for HFP bluetooth), but every time I do, a Spotify Service interjects and sets the connection to A2DP. It seems like Spotify wrote a service to hack the bluetooth SDK to ensure that its bluetooth connections are always compatible with its music listening service. When I delete Spotify this does not happen. So in short, yes, I believe it is possible.


Internet Explorer - Advanced Properties for Trusted Root Certificates If you go to IE -> Internet Options -> Content -> Certificates -> Trusted Root Certification Authorities.

Now Click on some CA certificates and click on Advanced

You can add properties to the certificate. What exactly is this for?

Does this mean that if a certificate doesn't have 'Server Authentication' property, the client can still authorize it for that purpose if he chooses to do so?

Is this a security issue - i.e. can you you write an ActiveX control or Applet on which if a user clicks, it will turn on this property?

No. The dialog doesn't add these properties to certificates. It has nothing to do with the currently selected item – it merely adds them to the filter-by-property listbox at the top of the main window. (That's the one that says "Intended purpose: <all>".)

(The more specific name is a "certificate purpose", and the technical name is extendedKeyUsage aka EKU.)

Basically, if you check "Client Auth" here, you can easily filter the cert list for just those which have this usage permitted.

But

You can, however, find a very similar list in the information dialog of individual certificates, under the View button. It does allow removing specific usages, or – I think – adding new ones.

For example, if you have a cert with both "email" and "client auth" purposes, but only use it for email, you can use this to avoid clutter whenever your browser asks you to choose a client-auth cert.

I suppose this could be used for trusting server certs that lack the "server auth" purpose – although it would be somewhat incompetent for a server to even use such a cert...