Your understanding is broadly correct, but in security and especially in cryptography, “broadly correct” often doesn't cut it.

There is a standard for encryption using elliptic curve cryptography to encrypt data, called ECIES (Elliptic Curve Integrated Encryption Scheme). (IES can be used with other key agreement methods, but only elliptic curves give it practical advantages over RSA — faster decryption, smaller keys.) The procedure is as follows.

Alice obtains Bob's public key on the selected elliptic curve.
Alice generates a random key pair on the selected curve.
Alice calculates the shared secret for Bob's key .
Alice passes the shared secret as input to a key derivation function (KDF).
Alice uses the output of the KDF as a key for symmetric authenticated encryption.
Alice sends the resulting authenticated ciphertext and her public key generated at step 2 to Bob.

The KDF step is important because a shared secret generated with ECDH is not uniformly pseudorandom. An attacker may be able to get partial information about it by simple mathematical observations (for example, the shared secret is a number between 1 and N where N is not a power of 2, so the highest bit is biased towards 0), by conducting key agreements with Alice using a series of intelligently-crafted keys, or by observing side channels from the ECDH computation. Partial information about the key can allow a related-key attack on the symmetric cipher. Passing the shared secret to a KDF “scrambles” any mathematical relations in the output.

In RSA-based hybrid encryption, the same symmetric key is never generated twice because it's generated at random. In ECIES, the same symmetric key is never generated twice because it's derived from an elliptic curve key that is generated at random.

The calculation of the shared secret is exactly the ECDH calculation. It's sometimes known as “ephemeral (elliptic curve) Diffie-Hellman” because the private key is single-use. Ephemeral and non-ephemeral Diffie-Hellman are the same algorithm, what “ephemeral” means is that the key is used only once.

From a cryptographic point of view, the output of the KDF can be used to encrypt more than one message. (But always with the same algorithm. Using the same key for two different algorithms, e.g. for both AES-GCM and AES-CCM, or for both AES-GCM and Camellia-GCM, could be anything from a subtle weakness that reduces the security by a bit and a half, to a catastrophic weakness that makes it easy to recover the encrypted message.) After all, if you have a symmetric key, it doesn't matter how you got it. Whether you'd want to do that is an operational matter: how much of a risk is there that Alice or Bob will accidentally leak the symmetric key? How much of a risk is there that Alice will generate the IV incorrectly for the symmetric encryption step? If you aren't worried about these risks then you can treat the symmetric key generated from the shared secret like you'd treat any other shared key, minus the problems of distributing this shared key.

Alice can perform the shared secret generation with the same inputs more than once if she wants: she'll get the same output each time, so that won't provide extra information to an attacker. The danger if Alice reuses the ECDH key is that this creates more risk that the key will leak, either from storage or through side channels.

It's even safe for Alice to use the same key pair to communicate with more than one party.

Just because everything is safe in principle doesn't mean it's a good idea. The more you leave a key lying around, the more risk there is that a partial compromise will reveal this key.

A common reason to reuse the ECDH key is to put it in a high-security piece of hardware that will perform operations with the key but not reveal the key itself: smartcard, secure element, HSM. However, this is useful for Bob, not for Alice. Bob needs to somehow send his public key to Alice in a way that Alice will trust, and after that he needs to hold on to the key. On the other hand, there is no strong advantage for Alice to reuse her ECDH encryption key, since she'll send the public key as part of the message.

A valid reason to reuse the key is if you have stringent constraints on message length. It lets you save about 65 bytes (size of an uncompressed point representation on a 256-bit curve) can be useful.

Performance, on the other hand, is not a strong reason. Generating an EC key is extremely fast: it's just a uniform bit string of the right length (this is unlike RSA where key generation is very expensive). You need to add the time it takes to calculate of the public key, and that's basically the same calculation as the ECDH calculation. So setting up ECIES-like encryption with a stored key instead of generating the key only divides the time of the asymmetric-cryptography part of the computation by two.

Finally, note that even if you reuse the EC key, you can still derive as many symmetric keys as you want. The KDF step takes an optional extra input which can be public. This extra input is variously called a salt, a label, an info string or various other names. You only ever get the same KDF output if both the secret input and the salt are the same.


What is the power of my ISP about my modem?

How they can claim this.

The ISP has control over your VDSL connection since the ISP is one end of the connection. They can determine if the problem is caused by the VDSL connection, for example because there are too much errors on the line etc.

Given that the modem is provided by the ISP they have often also some kind of access to it (depends on the ISP) and might get additional information from it, like the signal strength of the WiFi connections between your systems and the router.

  If I don't change my modem they will see it?

It is unclear if you are allowed to change the modem in the first place. Even if you can they might refuse to provide deeper support if you use your own modem since they are unable to get some details to debug connectivity problems if they don't get access to the modem.

Anyway, they can at least find out if the problem is the DSL connection itself since they have control over this connection. They can find out if any problems with the DSL connectivity might be caused by the modem or by a bad line. If they don't find any problems with the DSL line they can conclude that any problems you report are likely originate on your site, i.e. bad WiFi connectivity or similar.

  What else information then can get from my modem?

This depends on how much they manage the modem. In the worst case (full control of the modem) they might in theory have access to your internal network.

  if I use a modem not provided by ISP, this will reduce the access?

Since it is unknown what level of access they have know (and what level of access they need to support you) it is unclear if the situation gets better if you buy your own modem. But if you choose the right modem you might get at least more visibility and more control of what your ISP can do.


This is knows as Wp-vcd Malware. For full analysis you can check here.

For hardening Wordpress check here, and if you ask yourself, what should you do when your website is hacked - click here.

For removing that particular malware follow this.

More from IBM X-Force Exchange:

  Malicious code injection inside a wordpress theme's functions.php and
  wp-includes editing posts content.

  Injected files:

wp-vcd.php
class.wp.php

  Edited files:

functions.php
post.php

  Analysis

  https://medium.com/@cirku17/wp-vcd-malware-analysis-7c5dbaad89c3

  Repository

  https://github.com/CirKu17/wp-vcd-malware-sample

Keep in mind that this may be updated version of malware, so I didn't go through all the source - my suggestion for you is to backup your website and database from clean backups.


What do the terms used in OpenPGP keyserver SKS mean? (sig, sbind, sig3, exp2, Policy, ...)

In OpenPGP, signatures are used not only for documents, but also for certifications between primary keys with different levels of trust (sig, sig1, sig2, sig3; as hex codes 0x10-0x13 in this order) and several more internal stuff.

Signatures are also very important for binding subkeys to primary keys (and the other way round): these are displayed as sbind signatures by key servers, and a simple sig by GnuPG, and have signature types 0x18 and 0x19 in OpenPGP. User IDs are bound by "normal" certification signatures, also called self-signatures or selfsigs.

If for any reason you want to undo a signature, this is generally not possible (you cannot delete anything from the key server network). Instead, you again issue another kind of signature, a revocation of a key (0x20), revocation of a subkey (0x28) or revocation of a certificate (0x30). All of those will be displayed as revok by most key servers, and rev by GnuPG.

A certification policy displayed with the key word Policy drops out of this list, a little bit, as it does not denote another signature type, but is a signature subpacket describing a so-called certification policy. I already left a more detailed description in "What are you saying when you sign a PGP key?". Notations also describe a certification, and could for example be used to describe how the signer identified the signee.

The signature types are defined in RFC 4880, OpenPGP, 5.2.1.  Signature Types, signature subpackets only a little bit further down in the same document.


Is this ISP IP address assignment issue a vulnerability?

I assume this is a DOCSIS cable ISP. It can be a bit of a security issue. It's just like having an IP address conflict on a LAN. DOCSIS cable can use ARP just like a LAN. If that IP address that you assigned is also being used by another host on the network, then that other host will loose connectivity while your host is working. You could host services that trick users in to connecting to you instead of the other host, or you could obtain some incoming packets that are intended for the other host.

A bigger concern is if baseline privacy (encryption) is enabled on the cable network. If it isn't, then this issue probably not important compared to that.


It seems that SHA256WithRSA "implies the PKCS#1 v1.5 padding algorithm [RFC3447]"

See RFC4051, 2.3.2.

Sources : bouncycastle , crypto.stackexchange


Preventing a Computational DoS Attack in Public Key Cryptosystems

It will take a long time doing useless computation.

One could conceivably use a designated-verifier non-interactive computationally

zero-knowledge argument that the rest of the message is well-formed.

More usefully, use proofs of work and PKE with fast decryption.


If Cloudbleed affected a site that uses Facebook login, do I need to reset my Facebook password?

When logging in with Facebook your password is only sent to Facebook and not to the web site where you log in. The site where you want to log in asks Facebook who you are, and Facebook provides the site with some information and a secret token. Anyone who has this token can impersonate you on the site.

So your Facebook password has not been leaked, but your token may have been. To revoke the token, you can revoke the access the application has from within Facebook.


What is spam and what is the difference when compared to direct mail?

The main difference is permission. Spam emails (or unsolicited emails) are sent without any permission, and are generally evocative in some way.

Direct emails are those that, while resembling spam in some ways, are sent to you with your permission. They generally inform you of a new product, event, or look to gain some sort of information for statistical purposes that have to do with a service you subscribe to.

While you may not recall giving a certain company/service your permission, this permission may have been given during an application installation, or through a web-forum registration, for example. With direct mail, they will generally give you the option to decide whether or not you wish to receive emails from their sales/marketing teams, before or after the fact.

Direct mail = not bad, received with permission, can be annoying.

Spam = malicious, received without permission, annoying.

As a little addendum, if you are referring to direct mail in the sense of physical mail, like that your neighborhood postal worker would deliver, the differences are obvious, and have nothing to do with security (unless you've got a nasty war-driving postal worker in your area).


OAuth: Long running access in downstream systems - how to refresh token?

Well, the simplest approach is to just push the refresh token down to App B as well and let it handle refreshing itself. This could lead to some unintended behaviors on App A though if the refresh token is refreshed on refresh as well (say that 5 times).

What you might consider doing is adjusting the authorization server to exchange an access token for an access/refresh token pair, so App A sends it's token to App B, and App B takes that token and exchanges it with the authorization server for it's own tokens. Then it manages the token on its own. That assumes you can modify the authz server though.


Importance of password strength with secure element?

The usual computations on password entropy take place in the context of a dictionary attack, especially an offline dictionary attack, where the attacker can try passwords at will without locking anything. When there is an auto-locking tamper-resistant hardware, the context changes.

Conceptual view: there are N possible passwords (to simplify the exposition, I suppose that the possible passwords are equiprobable). The attacker may realistically try K of these passwords. The attacker's probability of success is then K/N. Security is ensured when that probability is sufficiently low that the attacker finds it not worth the effort. Let's arbitrarily set that threshold at 1/1000: if the attacker's probability of success, after (say) one week of cracking efforts, is still only one in a thousands, then he will decide to spend his time on something else (e.g. buying lottery tickets).

When the attacker can obtain a hashed version of the password, K will range from millions (if a good password hashing function like bcrypt was used, with enough iterations) to millions of billions (if a poor password hashing function was used, e.g. a single SHA-1 invocation). To achieve our 1/1000 threshold, N will have to be in (at least) the billions range.

With a device that autolocks after 10 wrong tries, K = 10. The threshold is reached with N = 10000, which is a very small space of possible passwords; you get that with a four-digit code. This is how such an autolock feature makes small/easy passwords satisfyingly secure.

Credit cards with chips do that (usually with K = 3).


What should students learn about security in an introductory programming course?

Security education should be contextual. There's not a lot to say about security when you're studying red-black trees or merge sort. But security should be a constant and pervasive factor as part of everything the student does.

Any security-related items should be required as a matter of course; bounds-checking and input sanitization, for example, should be absolutely required in all assignments. If the examiner can break the homework application by supplying invalid input, then points should be deducted. If array bounds aren't properly checked (assuming an unsafe language like C), then points off. It should't be sufficient to just have the thing pass the assigned test-case, it also has to be well-enough written that in a real-world scenario it wouldn't cause a disaster.

The students need to be used to always worrying about robustness and security the same way that chemistry students always should be worrying about lab safety. Security isn't something you study one semester and then move on.

If you're going to have a single lecture at the beginning about security, then it should primarily cover the security-related expectations that the students will be under. These expectations should be real-world expectations with respect to coding practices and should reflect the sort of vigilance that is always in the back of the mind for a good programmer.

This breaks down into several main areas, not all of which are appropriate for every language and every programming environment, here are a few that come to mind:

Language safety: An extremely big deal with C/C++, not so much with most everything else. Pointers, buffers, and that sort of thing fall into this category.
Input sanitization: Huge. Absolutely huge. I can't think of a single area in which this is not applicable.
Code clarity and documentation: Worth more than it sounds like. Many security vulnerabilities come from simple mistakes which stem from a misunderstanding of the code itself. The fewer mistakes you make, the better, even in the context of security.

Also, I'd throw in principles like "DRY" into this mix, since security vulnerabilities sometimes are the result of assumptions being out-of-sync within the code. The more places you specify a single value, the more likely you'll forget to change one of them, which can lead to security vulnerabilities. I remember a "no magic numbers" homework rule when I studied CS, where all numeric constants had to be assigned a name. It's a good policy to have for many reasons.
Privilege isolation: A bit more esoteric, but important in certain scenarios. The principle of least privilege is something that students need to at least be familiar with, for example; but it's difficult to make part of your day-to-day activity.
Security-specific items: Such as password storage, encryption, and stuff like that. This is more informational than directly applicable with respect to schoolwork, so I'm not sure where it fits in with respect to lesson scheduling.

It's important to learn about attacks like CSRF and token-stealing
attacks in the more abstract sense, but probably not in an
introductory course since it's a little advanced.


It depends on server configuration.  If you configure the site to have the user authenticate with the server itself, then you can have the server use the users permissions and they will only be able to access resources that the user has access to and you can deny them to non-authenticated users.

If the authentication is instead a session level authentication that is implemented in a scripting language like PHP or such, then the server won't know if the assets should be provided and it would be up to your scripts to decide what to serve.  If the static resources are only protected by the URL being unknown, then they could still be accessed with the latter approach.


Legal Requirements

They are not allowed, in a lot of cases.  As a result of the GDPR and similar legislation in other territories, companies are no longer allowed to siphon that data without permission even when it is just an anonymous identifier and websites are expected to give the user control over where data is sent.   This has the problem that the onus is on those collecting the information to obey the rules and assumes that those rules apply to them, which they may not.

Technical Measures

Browsers can optionally include a 'Do Not Track' header which signals that the user does not want tracking data to be collected.  There are growing calls for browser makers to abandon DNT as it is routinely ignored by apache servers for browsers where it is enabled by default.

P3P was another attempt to implement browser-side privacy processing.  However development stopped on this some years ago due to a lack of support by browser makers.

Browser plug-in tools like Privacy Badger can block known tracking sites/links, but those only apply to browsers and puts those seeking privacy in a position where you need to know every URL that you need to block, and in some cases can degrade the user experience.  Browser plug-ins do not affect Apps on mobile and embedded devices.

DNSBL tools like Pi-hole can currently be used to block sites at the network level but this is a less than ideal situation because it requires an exhaustive list of sites to block and again can interfere with the user experience.  With moves towards encrypted DNS (via TLS and HTTP) this avenue is likely to become decreasingly viable in the future.

VPNs and similar tools like TOR may go some way towards hiding your personal/tracking information, but to be effective they require a significant amount of operational security for the user and again significantly degrade the user experience.  Such methods require rigorous OPSEC and discipline in many cases.

Bad actors

All the measures listed are of limited value in the case of companies who act in bad faith.

A prime example of this is google; their CEO (Eric Schmidt) said in 2010, "We know where you are.  We know where you've been.  We can more or less know what you're thinking about." and the company has an established track record of committing (and getting away with) large privacy breaches including...

slurping personal data from wireless routers
bypassing P3P processing
"forgetting" to mention that some nest products have built-in microphones

With a company like google acting in bad faith, it makes life particularly difficult to maintain privacy as blocking sites like googleapis and google fonts leaves users with a severely degraded experience on the web as a significant number of sites rely on their content and they are by no means alone.

tl;dr - privacy is not being respected and there aren't any silver-bullets to enforce our rights at present.


Not really. It's essentially one password, with a press of the return key as one character.

It adds complexity to the log in process, which isn't generally a good thing (users would probably choose one good password, and one quick to type password). Don't forget @AviD's rule: "Security at the expense of usability, comes at the expense of security"

Depending on how the passwords were stored, they would slightly decrease the ability of attackers to brute force accounts, since an attacker would need to break both parts. I doubt that this balances out the usability issue though.


Antivirus monitoring activity: why do they not have an internal firewall to prevent processes' access to user's documents?

More Dates Data ... svchost.exe when it tried to access DataDefinitions at Norton's install folder. It seems a very clear activity of a trojan, doesn't it?

svchost is a process which is used for lots of different things. So it might be an infection or it might be not. And it is not even clear that the infection happened only after Norton got installed. The system might have been infected before. Once you have an infection on the system you cannot be sure how it behaves any more, that is even an antivirus installed after the infection might be fooled by the malware.

  Do antiviruses have any chance to agree with Microsoft Corporation a system to detect abnormal activity?

To detect abnormal activity you first have to define what normal activity is for each of the applications you have and each one you download. Then of course you would have to read this description for each of the applications you install and you fully have to understand what it means. And only after you accepted what the application can do it should be installed.

Because this can probably not expected from the common users systems like Android have some kind of manifest which shows the kind of information an application likes to access. Even though that is much simpler than what would be needed to classify abnormal behavior it still is too complex for lots of users so they simply grant all rights to some random application.

Apart from that you would probably grant access to all files to a Backup application since that is what such kind of application needs - otherwise no backup and restore would be possible.

  How is it possible that this program with the trojan, MyPC Backup, was installed in my computer just after Norton Installation and that it has been, precisely Norton what finally detected it as a trojan?

Malware is changing fast and antivirus solutions only play catch-up. Thus it might miss one thing today and find it tomorrow after the malware was seen in the wild and antivirus signatures got updated after that. You can be lucky that it got detected at all, even after infection.

  If there was abnormal activity of a process trying to access Norton's definitions (svchost.exe), ...

Again, it is hard to know what abnormal means for some random application the user decided to download.

Also all the other question you have repeat the same thing: you expect some antivirus to be aware of any current and future dangers and you expect it to know what a normal behavior of any random application is. These expectations can not be fulfilled since malware gets tested against the antivirus solutions by the authors of the malware and they tune the malware long enough so that they bypass these protections. The antivirus vendors then tune their solutions again for better protection, but only after they've detected the new malware - which usually means that lots of users already got infected.

If you install any kind of software you should not believe the advertised behavior. This is true for some free software downloads which often gets bundled with adware or even malware. But this is also true for antivirus where the vendor claims full protection. This is a promise which can not be fulfilled.


Can biometric vectors (i.e. fingerprint vector) be considered as Sensitive Authentication Data (SAD) in PCI?

I'd say no. SAD is information relied on by the card issuer to authenticate a transaction. So PINs/PIN Blocks, full track data and CVC2 are all placed on the card by the issuer (OK, that is simplistic for PIN) and only used by the issuer to validate the card and the customer during the authorization process.
The table on P7 of v3.2.1 of PCI DSS is the authoritative reference, the glossary is not normative.
However, technically you are a service provider to the processor, and they may require you to comply with PCI DSS as a contractual measure because that what allows them to be comfortable about your security, whether or not it strictly applies from a card brand perspective.


It's simple enough.

They run a batch job that checks every password in the leaked list and yours matched.  That verification is done exactly the same way as when you manually sign in.

As you can see, they then reset your password and notify you.


'Critical security alert for your linked Google Account ' but I don't recognize the account

FYI, I can link my Google account to yours. I just need to add your email to my account as a linked account. No maliciousness required. I get them a lot because my Gmail address is so generic, people mistakenly use my address by mistake.

Can malware open your browser's password file? Yes.

Can you see who has added your email to their linked accounts? I do not believe so.


Become domain admin by controlling an OU in Active Directory?

Should be straightforward enough;

As OU administrator, reset the domain administrator's password (as he
is in your OU)
Now you can log in as the domain administrator (you know the password
now)
Configure your account to be a domain administrator (as you're
currently authenticated as a domain admin).


Everybody is using OWASP these days or some standard based on it.

https://www.owasp.org/index.php/OWASP_Secure_Coding_Practices_-_Quick_Reference_Guide

Just to note, most of the security must be done on the server side. I.e. the data validation and sanitation, enforcement of the security of communication channels, authentication, authorization, and many many more. Only trusted libraries should be used and the code written should be reviewed by independent developers to prevent intended back doors.

Regarding the client side, remember to not to operate with the data you don't need on the client side at all (or encrypt them securely on the server side - i.e. session data/view states) and discard any sensitive or confidential data you don't need anymore immediately. If you use some sensitive or confidential data on the client side (and you obviously do, usually it is a session token and some kind of credentials), make sure you use the most secure methods available to store and transfer them but this hardly depends on the technology in use on the client side.

Of course, don't forget to protect the communication channel between client and server with some kind of encryption.

OWASP will tell you more.


What security factors should I take into consideration when selecting a bank?

If you want a secure account look at yourself not the bank. Banks rely on insurance to secure deposits, their security is there to keep the premiums low and the insurance will take care of anything that gets past.

However if someone gets into your account via identity theft then the insurance will not cover the stolen funds. Therefore if you want a secure account you should detach it from yourself as much as possible.

You can use a few techniques to separate yourself from this account:

Don't carry a cash card for the account (and definately not a contactless one) - It's much more likely your card will be skimmed than your bank will be broken into by a l33t hacker
Opt out of paper statements - Can't forget to shred what you don't have
Route pay slips and bills to another account and pass through funds with direct debit - This way the accounts that hold most of your funds will not appear on other systems or on related paper work.


Determining a version of SSH from penetration testing?

It sounds off that a service provider will not give you details of the product/service you are purchasing. That is like a contractor not telling you what wood he is using to build a house. I would remind your service provider that "security by obscurity" will not help a remote attacker from figuring our or just launching attacks against all versions of SSH.

You should check to see if you have a "right to audit" in your service contract, as that might give you the right to know this information (always try to get such language in your service provider contracts)

Do you have command line/shell access? If you do, you could try to check the version yourself.

In terms of the pen testers getting the wrong version, its entirely possible. Depending on the checks they ran (probably automated through a vulnerability scanner), certain characteristics may not give a 100% match. It's also possible to configure/compile your applications to lie about their versions, change banners, or for some intermediate proxy or load balancer to change this information.

However, it sounds like a red flag from the service provider that they will not release this information. You may want to let them know how important security is to your organization and that lack of sufficient security assurances could lead to taking your business elsewhere.


What happen when a local device have the same IP as an external website

The short answer is no, this would not happen.

The reason is that if you change the IP address of a machine to say $172.217.20.28$ (the result i get when doing a DNS lookup for google.com), the machine would belong to a different subnet and therefore not be visible to other machines on the physical network.

An IP address consists of two parts: a network identifier and a host identifier. The $n$ most significant bits specifies the network part and the $32-n$ (for IPv4) least significant bits specify the host, where the number $n$ is given by the subnet mask.

Suppose the machines on your network use a subnet mask of $255.255.255.0$ then the $24$ most significant bits of the IP address specify the network, meaning that only machines that have IP addresses that are identical in the first $24$ bits are considered to be on the same network.

For further info i would suggest reading about subnetworks and routing .


Accessing over a VPN both sites that know your real identity and sites you want to stay private from

Is it a bad idea to access over the same VPN both sites that know your real identity and those that don't?

From a hyperparanoid perspective yes. You will likely have the same visible IP for both sites. Whilst usually you would expect other users to be present at the VPN IP it still makes pairing up your requests easier.

  What kinds of attacks could expose your identity to a) the anonymous sites, b) the attackers?

Two obvious ones -

Browser Fingerprinting. This is surprisingly accurate - https://amiunique.org/
Packet matching. I.e. someone with wire access to traffic entering and leaving the VPN can use statistical methods to pair the packet you send into the VPN with the packet leaving the VPN for the remote server (and vice versa).


Is this phishing? How can I be sure? And what can be gained?

This appears to be valid. No single fool-proof answer exists, but it appears valid and safe for the following reasons:

You were expecting it from them. While it's possible someone trying to spearphish you knew this, it is one of several positive indicators. This alone is not enough, however.
The domain headers check out and having a generic email (resumes1@company.com) is very common. See #4.
The URL checks out when hovering over it.
There is about a 90% chance someone is reviewing your resume and position from software like taleo or brass ring, which means the email sent will almost certainly NOT originate from their actual email. Probably a dozen or so recruiters share said software, so having it tailored to a specific Email signature is highly unlikely and the signature you received would not be out of character. It's also not uncommon (although it is unprofessional) to have several fields that are supposed to be filled out NOT filled out, leaving a generic term in it's place. Additionally, in a large, well-developed company it's not out of character to receive form letters with $variable_job posting that is filled in on the form letter. This is far more efficient for recruiters to work within their software - just like a salesman has an easier time integrating his email with salesforce than custom writing each email for each invoice.
A 3 hour delay does not necessarily indicate any serious risk. If it's a medium or large business (or poorly configured) the website may "batch out" emails or spool up several at once at a pre-determined period of time (e.g. every 3 hours). There are also other reasons an outgoing email may stall, without being risky.
Replying to an email will not get you "phished." Clicking on links will, or replying with PHI/PII will - but responding that you'd love to move forward and are excited for the opportunity poses no risk.

Anecdotally, I  have been involved with phishing campaigns on the security side, and nothing is raising my hairs.

If you are ever unsure, it's still always best to open an attachment or click on the link in a sandboxed environment.


When paying online with a credit card, what is "3D authentication" and is it reliable?

From Wikipedia:

  3-D Secure is an XML-based protocol designed to be an additional
  security layer for online credit and debit card transactions. It was
  developed by Visa with the intention of improving the security of
  Internet payments and is offered to customers under the name Verified
  by Visa.

NOTE that your link is garbled, it might be that he is trying to redirect you to a fraudulent site adding a link into an html form  to make  you think you are going to your bank's website, but instead you are being redirected to a phishing website.

In your case they want you to go to: https://acs.onlinesbi.com/sbi/enrollment/enroll_welcome.jsp

But they seem to add something to the front which might redirect you to another website.

If you are indeed redirected to this website, check the URL and verify the certificate:

If you are not a customer of the SBI or you are not being redirected to this website with a valid certificate for the SBI as shown above then I would not continue anymore.


What you've heard is not accurate.  CBC is secure, if used properly.  OpenVPN does use CBC mode correctly.  Generally speaking, OpenVPN is very well designed, and you shouldn't need to worry about this.  You shouldn't need to change the default settings for cryptographic algorithms.

In fact, CBC mode is the default mode of operation for OpenVPN, so you do not need to change anything; you can just stick with the defaults, and I recommend you do so.

OpenVPN also supports CFB and OFB modes, but those modes have no advantages over CBC mode (and OFB mode has some potential disadvantages).  Therefore, I think OpenVPN's default of CBC is a reasonable and sensible choice.

OpenVPN supports many symmetric-key algorithms.  The default is Blowfish, bu tit also supports DES, 3DES, DESX, RC2, CAST5, AES, CAMELLIA, and SEED.  Blowfish is a fine choice.  AES would be arguably the more conservative, conventional choice, but frankly either Blowfish or AES is fine.  I would definitely avoid single-DES (or anything that is listed as a 40-bit or 64-bit key), and I would try to avoid RC2, CAMELLIA, SEED, CAST5, and DESX if I could -- but this is a detail.  In any case, OpenVPN's defaults are fine, so I suggest you just stick with them, rather than try to tweak them.

A comment for the future: If you want us to comment on a recommendation from someone else, it helps if you can link to the primary source.  (You didn't tell us where you got the recommendation to use CBC mode in OpenVPN.)  This time I was able to work out what you meant, but for the future, this might be helpful if you post other questions.


XSS echoed in pages html code but no pop up window

With an XSS attack you normaly try to put JavaScript Code on a website.

In your example a user tries to log in and on the next page there may be a warning like 'Username [input string] is not valid'.

Now if you try to log in as alert(‘XSS attack’) it would not be considered as a xss attack because the browser doesn't even recognizes your input as JavaScript - it is just an ordinary string. The example warning from above on the page will look like this:

'Username alert(‘XSS attack’) is not valid'

But if you enter something like this:

<script type="text/javascript">alert("XSS");</script>

the browser will recognize it as JS, and likely evaluate it. The warning would look like this:

'Username  is not valid' (this is because JS will not be shown on the page)

Conclusion: Only by sing the script tags you will get a browser to recognize a string as JavaScript and therefore only with these tags your popup will show.

Update:

As your comment states, the input will only be printed in the value of the textbox, the approach won't work, as textboxes escape the values automatically.

But you could try this as username: " autofocus onfocus="alert(1), so the box markup will change from this:

<input type="text" name="loginidtextbox" value="" autocomplete="off">

to this:

<input type="text" name="loginidtextbox" value="" autofocus onfocus="alert(1)" autocomplete="off">


Why is the first step for an attacker to get Reverse Shell after getting RCE?

Remote code execution means you have successfully executed some specific code on the server. It does not mean you can execute anything else on the server, yet. The solution is to have the executed code make a connection back to you and allow you to send more commands for it to run. That's what a reverse shell is for. Without a reverse shell, you'd potentially have to re-exploit the server with a new payload over and over for each additional command you want executed. That would be a royal pain.


Can a steel woven wallet prevent RFID scanning of credit card information?

Any Faraday cage will do the trick. So a shielding of just about anything conductive, be it aluminum foil, conductive paint, wire mesh, or any of a number of similar alternatives is going to be opaque to radiation. That means no radio waves in or out, which means the RFID signal is blocked.

Note that the size of the mesh has to be significantly smaller than the wavelength in question; RFID specs are mostly in the MHz range but go as high as 2.4GHz, which is about a 10cm wavelength. So your mesh should be just fine. But aluminum foil is cheaper.


RBAC: how to separately scope two resources that have a many-to-many relationship

Your data model looks like a graph. Contact --- assigned to --- File, and vice versa. So the assignments are links (edges) in the graph.

I am assuming that there can also be multiple contacts assigned to a single file or multiple files assigned to a contact. How would you handle deleting a contact that is assigned to a file which is assigned to another contact? If you delete a contact which would delete a linked file, then that would leave the other contact "hanging".

I would suggest to treat the assignments i.e. the links (edges) as a scope as well that could have create, destroy, update permissions. Give roles permissions to assignments as well.

You need to make sure that for a contact or file to be destroyed, it should not have any links (assignments) to other file or contact. This will prevent the "hanging" situations described above. So a node can be destroyed only if it does not have any edges.

If a user tries to destroy an object which has links to other object, then throw an error such as "Cannot delete contact which has assignments to other files. Delete the assignments first".

Now, you can assign the CRUD permissions for assignment scope to the Clerk and Contact Manager roles. If a Contact Manager tries to delete a contact with a file assigned to it, then they need to destroy the assignment first (for which they have the destroy permission). Once all the file assignments to that contact are destroyed, the contact can be destroyed. The responsibility of deleting files is anyways with the Clerk which can be deleted provided it does not have any contact assigned.


How to address bad password security policy from a large company?

If they process payments via credit card, they must maintain PCI-DSS compliance. You could always report a violation. They could potentially send an auditor and insist on remediations. The whole process would take probably a year or more. It would not surprise me if they are already working on it, assuming you have found a bona fide issue.


Overwriting return address of main function

Just a rough description for now as I don't have much time. The general idea is to determine the address of the target function as well as the exact position of the return address on your stack.

If you want to overwrite the return address you first need to find the correct position. To do so you will probably want to debug the program, set a breakpoint to the last possible step in your main function and watch the registers change by stepping single instructions from there. A brief hint: If you open the program and subsequently put a 1 Byte longer string into it every time it launches: you can watch it crash at some point. Assuming there is no stack canary or shadow stack or whatsoever you will have found your target address. You could (while debugging it) e.g. feed it a lot of 'A's and watch for 0x41 in your Debugger.

Next thing is to determine the address of your target function. Its pretty straight forward, you can e.g. try info symbol with info address.
After that it all comes down to (in the easiest case) writing garbage (e.g. 'A') on the stack until you reach the adress of the RIP (Return Instruction Pointer) and then write the new adress you want into it.

Also do read a little about EIP/RIP, and Stack Overflow on wikipedia and others.


SSL is not expensive by itself. When implementing site-wide SSL for Gmail, Google found it to increase CPU load by about 1% and network load by about 2%. Of course, not every site is Gmail. Biggest costs about SSL are:

You have to manage a server certificate. The buying fee is small, much smaller than the administration time anyway, and it won't get far.
Transparent proxies (as employed by some ISP) won't be as efficient (but that's their problem, not yours).
The initial connection to your site is a bit longer (but we are talking about a one-shot sub-second delay here).

There is a widespread myth about how encryption is necessarily expensive, and that's just that: a myth, i.e. a much deformed piece of information from much older times. A basic server will support 100 MBit/s SSL with less than 10% of a single CPU core. In 1996, when a server could be a 33 MHz 80386, SSL could be viewed as expensive, but this was quite some time ago.


It mostly depends on the type of VPN you use, how it is setup and how you use it.

Generally speaking, if your VPN is setup to process all your connections then the attacker will see the initial handshake and then only encrypted data (and some management traffic, from time to time).

So, someone sniffing the network between you and the VPN host will not be able to see what web site you're accessing, what DNS requests you make or anything else.

This, however, relies on a few critical elements that are not always guarantee:

The client you're using is secure and properly configured.
The attacker does not have any control on any part of the infrastructure you're going to use outside the network he's snooping on (specifically, he does not control the DNS server you're using - which might or might not be provided by your VPN or any other host you're accessing through your tunnel).
You connect to your VPN provider before doing any browsing and keep using it all the time afterward until you terminate the session (it's easy to leak information when web sites can do requests in the background and when browsers might be setup to restart your previous session on startup).

Also, be aware that it's possible to setup a VPN connection only to secure data that goes to a specific network. In that case, most of your traffic will actually be unencrypted.


+1 for Yoav Aner's comment.

I don't have any particular experience with the questions you asked, but it seems like designing such a system from scratch without any prior knowledge and experience will only lead to trouble.

Is there are particular reason you do not want to use premade tools?


The nature of the CVE-2015-0235 makes it impractical to scan remotely. The glibc library is used by many applications which may or may not be exploitable depending on what parts of glibc they use.

Your best bet is to identify which of your systems (they are your systems right?) are using the outdated version of glibc and patch accordingly. Consult with your distribution's maintainer to identify the packages and versions impacted. If you have many systems and don't already have a central patch management system in place, you may be able to write a script to help you identify what versions you're running where.

I don't see any reason that a system behind a load balancer couldn't be vulnerable. Again, it depends on the specific applications used and the setup, but in general, this vulnerability could still be exploited on a system behind a load balancer.


The answer very much depends on the receiving MTA's configuration. However, it can (and should) be done.

Postfix has a smtpd_sender_restrictions configuration option which controls what happens when it sees a MAIL FROM message. One such configuration option is reject_unknown_sender_domainwhich validates that the sender domain has an A or MX record, i.e. the domain sends email. If the domain does not resolve, then by definition it has neither of these things and so postfix will refuse the email.

Other MTAs will have similar options.

When the receiving MTA decides to reject the email, it will tell your smtp relay server that is what happened and your mail relay will then tell you.


Password recovery tool over telnet or http basic auth

As Jeff stated, THC-Hydra is a good application of choice. I'll try to cover the basic usage for your situation.

You will need a dictionary file unless you want to bruteforce every single character possible.

In the examples change the following fields:

dictionary file: Your password file
ip address: The router
protocol: Either telnet or http-head. Incase of https just type https-head and add -S
username file: A file with a list of usernames to bruteforce

Known username with dictionary attack:

hydra -l admin -P <dictionary file> -e nsr -f <ip address> <protocol>

Known username with bruteforce attack.

Generate 3-8 char long password with both cases and numbers:

hydra -l admin -x 3:8:aA1 -e nsr -f <ip address> <protocol>

Unknown username

hydra -L <username file> -P <dictionary file> -e nsr -f <ip address> <protocol>

Ofcourse reading the manual will tell you this aswell.


How does OpenID signature work without a shared key?

According to the openid spec, a shared key is (optionally) established between the OP and the Relying Party using a Diffie-Hellman Key Exchange

Diffie-Hellman is one of the key agreement protocols which allow for two parties to establish a secret key without a third party knowing what that key is.

  The Relying Party verifies the information received from the OP including checking the Return URL, verifying the discovered information, checking the nonce, and verifying the signature by using either the shared key established during the association or by sending a direct request to the OP.

If the shared key is trustworthy, any contents modified should fail signature verification. This verification is done by the Relay Party, or web application looking to verify OpenID credentials.


What is the proper terminology and base CVSS score for the following cache related behaviour?

I believe the proper scenario for this would fall into security misconfiguration according to OWASP.And even falls into the top 10.

Top 10-2017 A6-Security Misconfiguration

I currently agree with the score. But it needs to validate other circumstances also. Such as the information that it stores. If the cache stores credit card information or any financial/personal pages then that can even increase some points 4.2 perhaps.

I would consider this a smaller score if it wasn't on the OWASP
top 10. What I mean is because it is happening a lot it should have a bigger attention. But it can be something critical if an attacker can access multiple browsers. So then again by it being easy to do makes it more critical.


Using the index of characters in a security question

In all generality, no, you cannot use such a scheme with a storage based on hashing and still expect the same kind of security as with full-password hashing as it is normally practised.

Here is the demonstration: the point of storing the hashed password, and not the plaintext password, is that you just assume that attackers may obtain a (possibly read-only) glimpse of the server's contents (e.g. with a stolen backup tape). With that copy, the attacker can emulate the server behaviour on his own machines.

In particular, the attacker can:

Start his emulation of the server.
Begin an authentication procedure with that emulated server. The server asks for, say, the 1st, 5th and 8th letters of the user's password.
The attacker snapshots the whole emulated server state at that point.
For every possible combination of three letters, the attacker restart the emulated server at the snapshot point, enter the three letters, and see if the emulated server is happy or not.
Once the attacker has found the right combination of three letters (there are only 26×26×26 = 17576 combinations of three letters, which is really few for an automated attacker who can do things by the million -- remember that all of this happens on the emulated server, on the attacker's own machines), he can start over at step 1, to guess other letters. After a few iterations, the attacker has the complete user's password, and can confidently log onto the real server.

In practice, the attacker does not need to really set up a complete virtual machine with snapshots; he can just concentrate on the few kilobytes of code that handle the authentication process. But basing the description on snapshots and server emulation shows that this kind of attack is generic, and there is nothing that can be done to protect against it as long as the attack model applies.

To again achieve security, then, the model must be made not to apply. In the discussion above, I assume that the attacker can get a copy of the server state. Thus, to prevent that attack, we must make it so that there is at least part of the server state that the attacker cannot plunder. In that case, just store a symmetric key K in that attacker-free part of the server, and use symmetric encryption for storing the passwords.

I expect most sites that asks for letter combinations within the user's password to use such reversible encryption. This can be considered as "safe" if the key K is indeed kept out of reach of attackers, which is hard unless you do it seriously (and expensively).

Still in all generality, asking for three letters means that you grant entry to random attackers with probability 1/17576, which is, in my opinion, a bit too high for comfort, considering that we are talking about a publicly reachable server. The whole concept of asking only for some letters is meant to be "more secure" but in fact it is more about sprinkling some obnoxious ritual elements so that you may feel more secure, possibly at the expense of actual security.


When you look at something from a security perspective, its security aspects emerge. That often refers to the security-related principles and concepts which are part of a particular technology. (This technology doesn't have to be about security itself.)

Examples:

  Anonymity is an important security aspect of wireless communications and has continuously attracted significant attention.

(Source)

  We know that establishing a person's identity is an important security aspect of government transactions.

(Source)

As opposed to overall security goals, security aspects are specific to a product or technology and can't be generalized in the same way.


Capture emails of users who clicked my link

Use a link like phish.org?email=user@domain.com.

You can use base64 or any other encoding to obfuscate the email address, but the principle is the same.


Traffic obfuscation under targeted surveillance

I think that the only option that you have is a "network cover channel", some of them are easy to detect and other are really hard. I suggest you to read Network Covert Channels: Design, Analysis, Detection, and Elimination and also there is a book called "Hiding in Plain Sight" from Eric cole that explain all the basics of the network covert channels, pros and cons, and so on.


What kind of protection does Port security offer?

Port Security defends against the following attacks:

CAM table overflow
DHCP starvation
MAC spoofing (partial)

The first two rely upon the ability of the attacker to flood the network with requests from bogus MAC addresses, so Port Security directly inhibits them.  The latter is only partially mitigated; an attack which only needs to spoof one address (and not use a valid address too) would be able to bypass Port Security.  However, that rules out some attacks - for example if the attacker needs remote control of the endpoint on valid IP/MAC "A" and wants to spoof IP/MAC "B" in an attack - can't do both at once.


Can brute force or dictionary attacks be detected when using the WiFi protocol?

No, it is fundamentally impossible to detect a brute force or dictionary attack when using the IEEE 802.11i (WPA2) protocol. This is due to the fact that brute force attacks do not require interacting with the router at all, only passively observing existing connections. If they observe the 4-way handshake, they can attempt to brute force it offline and use it to either authenticate or passively decrypt traffic. The router has no way to know if a client connecting to it is connecting with a key legitimately obtained or with a key that has been obtained through cracking* the 4-way handshake.

The upcoming WPA3 protocol will no longer be vulnerable to offline brute force and dictionary attacks due to its use of the Dragonfly protocol. Unlike WPA2, the encryption key is generated randomly and is distinct from the password used for authentication. Attempting to authenticate with any given password requires interacting with the router, so a brute force attack will thus require actively requesting authentication from the router, which can then rate-limit requests, log failed attempts, or outright refuse to serve a client that is repeatedly failing authentication.

* A one-way hash of a the password is sent in the clear, so all the attacker has to do is run candidate passwords through the same algorithm and compare the resulting hash to the hash of the correct password.


An intranet web app for decrypting values : a bad idea, and if so, why?

Well, which is it? A user or an attacker? A user doesn't care about the key, an attacker does.
An attacker doesn't really even care about the key, but rather the password. Moreover, an attacker doesn't really even care about the password, but in fact the data in the database.
If an attacker could reasonably get the key out of the user profile (which is what you're suggesting is the attack) they could easily just observe the connection to the service or even the database itself.
The correct solution is to move the connection to the database out of the context of the user. Since that's probably not feasible, you should consider switching to a non-credential-based mechanism like Windows Integrated Auth. You seem happy to do it for the service, so why not the database?
Note however that this doesn't actually solve the problem, it just limits the ways an attacker can connect to the database.


Nmap scan for Operational Technology devices

Operation Technology, Industrial Control systems (ICS and SCADA), medical devices, embedded devices, and specialized communications systems can be frighteningly fragile, especially considering the degree of trust that is placed in them and the serious consequences that follow when they are brought down. Nmap and other non-standard network software can cause problems, partially because they operate at the edge cases of the RFC standards for TCP/IP, and partially because they are designed to reach out and touch things in ways that system designers have not considered.

With the understanding that every interaction with these systems carries a degree of risk, here are some guidelines on what Nmap options are the most and least likely to cause disruptions, organized by scan phase.

Target enumeration

Often overlooked, this phase is where target addresses are chosen. Usually these are specified directly on the command line, but it can be safer to put your targets in a text file and use -iL to pass them to Nmap. This is especially helpful if your targets are being provided by someone else, as it eliminates the possibility of fat-fingering an address. You can also use --excludefile option to exclude known out-of-scope addresses from your scan.

Host discovery

Nmap sends several different kinds of probes to determine if a target is listening. Most of these are pretty harmless, but when scanning sensitive systems it may be best to explicitly choose your host discovery methods with -P* options. In particular:

switches may have difficulty with large numbers of ARP requests
Nmap's ICMP datagrams are sent without any data by default, which is unusual. Adding --data-length can mitigate this, but it will affect all other packets, leading to more unusual cases like TCP SYN with data.
The default host discovery sends raw TCP SYN and ACK probes to port 443 and 80. Unsolicited ACK (-PA) is not allowed by RFC.

Reverse DNS resolution

Here you don't need to worry. Reverse-DNS is performed between Nmap and your configured DNS servers, and does not result in traffic being sent to the target IP directly. Specifying -n will skip this step for a small speed boost, but it won't have an effect on the target.

Port scanning

Port scanning is problematic. Leaving aside the more esoteric scan options (-sA/W/M/N/F/X) which are explicitly RFC-abusive, simply doing a raw SYN scan can bring down targets which allocate resources for incoming TCP connections that never happen. This is known as a SYN flood. Always make sure that the system you are scanning from will send a TCP RST packet in response to an unsolicited ACK, since Nmap itself does not bother to reset its half-open connections. In some cases, this is still not sufficient, because Nmap's crafted TCP packets are just unusual enough to cause targets to freak out.

TCP Connect scan (-sT) uses the OS's native socket operations to attempt to open connections. This slightly slower method can reduce some of the unusualness of your scan, but at the cost of completing a full TCP connection to each open port, and then immediately closing it. Rob Graham notes that some older Unix-like systems handle reset connections in a way that can cause the service on the port to crash. So consider which part of your target is more fragile: if the OS or TCP stack, then use -sT; if the service or application, then use -sS.

In your question you are using the -sn option, which turns off port scanning. This is, of course, the safest option, but it does not provide any port scan data (duh).

Version detection, OS detection, and NSE script scanning

Here be monsters. Version detection sends a bunch of unsolicited data to target services to elicit unique responses. OS detection does the same thing to the TCP/IP stack. NSE scripts can do either, and in more creative, complicated, and intense ways. While these are some of the most fun and interesting features of Nmap, I recommend strongly against using them on potentially fragile targets in an operational environment.

Traceroute

The --traceroute option is probably pretty safe, simply because it does not send any type of probe that either host discovery or port scan did not already send. The exceptions are:

If you did a TCP Connect scan (-sT), traceroute may still send raw TCP packets, because it needs to manually decrement the TTL field. It prefers to send packets to closed ports, though, to reduce the issues discussed earlier regarding SYN flooding.
Because it decrements the TTL, it will end up sending a probe to the target that arrives with a TTL of 0 or 1. This is an unusual case, and though it is well specified in the RFC, unusual cases are where things break most.

Timing

  Inigo Montoya: But, I promise I will not kill you until you reach the top.

  Man in Black: That's VERY comforting, but I'm afraid you'll just have to wait.

  Inigo Montoya: I hate waiting.

If there's one thing that can be counted on to make a target unresponsive, it's too much traffic. Nmap tends to be better than many scanners in this regard because it reduces speed when it detects packet drops, but sometimes that's not enough. Using the -T2 (2.5 packets per second) or -T1 (4 packets per minute) options can be helpful in these cases, or you can manually tune the values with --scan-delay and --max-rate. In any case, slow it down and get ready to wait.

Other resources

I periodically search Twitter for mentions of Nmap crashing devices, which I retweet with the #KilledByNmap hashtag. There is also a little-maintained list of fragile devices started by some folks at SANS called the Network Scanning Watch List.

Good luck!


AWS Flowlog for Private Subnet Showing Routable IP's

TL;DR - There was a Network Load Balancer (NLB) in the private subnet in front of the host in the private network.  That NLB had a public IP.

When there is a Public IP associated to the network interface, traffic from the client public IP (source) will reach the ENI provided the security group and ACL allows the traffic to come in, regardless of whether there is IGW as default route or not.

Because an AWS NLB does not use security groups and no NACL was in place, routable traffic was able to reach the private subnet.  The security group on the host rejected the traffic and that's what was showing up in the Flow Logs.
Response traffic would not make it out of the private subnet because the route tables are followed.  Route tables aren't used to control inbound traffic but do control responses.
Can you clarify why an NLB in a private subnet even with a publicly routable IP address can receive traffic when it's subnet does not route through the Internet Gateway?
From a port scanners perspective they would have received no response from the NLB.

SYN from the client will reach the NLB, but no SYN-ACK would be sent to the client as now route table would be evaluated for response traffic and as there is no route to IGW the response traffic would be dropped.
To summarize, NLB or your backend target are not responding to internet traffic. Traffic would be accepted by Public IP on private subnet regardless of the route table default route.

Reference: AWS Support


Do voting machines rely on "security through obscurity"?

For the industry in general, particularly in the US, the security of voting machines is not unlike the security of TSA checks. Which is to say, it might work sometimes, but more than anything it's there to make you feel better about the process. Blatant violations of the security structure appear to be rare, but not because of the quality of the security.

While it's nice to feel like voting fraud doesn't happen, it's unlikely that any election of any magnitude anywhere has been perfectly clean. But presumably the fraud in both directions more-or-less averages out over time. Hopefully.

Specifically, beyond the security of the devices themselves, it's also the process put in place around them that contributes to the insecurity of the system. The "sleepover" practice made famous in the 2004 and 2006 US elections continues today in many areas. And when a voting machine shows signs of tampering (as often is the case), it does not necessarily invalidate the count.

But these are always local incidents, each closely associated with a given voting precinct, a given set of election officials, and a given set of local influences. It's the type of incident that requires no technology or vulnerability or security angle. An attack directed at a given voting machine (irrespective of the local officials) would be widespread, diffuse, covert, and systematic.

Part of what protects us here is the complete lack of any sort of coordination. There's no standardization of voting procedures or voting machines. There's no single target, which dramatically complicates the process.

Yes, there's some amount of security through obscurity, but more than anything it's security through confusion. Targetting would likely have to be opportunistic. And typically this is an attack that would be extremely difficult to pull off without physical access. Compound that with the fact that physical access makes fraud easy without any software vulnerability, and it starts to sound like we've been going about this all wrong from the beginning.


Webserver port tunneling security - security options

I'm afraid that you have already failed at the first hurdle since you are using HTTP everywhere. This means that you are pushing unencrypted login traffic over the Internet which is subject to interception and misuse. You must have HTTPS at least from the client to the edge server.

You also haven't taken into account denial of service attacks though you haven't said whether you think that important. If all of the services are on guessable ports, an attacker can simply start streaming traffic to those.

Using multiple ports also makes it hard for clients to connect when behind a firewall. I'd recommend using a reverse proxy at the edge of your server network. That can both be the HTTPS terminator, load balancer (if needed) and can be made to redirect URL's to the appropriate back-end services.

On the front-end, clients should use a folder to identify their origin:

https://myserver.com/servicea
https://myserver.com/serviceb
etc.

The reverse proxy can redirect those to the correct back-end ports.

You don't need anything clever with ids/passwords though if you wanted to tighten things up further, you could use the reverse proxy or a firewall at the server end to restrict connections by source IP address.


Unencrypt Data Encrypted by Cryptolocker Virus

Most ransomware use strong encryption algorithms, which means that you will have a hard time trying to decrypt the encrypted files without the corresponding decryption key.

The malware uses an AES key to encrypt files. The AES key for decryption is written in the files encrypted by the malware. However, this key is encrypted with an RSA public key embedded in the malware, which means that a private key is needed to decrypt it.

Read more at: https://www.secureworks.com/research/cryptolocker-ransomware


How to choose/compromise between data protection, and device recovery?

In general, since I don't have a specific case to look at, you simply need to answer the question:

Which is worth more to you?

Where worth is defined however you like. Hardware is expensive and data is cheap monetarily, so let me expand and consider two use-case scenarios:

You're working on something ground-breaking/commercially sensitive. Having your data stolen is going to be a problem because this data is very, very important to your future profitability. In which case, if somebody steals your laptop, that's expensive, but not nearly as critical as losing that all important latest mix, or whatever.
You're a bog standard home user. You've got doc1.doc files all over your hard disk, but most of them contain "Photos of the cat aged 3 1/4" or "That funny email from dave!!!11". You've got a few saved games you'd rather not lose and a bookmark to your favourite lolcat. This is not really critical to you.

Clearly I am choosing two fairly contrived extremes, but the point holds. In either case, the security measures you apply should be appropriate to the risk you're trying to mitigate. If you don't hold much data of any significant interest or value on your computer, you should do enough to ensure you can trust your system to do whatever it is you want to do. If you do process information you think is pretty valuable, start adding encryption and the like into the mix.


No, the SAK is still Ctrl+Alt+Del, and it never went anywhere. (It never was a technical requirement for logging in, merely a policy decision.)

On "consumer" versions of Windows, the SAK (Secure attention key) requirement was disabled for convenience, although can still be enabled via Group Policy, or even via control userpasswords2. Server editions still have it enabled.

The SAK still remains useful – when logged in, you can press it to get the "Windows Security" screen, change your password, or start Task Manager. So it can still be used to manually verify the login screen, even when Windows does not require it.

You cannot make every key be a SAK, because that would make it impossible for other programs to react to keypresses (which is the whole point of a SAK).


What are TLS Cipher Suites with ephemeral key Exchange and NULL encryption for

The NULL encryption was introduced after RFC 4785 which was introduced support for different import restrictions among other things:

Quoting the RFC:

  There are also cases when confidentiality is not permitted -
     e.g., for implementations that must meet import restrictions in some
     countries.  Even though no encryption is used, these ciphersuites
     support authentication of the client and server to each other, and
     message integrity.

Reference: https://tools.ietf.org/html/rfc4785

  The ciphersuites defined in this document are intended for a rather
     limited set of applications, usually involving only a very small
     number of clients and servers.  Even in such environments, other
     alternatives may be more appropriate.


Would this work to protect a cookie with an OAuth token?

You are not worrying about the right things

Protecting information located on the client?

You don't need to do anything once the information has reached your client (ex.: your browser) in order to protect it. You could store the access token in a cookie, in a hidden field on your webpage, in html5 local cache or plainly visible directly in the middle of the page and it doesn't change anything (except shoulder surfing...).

Worrying about the access token once it's on the client is like opening notepad to write your email password and then worry that an attacker might be able to steal that information from a remote location. It doesn't happen. Unless your computer is already compromised but at this point you have already lost.

Where it makes sense to worry?

Usually, your information is vulnerable when it is in transit. In the case of OAuth2 (implicit flow), the access token will be in transit at two places :

from the authorization server to your browser
from your browser to the resource server

Protecting the information while it is in transit is as easy as using TLS everywhere. Which you should already be doing since you are using OAuth2 and it's required by the protocol.

Now the real problem

The way you intend to use OAuth2 is most likely not the way that you should be using it.

To understand why you will probably misuse OAuth2, you have to know about the flows. OAuth2 define 4 authorization flow

Authorization Code (only good one but... keep reading)
Implicit (false sense of security)
Resource Owner Password Credentials (horrible idea)
Client Credentials (not applicable to your case)

Since you using a javascript client, the only flow that works for you is the implicit flow and now starts the issues.

Implicit flow problems

There are many but let's just talk about the most critical one. Access token are not bound to a specific client! From the specification section 10.16 :

  For public clients using implicit flows, this specification does not
  provide any method for the client to determine what client an access
  token was issued to.

This open the doors for attacker to impersonate you, the resource owner, and then gain access to the resource server. Let's keep reading section 10.16 :

  A resource owner may willingly delegate access to a resource by
  granting an access token to an attacker's malicious client. This may
  be due to phishing or some other pretext. An attacker may also steal
  a token via some other mechanism.  An attacker may then attempt to
  impersonate the resource owner by providing the access token to a
  legitimate public client.

  In the implicit flow (response_type=token), the attacker can easily
  switch the token in the response from the authorization server,
  replacing the real access token with the one previously issued to the
  attacker.

  Servers communicating with native applications that rely on being
  passed an access token in the back channel to identify the user of the
  client may be similarly compromised by an attacker creating a
  compromised application that can inject arbitrary stolen access
  tokens.

  Any public client that makes the assumption that only the resource
  owner can present it with a valid access token for the resource is
  vulnerable to this type of attack.

That first attack is actually not even an attack but rather just a "flaw" in the implicit flow...

The next attack

Now starts the big troubles. You seem to be trying to use OAuth2 implicit flow as a form of delegated end-user authentication which it is not meant to provide. Back to the specification section 10.16

  Authenticating resource owners to clients is out of scope for this
  specification.  Any specification that uses the authorization process
  as a form of delegated end-user authentication to the client (e.g.,
  third-party sign-in service) MUST NOT use the implicit flow without
  additional security mechanisms that would enable the client to
  determine if the access token was issued for its use (e.g.,
  audience-restricting the access token).

At this point it's mostly game over for you.

How to mount that attack?

It's pretty simple. Let's say your REST service required an access token from facebook. All an attacker need to do is to host a service, for example stackoverflow, and require an access token from facebook. When you give the facebook access token to stackoverflow, stackoverflow (our attacker) can now impersonate you with your REST service.

All that because access tokens are not bound to a specific client.

A solution

Don't use the implicit flow and instead use the authorization code flow. Which means that your 100% client side app will need to no longer be a 100% client side app.

Why are you not using the server that is serving the angularjs client to your user to handle the OAuth2 flow?

Reference : http://tools.ietf.org/html/rfc6749


How to start OWASP Shepherd using Docker?

It depends of how did you run the container. If you specified -p option, then you mapped ports from your host to the container in order to access it directly on your localhost. I mean, for example, if you put on docker run command -p 5555:80, you are mapping container port 80 to host's port 5555, so you can access to it on http://localhost:5555.

If you don't want to map ports in order to prevent anyone on your network can access to the container through your host, run it without -pand then you can do a docker inspect command to find the container ip address. Because the containers by default are accessible only by the host machine on a specific ip. Docker set iptables on run and allow only to you to access to the container. You can do docker inspect yourContainerName | grep '"IPAddress"' | head -n 1 and you'll get the ip address of your container. Then you can access only from the host to http://<yourResultIpFromBeforeCmd>

Hope it helps.


When implementing CORS, should I check for a correct HOST header in my webapp?

My understanding is that DNS rebinding is an attack that you'd perform to access something on a local system like a router ...

A DNS rebinding attack is not restricted to a router or other local network devices. It is an attack which is used to bypass the same origin policy and thus not only submit data to a server like in CSRF but also read the response back.

While the typical use case is to read data from servers which can not be directly reached from outside (like the internal company wiki) it could for example also be used to get data from internet reachable systems which use IP-based authentication (i.e. some client given special rights based on there source IP address).

Given that CORS is about restricting cross-site read/write the recommendation to check the Host header in order to protect against DNS rebinding makes sense, since DNS rebinding is essentially the attempt to make a cross-site request behave like a same-site request.


Do I have to use an IV when using GPG with AES 256?

I'm going to refer you to Thomas Pornin's answer to Will encrypting the same file with GPG and the same key produce the same ciphertext?, which is (as usual) really excellent.

It boils down to: Yes, there is a random IV and an additional random salt during the password to key transformation.

The relevant paragraph is:

  The third point also applies when doing password-based encryption (encryption is done with a password, not with a recipient's public key). Password-based encryption also adds a fourth randomization, which is the salt in the password-to-key transform, 3.7.1.3.

Section number added by me from his quotation, link updated.

The third point is:

  When doing the symmetric encryption itself, a random IV is used, and will be different (with overwhelming probability) for each invocation. See section 5.7 for details.

Link updated again.


How to encrypt a USB to be used with MAC & Win

I am not sure if there is a free software for that, but there is a free trial for EasyLock, a cross-platform data encryption software for USB devices. Once you open the product page, select Resources Tab, USB Setup for Windows and Mac. You don't have to install both of them, you just choose the compatible one with the computer where you use it for the 1st time.
If you have any questions, I am here for you.


Providing access to Git repo behind a Firewall using Certs/Keys for Authentication

If you're thinking of SSH certs does this mean these are internal users who can be forced to use additional security measures? Examples:

VPN
SSH Jump server - users connect here first and then use port forwarding to access your git host(s). You could insist on two separate sets of credentials too.


Using "Dynamic Hash Technique" to protect cookies from XSS?

If I read the paper correctly, they authors seem to be proposing replacing the cookie with a separate value passed as either POSTdata or concatenated with the URL of a POST or GET request.  While it is technically true that removing the cookie and doing something else for session management makes attacking the cookie useless, the attacker will simply attack the replacement session identifier - just like you expect.

The approach attempt comes down to obfuscation.  At best, this approach will be useful if implemented on a small number of extremely low traffic sites. If it becomes commonplace, attackers will just automate their attack to go after this value as well.

It's worth noting that session identifiers have always been possible to transmit appended to the URL or in the postdata. This was originally implemented as a way to support web browsers that didn't support cookies. It's likely automated tools already look for values like this, and it won't fool a manual tester.


Preventing dictionary attacks against hashed passwords

You should not use SHA-3 yet. And let's not call it Keccak for clarity's sake, I can't recall what SHA-2 and SHA were originally called so I guess future readers won't know Keccak either.

More on-topic, your answer is here: How to securely hash passwords? This protects against dictionaries and all other possible attacks in the best currently known way.


Explanation required on Relationship between "Certificate Type" and "Key Exchange Algorithms" in TLS 1.2

First, this is a pretty broad question already. Please don't add anymore questions to this and ask for further details in new questions instead.

  Question 1: Is this observation correct?

No. If you do a openssl x509 -text -in cert.pem you can see the public key and also the type of the public key:

    ...
    Subject Public Key Info:
        Public Key Algorithm: rsaEncryption
            Public-Key: (2048 bit)
            Modulus:
                00:be:f2:0e:d5:f5:97:8f:23:e1:89:6d:56:58:97:
    ...

  Question 2: Is this correct?

Depending on the interpretation of what "securing the actual data" means. The part after the WITH in ciphers like TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 describes the method for encryption and integrity protection. It does neither describe the key exchange nor the authentication method. But without proper authentication and key exchange the key used in encryption could be compromised which means that it does not really "secure" the actual data.

  Question 3: ...

You got this mostly right. The RSA/ECDSA in the cipher suite describes the authentication. And in case of ..DHE_RSA_.. or ..ECDHE_RSA.. it also only describes the authentication. There are ciphers like TLS_RSA_WITH_AES_128_CBC_SHA256 though where the key exchange algorithms is RSA and in this case the certificate is also involved in the key exchange.

  Can someone explain the role of the Certificate in the various stages of establishing the pre-master-secret?

The certificate is only directly involved in the key exchange (i.e. establishing the pre-master-secret) in the obsolete RSA key exchange which essentially means that the client encrypts the pre-master-secret with the RSA public key and the server can decrypt it since it has the private key.


Is RSA key-like browser authentication feasible?

Your intuition is correct! There are two protocols that I'm aware of which use public-key crypto as a way to log into websites. (neither are actually SSH though)
TLS client certificates
We are all familiar with TLS (that green lock icon in your browser bar). Typically it serves two purposes:

Encrypt the traffic between you and the server.
Prove that the server is who they say they are.

By clicking on the green lock, you can see the server certificate for the site you are currently connected too.
It turns out that TLS also supports a mode called "mutual authentication" where, in addition to the server providing a certificate to prove its identity, you (the user) do too.

To do this, you need to get a personal certificate (usually issued by the website in question) and import both the cert and the matching private key into your browser (usually via a .p12 file). When connecting to a site the requires it, you'll see a popup like this:

FIDO Universal 2nd Factor (U2F) USB sticks (think Yubikey)
This is the technology where you plug a USB crypto device into your computer and a website communicates with the device to authenticate you. This has pros and cons compared to client certificates, but one big pro is that the private key is stored in cryptographic hardware, so even someone with admin access to your laptop can't make a copy of your key.

From wikipedia:

Universal 2nd Factor (U2F) is an open authentication standard that strengthens and simplifies two-factor authentication (2FA) using specialized USB or NFC devices based on similar security technology found in smart cards.
U2F Security Keys are supported by Google Chrome since version 38 and Opera since version 40. U2F security keys can be used as an additional method of two-step verification on online services that support the U2F protocol, including Google, Dropbox, GitHub, GitLab, Bitbucket, Nextcloud, Facebook and others.


Better way to import Win32 APIs from injected shellcode

There's a good way to solve problems (2) and (3) in the described manual binding process but I'm reluctant to publish good and elaborated public tutorial about designing shellcode here on StackExchange. ^_^ So, there's a hint for you of using crcs for (2) and indirect calls for (3) - you seem familiar enough with the manual binding process to deduce the exact way of applying these two concepts.

Regarding (1), is not a problem but an incorrect assumption: binding exports to imports and providing a programmer ability of calling system API is not trivial by whatever mean. The question is just who'll do all the dirty work. As soon as you reject Windows linker's service for its reliance on plaintext names, you're on your own to implement the dirty details by your own way.

Import injection seems to be the most clean way as you modify the binary anyway, but it adds plaintext API names, so I guess because of that is out of your consideration.


Risk of web admin portal without extra authentication steps

It's an interesting question, and I'm not sure I can answer correctly. But here are my thoughts anyway.

It can't be a vulnerability. A vulnerability is something that can be exploited, and if it can't be exploited it can't be a vulnerability. The lack of an IP whitelist isn't something that can be exploited, if authentication requires a strong password.

It is probably a weakness. A weakness is something that is technically wrong or imperfect, and that in some cases might lead to a vulnerability (but not necessarily). So why should you let random IPs connect to the admin panel, if you are sure that only a few specific IPs will ever need to access it? The best, perfect, ideal thing to do would be to use an IP whitelist. So the lack of an IP whitelist would be a kind of weakness. It won't necessarily lead to a vulnerability, but it might. Example: imagine that an attacker steals the admin's password by shoulder-surfing. The attacker goes back to his basement and tries to connect... and if you have an IP whitelist the attacker will fail. But if you don't have the IP whitelist, what was only a weakness then becomes a vulnerability.

Note that CWE (Common Weakness Enumeration) actually includes "use of single-factor authentication" in the list of weaknesses: CWE-308.

So in my opinion, implementing an IP whitelist in this case can be defined as defense in depth, because you are actually protecting from weaknesses, and preventing them from becoming vulnerabilities if something were to go wrong.


I would say you are right so far, but this is just guessing so far (probably right though :)).

Yes, I think reverse engineering the application binary is your next step. If you identify the encryption function and the key, then you can reimplement the crypto functions in say, python, and decrypt/encrypt your values as you like.

So,

Get your hands on the application binary. (either extract it from the phone (might need to jailbreak it), or download the IPA from iTunes, more info here)
Run a "strings" on the application. It can results in many interesting strings, it might even list you the encryption key or some clues about what algorithm is used.
Use a static debugger, such as IDA Pro or Hopper (need to support ARM) to peek into the binary. If you are lucky it has the function names, which could help you greatly to find what you are looking for. If not, you could try to search for known crypto constants in the binary. Check out my answer about that here. Also check out this and this. If you found a constant used in the crypto function, you can cross-reference where that constant is accessed/used, and eventually you will find the key as a parameter or static variable used by the crypto function.
If all else fails, you will have to use a dynamic debugger (such as GDB), and attach to the process running on the phone and work from there. Find a piece of data that you know for sure that it will be eventually encrypted, and trace the function calls accessing that data until it's encrypted.

Don't forget about the Reverse Engineering and Crypto stackexchange sites, and of course google a lot! ;)


What is the risk of someone intercepting my CSR and private key

If you do it properly, nothing.

The usual process for getting a TLS (formerly SSL) certificate from a CA is:

Generate server.privkey and server.csr (or equivalent) files on your machine. Keep the private key private.
Send the server.csr (certificate signing request) to the CA to get signed and become a certificate.
Take the certificate the CA gives you back and import it into your web server along with the server.privkey.

The CSR file is not sensitive and can not be maliciously modified without cracking the crypto (hard). You do not need to be overly careful about sharing this file.

The Private key, on the other hand, should be private. It should stay on your server. You should not share it with anyone. Again, this is private. All sorts of bad things can happen if bad guys get this. If you have already shared it with someone, I suggest you start the process over by generating a new keypair, a new CSR, and getting a new cert. This time, don't share the private key with anybody!

What's in a private key?

Your private key is the cryptographic identity of your server. When a browser connects to your site, your server sends down the certificate (containing your public key), and performs a proof that the it has the corresponding private key. Browsers accept this proof that it is talking to the real cutefluffyanimals.com, and not a spoofed version. The browser shows the green padlock and everything is good.

If a bad guy has a copy of your private key, then they also have the cryptographic identity of your server and can pretend to be you: intercept traffic going to your server, view information the user entered (including usernames/passwords), modify page content, pretend to be the server and respond directly to the browser, inject their own content or code or ads into your pages, etc. They can literally do anything because, cryptographically speaking, they are the real server. The browser will still show the green lock because the server it's talking to has the right private key.

Anybody who requires you to share your private key clearly doesn't understand how certificates work. Kick them in the face.


Client-server encryption technique explanation (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys)

Asymmetric Cryptography

There are two different parts to creating a TLS session.  There is the asymmetric cryptography, portion which is an exchange of public keys between two points.  Which is what you saw in your Alice and Bob example.  This only allows the exchange of asymmetric keys for asymmetric encryption/decryption.  This is the ECDHE portion.  The RSA portion describes the signing algorithm used to authenticate the key exchange.  This is also performed with asymmetric cryptography.  The idea is that you sign the data with your private key, and then the other party can verify with your public key.

Symmetric Cryptography

You encrypt symmetric encryption/decryption keys with your asymmetric key.  Asymmetric encryption is very slow (relatively speaking).  You don't want to have to encrypt with it constantly.  This is what Symmetric Cryptography is for.  So now we're at AES_128_GCM.

AES is the symmetric algorithm
128 refers to key size in bits
GCM is the mode of operation

So what exactly does our asymmetric key encrypt?  Well we want to essentially encrypt the symmetric key (in this case 128 bits, 16 bytes).  If anyone knew the symmetric key then they could decrypt all of our data.  For TLS the symmetric key isn't sent directly.  Something called the pre-master secret is encrypted and sent across.  From this value the client and server can generate all the keys and IVs needed for encryption and data integrity.  Detailed look at the TLS Key Exchange

Data Integrity

Data integrity is needed throughout this process, as well as with the encrypted channel.  As you saw when looking up GCM, the encryption mode of operation itself provides for the integrity of the data being encrypted.  However, the public key handshake itself must also be confirmed.  If someone in the middle changed data while being transmitted then how could we know nothing was tampered with?  This is what instance where the negotiated hash function is used, SHA256.  Every piece of the handshake is hashed together, and the final hash is transmitted along with the encrypted pre-master secret.  The other side verifies this hash to ensure all data that was meant to be sent was received.

SHA256, as mentioned by another poster, is also used for the Pseudo-Random Function (PRF).  This is what expands the pre-master secret sent between the two parties into the session keys we need for encryption.

For other modes of operation, each message would be hashed with this integrity algorithm as well.  When the data is decrypted the hash is verified before using the plaintext.

Here is a great explanation for how these derivations happen for different TLS versions.

Put all these pieces together and you have yourself a secure mode of communication!

You can list all possible ciphers that OpenSSL supports with openssl ciphers.  You can go further and print the details of any of these cipher suites with the -V

For example:

$ openssl ciphers -V ECDHE-RSA-AES256-GCM-SHA384
          0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD

0xC0,0x30 represents the two byte identifier for the cipher suite
Kx=ECDH represents the key exchange algorithm
Au=RSA represents the authentication algorithm
Enc=AESGCM(256) represents the symmetric encryption algorithm
Mac=AEAD represents the message authentication check algorithm used


Is there a risk in opening port 22 for ssh access with a network?

Can someone clearly highlight why this is not recommended?

Because any running service is increasing your attack surface. Especially with network capable services, you're always exposed to danger. I don't think anyone can give you a more specific answer than that, since the SSH implementations tend to be quite OK from a security standpoint. Nevertheless there is always the possibility that an exploit is discovered, granting anyone sending the right packets to your server access or that you've greatly misconfigured your servers.

But, even if you assume that the software itself is flawless, there are a couple of reasons why you might want to re-think your approach. Obviously, you haven't told us and details about your setup, but in the real world key management, audit trails and firewalling is always an issue. Aiming for another approach might therefore be a good idea.