Can you restrict the services a certificate can access on the client side? I have a verification certificate signed by my organisation’s CA, which I can use to authenticate my user account on intranet web services.

Is there someway I can sign a new certificate which can only authenticate to one specific web service. Or some other way to enable limited access to one web service by a script I don’t want to give full access to my verification certificate.

Unfortunately I don’t have access to modify the web service, which is running nginx.

You are mixing the concepts of authentication and authorization. The first is to know who the client is and the second to decide what this client can do. A client certificate in TLS is just used for authentication, i.e. like username + password but only better. If the service you want to access will accept this certificate as authorized  is fully up to this service.

  Is there someway I can sign a new certificate which can only authenticate to one specific web service.

First, you cannot usually create a new client certificate by using an existing client certificate. Also, given that you are not able to modify the service you have no way of specifying which authenticated clients are authorized for a specific service.


Will PHP malware from my hacked website be able to infect my computer locally if downloaded? I have site that is hacked and flagged by Google for having malware:

  Some pages on this website send visitors to the following dangerous websites: freshmodel.pw.

I made a backup of everything before I started, added a new clean website, and remove all the old site files (which I assume has malware).

Is it dangerous for me to keep a backup of this on my computer?

No, not unless you run it. And by default Windows can't run PHP files. Cleaning the site is a good idea, but be careful not to make the same mistake twice; if they got in through a file upload vulnerability, they will do it again if it's the same site. So try to find out what file is malicious and post it here so we can help.


Home wifi: is it typically possible to prevent WLAN devices from selecting their own IP address? Motivation: I want to be able to create different outbound traffic rules for different devices on my network e.g. my laptop can create VPN tunnels, whereas my kids' laptops can only connect DNS/HTTP/HTTPS, and they are locked to a specific DNS server.  I can create different firewall rules on my router for different IP address blocks, but don't want this to be easily subverted by devices being able to select their own IP address in the "allow" range.

So this question is about whether it is typically possible and practical to prevent a device on a home wifi network from selecting its own IP address (from within the network range), using commonly-installed home wifi/internet routers.  In other words, can you prevent devices from assuming any static IP address in the WLAN's normal range.

Assume that I already have and know:

wifi router configuration for DHCP pool ranges
wifi router configuration for DHCP static IP addresses
wifi router MAC-address filtering etc.

I can add a static-lease for the device based on its MAC address, and when the device is configured for DHCP it assumes this address.  But assume that I don't have 100% control of the device's networking settings, that some other user can change those - for example they could switch from DHCP to static and configure an IP address of their choosing.

My observation is that whatever static IP address is chosen works and the router will route packets for that client (it has wifi-level access e.g. WPA2 credentials of course), regardless of whether the IP-address chosen is within the router's DHCP range or some reserved range.

My conclusion is that you cannot create firewall rules which prevent outbound traffic for certain clients based on an IP-address range, since clients are free to grab a free static IP address within that range.  This seems to happen irrespective of whether a DHCP reservation exists for that client's MAC address, which makes sense because DHCP is inactive for the client at that point.

It seems to me that either multiple routers or multiple VLANs are the only way this can be achieved?

Example: I want to prevent an allowed but only partially-trusted device on my WLAN with MAC 12:34:56:78:9a:bc from routing packets with source in the CIDR range 10.1.1.0/25, which is reserved and outside my DHCP range.

There is no way to force IP addresses on clients in an Ethernet network as such, as they can simply opt not to use DHCP at all. Clients can pick and use any valid IP address. Furthermore, static leases by MAC address will not guarantee an IP assignment even if DHCP is used as MAC address not static and can be chosen arbitrarily (equal to MAC filtering in the first place). More intelligent firewalls will usually force the source address of packets to belong to the interface subnet. You could also really make a firewall rule to at least enforce that only some range of IP addresses are routed.

Embedded router devices are spectacularly non-versatile and preventing some devices form accessing the internet is not a particularly common usage case. Forcing IP addresses to devices is kind of an XY fallacy for the problem. This task is definitely impossible, but your objective is fairly straightforward.

For example, you could use another NAT router for the restricted devices and give it a static LAN IP address on the WAN interface. Then make rules preventing that LAN address on WAN interface from reaching the internet on the main router. This works because the devices behind the internal router have their addresses translated to the single WAN address which they can not change. They would still be able to access the main LAN addresses through the default route of the internal router. To communicate back to them you would need to add port forwards. Another possibility would be to use 1-to-1 NAT with a pool of addresses.

As stated, using a VLAN per SSID capable AP would at least allow a router running a full version of Linux to trivially segregate the traffic between VLAN segments (I recommend Ubuntu w/ Shorewall). Some "open source" firmware images for home routers supposedly can do VLAN/SSID and firewall rules based on VLAN tag, but they tend to be horrible and I strongly do not suggest them.

Perhaps a sincere analysis of the threat model would be helpful as well. Why is it important that these devices can not reach the internet. How strident will attempts to circumvent these controls be? Is a MAC whitelist not good enough? You say the devices are partially trusted... are you sure you trust them to have unprotected access to your trusted machines anyways?


1.1.1.1 Cloudflare encrypted DNS.Does it still leak IP addresses? 1.1.1.1 might be encrypting the DNS request but then between my ISP and the website I'm accessing, IP addresses are exchanged.Does my ISP see the IP address of the website I'm accessing but not its domain name?

When that happens over HTTPS therefore you the domain is encrypted, is the IP address still leaking?
And what about simple HTTP ?

There are several unrelatd topics here, but:
Yes, the IP never is safe from attackers. Neither is the domain name is your scenario.

First, Cloudflares DNS might support some encrypted transfer, but this won't happen if the client doesn't use it. Making a normal old DNS request is still unencrypted, so a sniffing something can see what domains you're visiting.

Then, even if it was encrypted, the whole point of DNS is to transform a domain name to a numeric IP address. This IP is then used to request the content of the website itself. Anything on the way there (your ISP, some other commercial internet nodes, the websites hoster, etc.) can see the target IP (and yours too).

And the content of the request will also contain the domain again, because there might be several different domains on one IP. This is true for both HTTP and HTTPS, and both times it is not encrypted. There are some plans for HTTPS to make encryption of this part possible, but right now it is plaintext.


What can an attacker achieve with admin access to a router? I wanted to know what a person can do if he has access to the Router Settings?
I know he can change the password and stuff but can he do any real password sniffing stuff?

depending on the router, you can set up a proxy server and redirect all traffic to said server.

This would allow you to do any MITM attacks you would normally be able to do but without having to ARP the victims. A simple google of MITM attacks could open up a large range of ideas for your self.

DNS attacks (e.g. redirection) and SSL stripping / denial are good example of things you can do if you set up a proxy server on the router.

Basically redirecting traffic to a device to handle it with your rules is a start, and then decide what you want to do from there.


At what point in their employment should security policies be explained to an employee? There are the basic things that need to be explained to every employee about a security policy. For example:

How sensitive information must be handled.
How to properly maintain your ID, and password, as well as any other accounting data.
How to respond to a potential security incident, intrusion attempt, etc.
How to use workstations and Internet connectivity in a secure manner.
How to properly use the corporate e-mail system.

But at what point in their employment should these security policies be explained to an employee?

The question could also be asked: "how long should an employee have access to data before they are trained in how to use and protect that data?"

For most organizations, the answer is "0 minutes". You wouldn't place an employee in front of machinery without training them, and you shouldn't place employees in front of a computer without training either.

Each organization needs to assess the risks of this, but the typical answer is that this training is done during orientation.


Do I have to harden IE if I'm only using Firefox? Assume a Windows 7 system (probably whatever home version comes with the machine), with the latest OS patches, latest IE and latest Firefox. Also assume that the user uses only Firefox for browsing, never IE, and that uninstalling IE is impossible or impractical.

In the context of "safer" usage while browsing, is it sufficient to take steps to harden Firefox, or do I also need to worry about IE?

The underlying question is: Assuming a "Joe Sixpack" home user, are there attacks that target IE that can be triggered from actions taken by a user who doesn't knowingly start IE for web browsing? (And are they mitigated by hardening such as suggested in documents like this one.)

I'm guessing that uninstalling IE is impossible or impractical.

Go to Control Panel -> Uninstall a program -> Turn Windows features on or off. There you can deselect Internet Explorer.

You need to harden IE as well. An application could launch or embed an IE window that could then be used to gain control of the system. Consider this attack: an attacker serves a web page that uses a 0-day remote code execution exploit in Firefox to launch an IE window that visits a page hosting a privilege-escalation exploit in IE.


BitLocker To Go password strength When using BitLocker To Go, given that removable drives are inherently offline and may have to resist such attacks, what are the best practices / recommendations for password strength?

In this case, the password takes the role of a symmetric encryption key. So you can use the recommendations for symmetric keys given by various trusted institutions.

For example, if you want to have a password of 128 bits of security, you can generate one of at least 22 alphanumeric characters (a-z, A-Z, 0-9). You can use a password manager for this, to ensure you do not introduce some bias in the generation process. (For the math: 128/log2(26×2+10) = 21.5)


How can an attacker use a leaked private key? I admit that while I'm a programmer, my crypto/security knowledge is fairly basic. I understand that the potential of leaking private SSL keys is cited as one of the most serious effects of the Heartbleed bug. My question is, how can an attacker actually use the private key?

Heartbleed.com states that:

  These are the crown jewels, the encryption keys themselves. Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will.

"Decrypt any past and future traffic" is clear to me, assuming the attacker has (or has had) means of sniffing the encrypted traffic. But I can't quite grasp how they can "impersonate the service at will."

The way I understand it, to impersonate the service, the attacker would need a way to divert traffic to their site, or pose as a man in the middle. And I believe both of these are quite difficult to accomplish (at least when no unsecure network like public Wi-Fi is involved). Is this correct, or am I missing something?

So, perhaps a different way to phrase it: if I, as an end user, type in https://someorotherdomain.tld into a browser's address bar (and there's no certificate problem), how likely am I to be talking to someone else due to someorotherdomain's private key having been heartbled?

Here is an example:  My dad started getting browser certificate warnings when he went to Gmail.  I looked in his hosts (C:\Windows\System32\drivers\etc\hosts ) file and some malware had edited it to redirect requests to gmail and a bunch of other sites to bad IP addresses that I assume the attacker controlled.  His browser warned him because those bad IP addresses did not have the correct private key of the certificate.  Now, if they had used a heartbleed type attack to grab those private keys, they could better impersonate the sites and my dad would have never seen a warning.


Why doesn't PCI DSS requirement 4.1 match the SAQ? In the PCI DSS standard (v3.1), 4.1(i) reads:

  For all other environments using SSL and/or early TLS: Review the
  documented Risk Mitigation and Migration Plan to verify it includes:

  Description of usage, including what data is being transmitted,
  types and number of systems that use and/or support SSL/early TLS,
  type of environment;
  Risk-assessment results and risk-reduction
  controls in place;
  Description of processes to monitor for new
  vulnerabilities associated with SSL/early TLS;
  Description of
  change control processes that are implemented to ensure SSL/early TLS
  is not implemented into new environments;
  Overview of migration
  project plan including target migration completion date no later than
  June 30, 2016.

However, in SAQ D this text is in 4.1(g) and there is no (i).

Why is there a difference?

I checked and this appears to be the same in v3.2 too (and also for the merchant SAQ-D).

Distilling from comments:

The PCI DSS standards document contains the requirements language and also contains testing procedures (column 2) and guidance (column 3) for QSAs and for those preparing for a visit by a QSA. The requirements are numbered in MAJOR.MINOR format and the testing procedures appropriate for a requirement use letters. The testing procedures are not themselves requirements.

The SAQ is a questionnaire for self-assessors. The questions appropriate to a particular PCI DSS requirement also use letters under the MAJOR.MINOR requirement format.

The lettering in these two documents are not intended to line up. Testing procedures and guidance for QSAs are different than questions intended for self-assessment.

If one qualifies to self-assess, then one can use the testing procedures and guidance in the requirements document to deepen one's understanding of the expectations of compliance, but one is only responsible for answering the questions in the SAQ.

If one does not qualify to self-assess them then SAQ should be ignored.


What is the difference between a jumpbox and a reverse proxy? These two seem to be an intermediary for external network and internal network. What is the correct use for each deployment? What are their differences?

"Jumpbox" (along with similar terms such as "jump server", "hop box" and the like) is meant to describe a server that sits between a client or management system and the target server or system being managed, which a user or application logs into from the client, and from there initiates a second session to the target server. There is no implied directionality with respect to whether the client and server each exist within a given network perimeter or outside of it, but generally they will be on opposite sides of such a perimeter and thus unable to directly reach one another using the desired protocol. Typically a command-line-based protocol such as ssh or telnet is used.

"Reverse proxy", on the other hand, is a bit more specific. A "proxy" server is defined with respect to a specific protocol or set of protocols, typically web (HTTP/HTTPS) and/or FTP, and allows the client (browser) within the network perimeter to access resources outside the perimeter by making connection to the proxy and asking the proxy to access the external resource on its behalf. A "reverse proxy", therefore, operates in the opposite direction: the client is outside of the network perimeter and the resources are within.

Many TCP-based network protocols can be relayed in this manner, and it's very much a matter of arbitrary convention which term is used for which set of protocols.


What is the name of this token-authentication scheme? I'm working on a specific security design. When reading it, it looks like some form of OATH but I'm not sure which kind.

The scheme is as follows:

The client authenticates through a web-portal (authorization server) with username password.
After a successful authentication, the user is forwarded to the resource-owner, the request contains a token.
The resource-owner validates the token with the authorization server.
The authorization server tells who the corresponding user is.

Now my question is: What is this schema called?

+--------------+                                +---------------+
|              |                                |               |
|              |       1. sends user & pass     |  authorization|
|   client     | +----------------------------> |  server       |
|              |                                |               |
|              |                                |               |
|              |                                |               |
|              |                                |               |
+--------------+                                +----^------+---+
                                                     |      |
                                                     |      |
                                   3. validates if   |      | 2. if correct, credentials
                                   256 bit string is |      | forwarded as 256 bit string.
                                   valid.            |      |
                                                     |      |
                                                +----+------v---+
                                                |               |
                                                |  resource     |
                                                |  owner        |
                                                |               |
                                                |               |
                                                |               |
                                                |               |
                                                +---------------+

UPDATE:

I hope my use case will clarify a bit more. I can only make minor changes to the resource owner (for a variety of non-tech related issues) and the type of authentication I want (two-factor) is not a minor change.
So I want the authentication server to redirect (after a successful authorization) the client to the resource owner ([512 bit string] POSTed to https://www.resource-owner.com/)/.
Now the resource owner asks the authorization server: is this token valid and for which user? It will return the user id is valid.
- The token expires after 5 seconds.
- The token is just a token, there is nothing encrypted inside of the token.

It sounds similar to OAUTH but the token usually contains basic attributes, including the user identity. You need to make sure that whatever the token contains cannot be modified, this can be done through validating a signature or using an HMAC.

I wouldn’t recommend reinventing the wheel here, just implement OAUTH.


In OAuth2, is it acceptable not to use https for internal communication between resource server and authorization server? I have a resource server (REST API) and an authorization server which are installed on the same server and behind a reverse proxy. All incoming external requests use https. Would it be acceptable not to use https for the communication between both servers internally (using localhost)? This way I'd only need to install the certificate at the reverse proxy level.

Since the traffic only goes to localhost, it's all handled by the loopback adapter and will never reach the network. As a result, using plain HTTP is fine.

If you wish to use HTTPS, in case that the servers will one day be separated, you can create a self-signed certificate for localhost and manually mark it as a trusted leaf certificate, even with no root CA. In practice, it will likely not make a difference.


Why is an IV needed when encrypting a private SSH key Given a password protected private key like:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,D54228DB5838E32589695E83A22595C7

3+Mz0A4wqbMuyzrvBIHx1HNc2ZUZU2cPPRagDc3M+rv+XnGJ6PpThbOeMawz4Cbu
lQX/Ahbx+UadJZOFrTx8aEWyZoI0ltBh9O5+ODov+vc25Hia3jtayE51McVWwSXg
wYeg2L6U7iZBk78yg+sIKFVijxiWnpA7W2dj2B9QV0X3ILQPxbU/cRAVTd7AVrKT
    ... etc ...
-----END RSA PRIVATE KEY-----

One can tell that the base64 encoded IV is specified in the header.

I do understand the importance of IV:s when it comes to "sniffable" traffic like traffic over 802.11*, etc, but I can't get my head around why an IV is needed when encrypting a private SSH key (as these are never transmitted over the wire).

Would somebody care to elaborate why the IV is needed in these cases?

Because the CBC mode of symmetric cipher requires IV to decrypt the encoded key, as explained in the common picture of Cipher Block Chaining (CBC):

.

The IV is not part of the passphrase, because it is not a secret. It was generated as a random number, but you can decrypt the key itself only with the knowledge of this IV.

  Given a password protected private key like:

And note that it is not a password, but pass-phrase, which makes it basically the source data for key encryption key.


How to avoid clickjacking in HTML and Javascript I tried to put the following code in HTML but it is not helping me avoid me the clickjacking:

meta http-equiv="X-Frame-Options" content="DENY"

I wrote the following code in Javascipt:

if (self == top) {
            document.documentElement.style.display = 'block';
        } else {
            top.location.replace(document.location);
        }

This solves my problem, but I don't want to redirect it a new URL, but instead, I want to show the clickjacking URL with an empty iFrame.

This is the HTML code  I am using to test clickjacking:

    iframe {
    width: 800px;
    height: 1000px;
    position: absolute;
    top: 0; left: 0;
    filter: alpha(opacity=50);
    opacity: 0.5;
    }

<iframe src="URL">

I want to display only an empty frame when I run the above code.

Hide the whole page:

<style id="antiClickjack">
  body {
    display: none;
  }
</style>

And remove that style element if this window is the lop level window:

<script type="text/javascript">
   if (self === top) {
       var antiClickjack = document.getElementById("antiClickjack");
       antiClickjack.parentNode.removeChild(antiClickjack);
   }
</script>


Is it possible to perform one-way OTR MITM? Here's something that is bugging me recently: suppose that me and my friend establish an OTR session and - as a result of that - DH key exchange is performed. My friend verifies my key, but I cannot verify his fingerprint. Despite that, we have a secure channel over which he can send me one bit of information - whether my key was valid or not. Can I trust the OTR session if he successfully verified my key and sent me this confirmation or is there still a risk of a man-in-the-middle attack?

I ended up asking on the OTR's developer mailing list and here's the response I got:

  On Wed, Apr 08, 2015 at 02:51:14PM +0200, Jacek Wielemborek wrote:

    Hello,

    Here's something that keeps bugging me for a moment. It's a hypothetical
    situation, so please refrain from question like "how did you send the FP
    to your friend?".

    My friend receives my OTR fingerprint over a secure channel (e.g.
    meeting in person), but he doesn't give the fingerprint to me and
    destroys the channel,
    Me and my friend establish a perfectly secure channel that has two
    limitations: my friend can only send messages to me (not the other way)
    and only one bit of information can be transferred.
    We agree that over this channel, he will tell me during a future OTR
    session whether my fingerprint matched what he received from me during
    step 1,
    We go back home, establish an OTR session over the internet, which
    isn't secure yet. My friend verifies my fingerprint based on what we got
    during step 1 and tells me whether it matched over channel from step 2,

    If the fingerprint he sees on the screen matches the thing he got from
    step 1, can I assume that there can be no man in the middle? In other
    words, is it possible to perform a one-way OTR MITM where my friend
    actually sees my real fingerprint, but when he responds, I can't see
    his, but one from the MITM?

    Hopefully I explained this clearly. Cheers,
    Jacek Wielemborek

  Jacek,

  Way back in OTRv1, this was actually possible.  However, the MITM
  wouldn't be able to read, write, or modify the messages; the issue
  was that your buddy would see your key as being the partner in the
  conversation, while you would see the MITM as being your partner in
  the conversation.  (The messages would actually be going to your
  true buddy, though.)

  We upgraded the key exchange protocol in 2005 to address this problem,
  and I do not believe a MITM could pull this off with OTRv2 or OTRv3
  (unless one of the endpoints were compromised, of course).

  [Even better is to exchange a shared secret in your step 1 instead,
  and then use the SMP to mutually authenticate your long-term keys.
  But this requires a secure channel in the secrecy sense, whereas
  your version only requires a secure channel in the authenticity
  sense; the latter is sometimes easier to pull off in practice.]
  --  Ian Goldberg Associate Professor and University Research Chair Cheriton School of Computer Science, University of Waterloo Visiting
  Professor, ESAT/COSIC, KU Leuven


Work computer picking up on personal computer on home wifi? I have a work computer that I sometimes bring home so that I can get work done. I know that I can't use that computer for personal reasons. My question though is, if I'm using my own personal computer can my work computer pick up what sites I've visited because it's on the same network? Then, will it still keep that information on it when I bring it back to work, even though it's no longer connected to my network?

While the answer below is generally correct, keep in mind that some websites track your browsing activity using sessions, and this data will be saved even if you change computers... The reason I think this could be important to you is that things like your search history using Google may be transferred to your work account if you use one account on both computers... Under normal circumstances, it should not be possible to view this data across the network - but it can be seen physically at your work place.

edit: the answer above is not precisely correct, the truth is - your data across the network is not separate at all, it's possible to see any data sent across the network even from a separate computer (albeit, some of it may be encrypted, ssl, etc...). Under reasonable circumstances, though, this should not happen in your case.


SHA 1 no impact to root certificate I ran a scan on a server and the results of the authentication for digital certificate was as follows :
Certificate 1 (root) signature algorithm: Sha256withRSA

Certificate 2 (chain of trust) signature algorithm: SHA256withRSA

Certificate 3 (chain of trust) signature algorithm: Sha1with RSA (weak but no impact on root certificate). This certificate shows in the certificate path as trusted.

There is a lot of literature online that SHA1 should be replaced to SHA 2 to prevent brute force and MITM attacks due to its weaker algorithm.

Could someone help me understand the risk if the root certificate is a SHA2 while the chain of trust certificate is a SHA1? Can a client use the chain of trust certificate instead of the root certificate?

The signature algorithm used in the root certificate is not used to establish trust against the root certificate because a root certificate is trusted by the virtue of a copy of the root certificate is installed in the browser, either included in the browser as part of the installation, or added later by the user to their certificate store.

For the rest of the trust chain, including intermediate and end certificate, a root certificate asserts the authority and encoded data in the intermediate certificate by cryptographically signing the signature of the intermediate certificate with its private key. Likewise, the intermediate certificate asserts the authority and encoded data in the end certificate by cryptographically signing the signature of the end certificate. There can be more than one level of intermediate certificates.

If an intermediate or end certificate has a weak signature, then it is possible that an attacker can generate two certificates with the same signature with different encoded information (e.g. looks-harmless.com and your-bank.com). The attacker can then ask a certificate authority to sign one of the certificate (looks-harmless.com) then copied the signature to the other certificate (your-bank.com).

The problem with SHA1 is that it has flaws that renders it feasible for an attacker with sufficient resource to find such collisions.

In your example, if intermediate Certificate 3 has SHA1 signature, then it is vulnerable to this attack. If the scanner didn't flag this chain as untrusted, then it should have.


It's really that insecure to have POP3 enabled in my gmail account? Several people are claiming that you should turn off pop3 in gmail because it allowed bruteforce attacks on the password.

Doesn't Google prevent this kind of attacks? What is the truth on this claims?

IMAP is so slow with Outlook that I really want to keep using POP. I have a strong password in place.

If the password is strong, then there is no worry whatsoever.

POP3 does not open new ways for cracking passwords IF you use it sensibly, i.e. within SSL/TLS. Otherwise, depending on the underlying authentication mechanism, a hash of your password may transit on an unprotected connection (bad !), or maybe even the password itself (worse !).

A feature of POP is that the emails are removed from the gmail servers once you retrieved them, so:

you can no longer read them through the gmail Web interface;
you no longer benefit from the disk redundancy and automatic backups of the Google infrastructure;
you can read your emails locally even when deprived of an Internet connection.

Therefore, this is not only a problem of performance and brute-force attacks.


Why doesn't nmap return open port info when I fragment packets? I'm performing a scan on a remote host and playing around with the -f flag for nmap when I noticed something I hadn't expected. In amongst the other data, when I type nmap -v -O <hostname> I get a listing of open ports and OS details:

PORT    STATE   SERVICE
22/tcp  closed  ssh
80/tcp  open    http
443/tcp open    https
Device type: general purpose
Running: QEMU
OS CPE: cpe:/a:qemu:qemu
OS details: QEMU user mode network gateway
TCP Sequence Prediction: Difficulty=17 (Good luck!)
IP ID Sequence Generation: Incremental

However, when I scan the same how with nmap -v -f -O <hostname>, I get:

All 1000 scanned port on <host> <ip> are filtered
Too many fingerprints match this host to give specific OS details

Can anyone explain why fragmented packets act differently in regard to the information received? Is the remote host likely set up to block fragmented packets, maybe?

Found this in the nmap documentation at: https://nmap.org/book/man-port-scanning-basics.html

  IP fragmentation is a complex system and implementations are riddled
  with bugs and inconsistencies. Possible tests could examine how
  overlapping fragments are assembled or time the defragmentation
  timeouts. These tests are avoided for Nmap because many firewalls and
  other inline devices defragment traffic at gateways. Thus Nmap may end
  up fingerprinting the firewall rather than the true destination host.
  In addition, fragments are difficult to send on some operating
  systems. Linux 2.6 kernels have a tendency to queue the fragments you
  are trying to send and assemble them itself before transmission.

So it seems that the process of fragmentation may be causing problems with the lookup. I would still appreciate any answers that explain this in more depth, though, if that is within the scope of the site.


What are security risks of connecting to my home vpn from my work? I connected to my home-made VPN, which uses OpenVPN and 2048bits encryption keys, from my work.

What are the security risks of doing so, given the fact that the servers are in the same network my work's PC is, and how can I minimize them if any?

Thanks

EDIT:

What I mean, is that the IT Manager seems to be pissed off by the fact that I connected a to my home via VPN to take some configs of my personal home server to apply to a server I manage in my work.
I am sure he will say that "There are security risks" by connecting to my home.
I sincerely don't see many risks, apart from having a super hacker in my home network which would be stupid because who would be interested in it? So, suppose this super hacker can connect to my Work PC from my home network while I am connected to my VPN. This is very difficult because I don't use the same password in my home and in my work, so he would not be able to SSH to my work pc, etc.

This is the only security risk I can think of... so I would like to hear from you if there are some others.

I can understand why your IT Manager is upset.

How would you feel if some one, without your consent, bridged an unknown network with your home network?

You arguably bypassed any controls they had in place and bridged a completely foreign network with that of (what I can only assume is) a multi million dollar corporation.

  What are the security risks of doing so, given the fact that the
  servers are in the same network my work's PC is, and how can I
  minimize them if any?

The risks are the same as any other PC/Server exposed to the internet - endless.

  I sincerely don't see many risks,

And that is precisely why your behavior could be construed as reckless. Just because you don't see any risks doesn't mean there are none.

  apart from having a super hacker in my home network which would be
  stupid because who would be interested in it?

There are many reasons for a hacker to be interested in your home network. For example:

Image from: http://krebsonsecurity.com/2012/10/the-scrap-value-of-a-hacked-pc-revisited/


Is a ddos attack that makes ssh auth attempts a possible way for attackers to significantly impact your system? I'm noticing on my digital ocean server, that I'm getting a high volume of auth attempts. I don't have any passwords since I use sshe key auth, so I'm not worried about a break in. But can a determined attacker basically kill a system by sending auth requests?

Is there anything you can do to protect against ddos attacks like this?

DDoS attack is distributed denial of service. By opening a large amount of connections to your server, attacker can reach the maximum limit of parallel authentication requests of ssh server (defined in sshd_config variable MaxStartups) and prevent valid authentication requests to fail. Additionally, an unauthenticated session from an attacker is dropped after the time defined as LoginGraceTime in sshd_config (default 120s).

Fortunately, this feature is implemented in a way that should limit DDoS attacks by using "random early drop" using three values: "start:rate:full". Default value is 10:30:100, which translates to:

  sshd(8) will refuse connection attempts with a probability of “rate/100” (30%) if there are currently “start” (10) unauthenticated connections.  The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches “full” (100).

(from manual page for sshd_config(5))

This means that attacker can't "kill" your system, but at some point, you would need to retry before you will get connected.


What is the best way to get OWASP ZAP to fuzz parameters with real data? I'm trying to import and scan Open API Definitions and it seems to me that the url parameters and request body are not being replaced with real data. Is there a way for OWASP ZAP to automatically replace those parameters and body requests with real data? If not, what other optimum solutions are there solve this?

Thanks in advance!

The best option is to proxy requests that use real data through ZAP. These could be unit tests or something as simple as command line calls to curl. You can also make calls to the target system using the ZAP API.

The Form Handler add-on also allows you to specify values for individual fields, but I dont think this handles URL parameters.


Why does this XSS vector work in svg but not in HTML? Why does this vector :

<svg><script>alert&#40/1/.source&#41</script>

works in http://jsfiddle.net/ZgPY4/2/ and
this one

<script>alert&#40/1/.source&#41</script>

doesn't. How is <svg> making it work?

HTML <script> has special powers other elements don't: it is a "CDATA element". That means that any < or & characters up to the end of the element are taken as literally meaning those characters. So what is passed to the JS interpreter is:

alert&#40/1/.source&#41

which is obviously not valid JS syntax.

The concept of a "CDATA element" comes from the SGML world from which HTML developed. But SVG comes from the XML world where things are simplified and there are no CDATA elements. Consequently the SVG <script> element has no special powers: inside an SVG script, < introduces a tag and & introduces an entity or character reference.

Consequently the &#40 gets parsed to ( and the resulting string passed to the JS interpreter is:

alert(/1/.source)

In XML terms the <script> element is in the HTML namespace and the <svg><script> element is in the SVG namespace, so they are different elements. HTML5 makes this all less clear by hiding the namespace prefixes and applying a non-XML parser to the SVG (which is why &#40 works despite it being non-well-formed; should be &#40;).


Authentication methods without trusting 3rd parties unless explicitly indicated The plan is to have a situation in which no third parties have to be trusted unless you explicitly indicate so. For example CA's are only used when the contact explicitly added the CA as a trusted party (there will be no such thing as root CA's or trusted CA's signing other CA's).

Methods I collected so far:

The above CA example.
Using a web-of-trust.
Sending a one time password to an un-authenticated public key, requiring this password to be sent back to you through another medium to prove it's you. Such as an SMS from a number that was known in advance or face-to-face. Since only the private key holder would be able to know this password it proves they own it.

Are there any other ways to authenticate certificate owners when you are not bound by standards but cannot distribute hardware in advance?

To clarify:
It's about verifying the private key holder is really the person you believe should be the holder. So in other words it's about authenticating the identity of the owner of the certificate.
So like: "Hey dafrank25@hotmail.com! Are you really the Frank I know from class?"

Please define what exactly you want to authenticate about the party you are communicating with.  Do you want to authenticate the name on their driver's license?  That they have a valid credit card number you can charge?  That they control a particular domain name?  That they are your customer and control account number such-and-such?   Something else?

For many web sites, all they need to know is that you are the same individual who created the account initially.  When you log into your Gmail email account, all you need to do is to prove that you are the same person who initially created that account.

For many e-commerce web sites, all they need to know is that you have a valid credit card number and will pay up.  For instance, when you log into your Amazon account and buy something, all that they need to know is that you are the same person who initially created that account and that your credit card number is valid and the charges on that credit card will be accepted.

Neither of these scenarios require certificates (they can be accomplished with certificates, but they can be accomplished in other ways as well).

In short, authentication is a broad subject.  The way we authenticate another party depends upon what, exactly, we want to authenticate about them and what guarantees we want the authentication method to provide.


Failed PCI-DSS Compliance | Submitting Evidence One of our web servers that is managed by a service provider (completely in their control, we have no login access) just failed PCI-DSS vuln. scan by TrustKeeper. The vuln scan detected the box as a Windows Server 2003 SP1 OS (extremely out of date).

I submitted the report to our service provider (along with an angry email). They responded with a simple cropped screenshot of sysinfo screen showing SOME windows 2k3 sp2 box. I have no way of knowing if that screenshot is from our box or not, and based on history with the provider, I'm inclined to think they just grabbed it from another one of their boxes to cover their butts.

With no AD or login access, it's impossible for me to know for sure the SP level of this box.

Question:

Is a simple sysinfo page screenshot enough for PCI-DSS compliance evidence? I can't imagine it being since as stated, it could be from any system. But then how to get evidence from this box that shows it really is our box and really is SP2?
How to remotely verify the SP level of a box. I've had no luck with nmap.. is there another way to prove it's not updated?

See this Server Fault question for my OP.

In order for such evidence to be accepted, it needs to be possible to tie the information in the image showing the Service Pack level to the system (IP address/URL) being scanned by Trustkeeper. A screenshot that has different windows open that shows you're providing appropriate evidence for the correct system should do the trick.

Do you know if the Service Provider is performing internal vulnerability scans on those systems? Perhaps you could get access to those results.

You could try running an online tool such as http://www.yellowpipe.com/yis/tools/craftnet/ though you're unlikely to get a different result to nmap.

As you'll have been running external vulnerability scans every 3 months, has this system ever failed before?


Skip date check in Server certificate in Chrome We have a web application on https port with server certificate valid from 01/01/2021 and valid to 31/12/2021. Due to some constraints the clients which are going to use web application are behind current date, while the server is on current date time. There is no issue in production as server and client both are on the current date time. When i try to connect to web application from client (whose date is of July 2019), i get SSL error in chrome.

Your clock is ahead. A private connection to "ServerName" can't be
established because your computer's date and time (Wednesday, July 31,
2019 at 11:00:13 PM) are incorrect. NET::ERR_CERT_DATE_INVALID Update
date and time. To establish a secure connection, your clock needs to
be set correctly. This is because the certificates that websites use
to identify themselves are only valid for specific periods of time.
Since your device's clock is incorrect, Google Chrome cannot verify
these certificates.

Also in the URL following error is there

This certificate has expired or is not yet valid.

I know i can change the client date to current date time and its working. But since there are some constraints i cant do that. I googled and not found any solution, Is there any option to disable the validity check or any other option to proceed with.
Thanks in advance.

There is no way to disable the expiration check of a certificate. If there is a way to accept the certificate anyway depends on the use of explicit HSTS (via Strict-Transport-Security HTTP header) or implicit HSTS (i.e. specific domains like .dev) always require HTTPS. If HSTS is used a certificate which is considered invalid cannot be accepted.


Best way to scan for and eliminate earlier versions of SSL/TLS in a production environment Due to new PCI DSS standards mandating that nothing lower than TLS 1.2 be used in a PCI environment, I am tasked with phasing out anything lower than TLS 1.2 on every device in this environment by our next audit next year.

Question:

What would be the best method of maneuvering through the environment and seeing which devices are still using deprecated versions of SSL? I know that I can use OpenSSL s_client to perform handshakes on machines, but is there a way to automate this or perhaps do this against multiple machines instead of going through a list and trying to perform a handshake against every single system? There are quite a lot of machines in this environment.

@atdre points to a tool that should allow detecting whether a given server supports TLS 1.2, but this is only part of the story. In SSL/TLS, the initial steps of a connection are the handshake in which a number of parameters are agreed upon between client and server, including the protocol version that will be used. The client announces the highest protocol version that it supports, then the server chooses the version that will be used (normally, the highest version that the server knows, but no higher than the maximum version announced by the client).

Therefore, even if all your servers are ready to use TLS 1.2, this does not necessarily imply that only TLS 1.2 will be used; it depends on what the servers would accept besides TLS 1.2, and what the clients support. For a given server, you have basically two methods to ascertain that TLS 1.2 will be used:

Make sure that the server supports only TLS 1.2: if a client announces "TLS 1.1" as highest version, the server should reject it. If a server accepts only TLS 1.2, then only TLS 1.2 will be used when talking with this server.
Check that all clients that talk to the server announce TLS 1.2 as highest version, and the server accepts. This basically entails running a network monitor tool (e.g. Wireshark) to observe the ClientHello messages actually sent by clients, and the ServerHello messages sent in response.

Further complications come from the "auto downgrade" behaviour of some clients (typically Web browsers). The client may try to connect, first, by sending a ClientHello that says "I support up to TLS 1.2". If that fails, though, the client may think that the server might be allergic to TLS 1.2 -- it is known that there are still a few deployed Web server that do not follow the specification properly, and simply drop connections when they see "TLS 1.2" because they do not understand it. In order to support these poorly implemented servers, some SSL/TLS clients, upon a handshake failure, will try again, this time with a ClientHello that announces "I support up to TLS 1.0".

Unfortunately (for your present situation), this means that even though a client and server seem to use TLS 1.2 under normal conditions, an active attacker may abruptly break connections that begin with a TLS 1.2 handshake (the active attacker injects spurious RST packets to kill the underlying TCP connection). In such a situation, the attacker may trigger the auto-downgrade mechanism, and force client and server to use a lower version.

So if you really want to make sure that only TLS 1.2 is ever used, even in the presence of a crafty attacker, then only the first method should apply. In other words, using sslyze or any other similar tool, you must make sure that when a client asks for TLS 1.2, it obtains TLS 1.2, AND also that if a client asks for TLS 1.1, the server rejects it.


Why is Google trying to communicate with svchost.exe First off - I usually target my questions to StackOverflow since they're programming related, and I usually login with my work account - so this will be my first post from this account, as well as my first post to this site - so I apologize if this question belongs elsewhere.

I have Eset installed on my Windows 7 machine, and only recently decided to tighten security. So I set Eset to inform me anytime there is attempted inbound and outbound traffic. I've been getting this message:

**Inbound Traffic
A remote computer is attempting to communicate with an application running on this computer. Do you wish to allow this communication?
Application: Host Process for Windows Services (svchost.exe)
Publisher: Microsoft Windows
Remote Computer: nuq04s19-in-f5.1e100.net (74.125.239.37)
Local Port: 64820**

When I swung around to my Debian machine, I plugged the IP into a whois query, and discovered that this is within an IP block owned by google.
So, my question is this - why? I mean, I have Chrome installed, and thereby I also have related Google processes running. So - first question is: if Google wanted to update, or otherwise connect with some of my running Google programs for whatever reason, why aren't they just knocking on those doors instead of svchost.exe? Second question: if anything at all, shouldn't svchost be what is attempting to contact Google instead of the other way around?

Try the following to identify what is communicating with Google:

Since you have the local port and destination run netstat -ao or netstat -nao to get the PID.
Now that you have the PID run Sysinternals Process Explorer with elevated/administrator permission.
Find the svchost with the corresponding PID.
Hover your mouse cursor over the process.  The tooltip will inform you of the different services running under that svchost.

Now that you've identified the right svchost, its a matter of figuring out which service within the process would be contacting Google.  Often they're unique enough where this can be easily determined at a glance.


Android Messages Web and Privacy Recently Google rolled out the feature to send SMS/Chat messages over Web via their Android Messages app.
The approach seems similar to the WhatsApp Web Client. What I didn't find however are technical details on how Google ensures privacy and confidentiality.

The setup is also done via QR code and suggests to me that there seems to be some sort of secured channel between the phone and the web browser. I currently believe that due to this, the browser ultimately just receives and sends the information to the phone, where everything is processed. It somehow has to be as I am sure that several people have encrypted their devices. The one thing that gives me doubt is the Smart Reply feature. Would the smart reply be created on the phone and relayed to the browser or would the browser do it on its own?

The question to me now is if this is how it works and how is it ensured that everything I would do on the web app just goes to the phone and not somewhere else?

Not sure if you found any answer, but have had the same question RE security/privacy and came across this thread higher up on google. Was able to find some information but not much. Some of the below is inferred as mentioned.
To confirm/make clear - this is what found between wireshark/monitoring, on the web, googles help page below, etc. and not all of this is for-sure/confirmed, I tried to make clear which are speculation/assumptions and which are not, just keep in mind :)
Encryption
Note that at it's core Android Messages is built around RCS (granted also supports SMS), and unfortunately like SMS - RCS as stands today is NOT end-to-end encrypted which is very unfortunate especially considering Google's one of the main players in RCS's development, but that's a separate topic.
Linking & Browser Storage
From: https://support.google.com/messages/answer/7611075?hl=en

[...] Messages for web sends SMS messages using a connection from your computer to your phone, so carrier fees will apply, just like on the mobile app.
Note: The QR code for Messages for web is unique to your computer and pairs the mobile app to that computer. You can pair your Messages account on multiple devices, but only one will be active at a time. When you open Messages for web on a computer, your conversations on any other computers or browser tabs will become inactive.
Note: Your latest conversation threads, contacts, and other settings will be encrypted and cached on your browser. If you don’t use your Messages account for 14 days, you’ll automatically be signed out for security reasons.

To clarify the above only covers the storage of that data on your computer/browser.
Browser to Google / Google to Browser
Due to it's nature (within a browser/web HTTPS) the communication between your computer and google is at least encrypted using TLS 1.2 (dependent on browser/environment*) and communicating with what you would expect / play.google.com and ssl.gstatic.com etc. so that side is secure on transmission/receipt.
Google to Phone / Phone to Google (Unknown)
(Speculation) Would assume and expect/pretty confident that SSL/TLS is handling the connection but can not say for sure (someone can wireshark to confirm but very unlikely it's not SSL).
What's doing the sending
From what information IS available, all say yes the phone IS doing the actual sending/receiving You can turn off your phone, or go into Airplane mode/no data connection and Messages for Web will not work until it comes back on. While that doesn't prove it on it's own, all major publications have stated as fact from the initial announcement
From same page linked above:

On your phone, you need: [...] Wi-Fi or data connection

From the above information, it would make sense that as you mentioned it's just creating a link/sync between your Phone and the Browser client, with your phone doing all the processing which could include Smart Replies (speculation) - though also while logged into your Google Account / associated with it, if you have your typing data stored with Google for personalization etc then Google could be doing that on their end without hitting your phone, but that would seem like more of a hassle since need a two-way sync anyway.
Privacy
On the privacy side, really should check out the Privacy Policy as I haven't had a chance to. Unfortunately it appears it's just their overall Privacy Policy & Terms which is pretty all-encompassing, but that's often a good way to get details on what/why/sometimes how.
Overall
Unfortunately regarding your question how to confirm it's just going to phone and no where else, that is hard to get an answer for and really just comes down to trust in Google. Remember when sending from the web it's not going straight to your phone, it's passing to Google which then is passing it to your phone/vice versa.
You wouldn't THINK it's going anywhere else but never know, additionally keep in mind that by opting into Android Messages on the Web your SMS/RCS data is passing to/through Google where it may not have been before. I'm NOT sure on this, but I would be curious if with Android Messages on its own (no web link) google has/had any access to full/raw SMS/RCS messages/data (?) - knee jerk I wouldn't think so (though they usually do have your typing data and WHO you text/frequency - metadata etc).

If anyone else has any additional information on the details of how this is working would love to see as well!


Any way to auto execute a file in windows MS-Word gives the functionality of OLE In which we embed any link in document and on any event it would go to that link and download the file.
The file is stored in the TEMP directory of the WORD.
How can a hacker executes that file say from the OLE it downloads an .exe but there need to have something that can execute.
Is there any way an attacker could run this file on my system ?

thanks.

That would be a very large security hole, so no, generally speaking, there isn't any way to do that. There have been security bugs in the past that permitted things like this in specific scenarios (such as downloading a file that executes when viewed in Windows Explorer), but they were patched. There are ways to do this if you have arbitrary control over where the file downloads to (in fact, that's relatively easy; just drop it in the user's "Startup" folder in their Start Menu or modify some shortcut that the user runs regularly), or can otherwise make certain changes to the file system, but just dropping a file in a temp directory won't do it.

There are ways for an Office document to ask the user for permission to do unsafe things, and those unsafe things can include running programs. However, these requests will cause somewhat-scary-looking warning dialogs that users much approve the risk of before the attacker's code will run.

Also, there's usually no need to drop a file on the user's system, if you have some way to execute an arbitrary program. Run the program over the network or (if you can use command-line parameters) just have CMD or Powershell execute a script that you stuffed into the command line.


Can IPs be trusted inside a VPN? Question

I have several linux clients connected to an OpenVPN server. Each client is given a persistent IP based on their X509 Common Name. Can I trust these IPs ?

Context

I have Client1 and Client2 connected to Server, all of them in an OpenVPN network:

I'd like to set up a NFS share to allow Client1 (exclusively) to access to some files on Server. The TLDP page about NFS and security states that the IP whitelist in /etc/export is "not terribly secure". Does this still hold true inside a VPN ? More precisely, is it possible for an attacker to spoof or take over Client1's IP address in a way that could allow access to the NFS share :

if he owns a copy of Client2's credentials?
if he has root access to Client2?
if he has physical access to Client2?

Specifics

(feel free to assume different software versions, configurations and/or encryption levels if you need to)

OpenVPN version is 2.2.1 x86_64-linux-gnu
The config file at /etc/openvpn/server.conf contains, among other lines:

cipher AES-256-CBC
client-config-dir ccd

And the ccd folder contains a file for each client, containing this one line:

ifconfig-push 10.20.1.N 10.20.0.1

with N the ID of the client (1 or 2 here)
ccd-exclusive is not enabled in the config file
Signature algorithm is SHA1 with RSA encryption
/etc/exports will allow a single IP to access the share :

/some/dir 10.20.1.1(ro,all_squash,sync,subtree_check)

Note: Please point out any other problem with my setup in the comments of the question. I will definitely look into it, but for the sake of leaving an usable artifact let's keep this thread about IP spoofing. Thank you very much for your time!

The first problem is since your using the same system as VPN endpoint and NFS share, its possible to 'spoof' the allowed ip address on the other side (e.g the public line of the server) unless mitigated through other means. (the NFS service has no idea that a specific IP should be on a specific interface)

The second is that if 1 of the machines is compromised in any way, it can be utilized as a relay for IP spoofing (Client2 can be setup than as a 'hop' between the attacker and the server spoofing Client1's IP in the process)

This is a hard to implement scenario, but doable for profesional attackers. (they have to find client1's IP for example) and if you limit NFS to only accept connectinos through openVPN, and at the same time employ a proper Intrusion detection. than the 'ip' filter can suffice for limiting the connection to only client1.


Does perfect forward secrecy work with group chats or chat history? I'm curious if perfect forward secrecy could work in an app like WhatsApp where you want to see messages from before the last message or a multitude of messages at the same time like in a group chat.

As I understand perfect forward secrecy changes the key every time so that older messages that were not encrypted with that key are not susceptible to being decrypted if the last key is lost. If thats the case and I'm sure it is, you can only see last message

I think you mean Perfect forward secrecy, which WhatsApp does support in its end-to-end encryption. PFS is difficult for chat apps, because of the uncertainty in the connection, and is the reason many chat apps just ignore it.

In normal PFS (like TLS or SSH) an ongoing connection is established and the keys are recalculated every so many bytes or minutes.  Chat apps cannot acknowledge a message (or any data) was received. In fact, the other end of the channel may never have sent any data your way, or was just offline the whole time. In any case, you as the sender should be able to secure the messages that you sent, regardless of the other end.

To overcome this entire problem protocols such as OTR en Axolotl use prekeys. These prekeys are pre-calculated Diffie-Hellman (or EC like Curve25519) keys. It is common to calculate a few hundred keys in advance. All of the public keys from these pre-calculated keypairs are send to the relay (chat) server, and advertised together with your public identity key (the public identity key is really your 'name' towards others). Now that the public prekeys are on the relay server, anyone who want to send you a message can just pick one of your prekeys and calculate the shared secret.

The message is then encrypted and authenticated using the shared secret and send to the receiver together with the prekey id. Once the receiver pulls the message from server, it can decrypt the message with the corresponding private prekey. A new prekeypair is generated and send to the server to take its place. This system goes on forever.

Both sender and receiver have to keep track of all their prekeys still in use. This entire algorithm is known as the Double Ratchet.

Apps using Axolotl:

WhatsApp
Google Allo
Facebook Messenger
Signal
Viber (claimed)

Update

The protocol is self healing because every message is encrypted with another key. This key is no longer known when the message is decrypted, and the message itself is stored in the local app database. Here comes the trick: the messages are not chained in order, so at best one prekey (one message) is compromised. This has no effect on the other messages. Every message is encrypted with another key (Perfect secrecy). The messages itself do not depend on each other and thus an attack on the last message does not give the attacker control over future communication (Future secrecy). Note: The protocol has some disadvantages as well, like messages orders, or lost messages.

Update 2: Group chat

From the protocol point of view, there is no such thing as a 'group chat'. It is just the same message send multiple times to people, like emails can be send to multiple recipients as well. Each of these messages is encrypted with the receiver's prekey. For example, if the group contains a total of 4 people, including you, then the same message is send 3 times (technically only send once, containing 3 messages) to each of the group members. Therefore it is required that each message is signed and encrypted with the shared secret between you and the receiver. Note: The latest version of the TextSecure protocol can optimize this process somewhat by encrypting the message once, and sign it multiple times. There is a proposal to introduce temporary group keys for larger groups. To my knowledge this has not made its way into WhatsApp yet.

If a new user joins the chat, there is no history for that user since chat messages are kept on the local device (obviously). See this as an advantage, every user of the group is responsible for keeping the messages private. A synchronisation solution will; 1) increase the attack surface, 2) increase complexity of the cryptosystem and 3) move ownership of messages around.


Why do I have a specific route for this strange IP? I use ubuntu. The only apps I have in it are firefox and telegram, both downloaded through official channels. I use other apps with virtualization, so my main machine is mostly clean.

I use a VPN so everything goes to it through a tun interface. Here's my route -n output:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.8.1        0.0.0.0         UG    50     0        0 tun0
0.0.0.0         192.168.25.1    0.0.0.0         UG    600    0        0 wlp1s0
10.8.8.0        0.0.0.0         255.255.255.0   U     50     0        0 tun0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 virbr0
192.168.25.0    0.0.0.0         255.255.255.0   U     600    0        0 wlp1s0
192.168.25.1    0.0.0.0         255.255.255.255 UH    600    0        0 wlp1s0
192.168.122.0   0.0.0.0         255.255.255.0   U     0      0        0 virbr0
195.181.167.147 192.168.25.1    255.255.255.255 UGH   600    0        0 wlp1s0

I noticed this strange IP 195.181.167.147 which connects directly through my gateway, thus bypassing my VPN. The other bypasses were made by me using ufw: I added bypasses to 192.168.25.0/24 so I can access my local network

I don't know how it got there, but I had a cron job that bypasses by proton VPN for a dynamic IP, which is given by a domain name:

#!/bin/bash
HOSTNAME=my.domain.com
LOGFILE=$HOME/ufw$HOSTNAME.log
Current_IP=$(host $HOSTNAME | head -n1 | cut -f4 -d ' ')

if [ ! -f $LOGFILE ]; then
    /usr/sbin/ufw allow from any to $Current_IP port 1194 proto udp
    echo $Current_IP > $LOGFILE
else

    Old_IP=$(cat $LOGFILE)
    if [ "$Current_IP" = "$Old_IP" ] ; then
        echo IP address has not changed
    else
        /usr/sbin/ufw delete allow from any to $Old_IP port 1194 proto udp
        /usr/sbin/ufw allow from any to $Current_IP port 1194 proto udp
        echo $Current_IP > $LOGFILE
        echo iptables have been updated
    fi
fi

I thought the strange IP had something to do with this cron job. But I don't think my.domain.com ever had this IP. I don't even think this cron job alters routes. And I also think that I don't even know what this cron job is doing now that I'm looking better at it.

A simple google search on this IP gives one result of an user on reddit talking about Proton VPN, which is the VPN provider I use. But the post is gone now.

Does anybody have any idea of what is happening?

UPDATE:

here's the reddit cache: http://webcache.googleusercontent.com/search?q=cache:46CfMx_bnzQJ:https://www.reddit.com/r/ProtonVPN/comments/8s40e5/pfconf_configuration_for_protonvpn_macos_app/&num=1&hl=en&gl=uk&strip=1&vwsrc=0

I also didn't install anything from proton VPN, I use only open VPN with proton VPN configuration files

I think I found what's happening everytime I change my VPN connection to another country, this specific IP changes. Of course, it's the open VPN app making an out connection to the server so the connection doesn't go through the tun device for the open vpn client


How can I avoid Canvas Fingerprinting? Canvas Fingerprinting has been getting a lot of press these last few days.
Here is a study I read on this topic: 1 and 2

What can I do to keep browsing anonymously and avoid this tracking method?

Well if you are using Firefox you can use NoScript but right now "Canvas Fingerprinting" is really a new buzz word but when more people know about it the more developers will make addons to counter Canvas Fingerprinting.

There are several options to block Canvas fingerprinting

TOR web browser.
Yesscript.

More info here Canvas Fingerprinting


Should I implement my own local password hash? Having a more-than-elementary knowledge of internet security, I've realized that some web applications and websites I use implement a less-than-ideal password policy. Some examples include:

Implementing a password-length upper-bound (upper-bounds I have seen are 16, 20, and 32)
Requiring the presence of arbitrary characters
Forbidding the presence of arbitrary characters (such as spaces, %, ^, and others)

These kind of practices make me worry that the server-side encryption is equally questionable.

Thus I'm wondering if it would be a good idea to implement my own script (drawing on tried-and-true methods) to create a hash of my password on my local machine and then rehash it until it meets the sites arbitrary requirements and use that as my 'password'.

What you describe is one of the two main methods used by "password vaults" products. Such products try to make it easier for you (the human user) to "remember" site-specific passwords, while still maintaining the important property, that is the specificity of passwords: one password for each site, so that a breach on one site does not endanger your accounts on other sites.

The two main methods are:

Try to "derive" (through hash functions or similar construct) a site-specific password from a master password; the site name is then used as extra parameter, to make sure that each site get its own password.
Generate random passwords for each site, and store them locally (on the client), encrypted with a "master password".

In both cases, you need client-side software, because there is no known method to achieve the one-wayness required for proper specificity with only human brain capabilities (see this previous question). Such software can be a local application, some script, a browser extension...

Your proposal relates to the "type 1" method (derivation from the master password). The usual hope is that the "type 1" method may allow for dispensing with local storage. Unfortunately, this fails on two accounts:

As you have noticed, password rules mandated by various sites are incompatible with each other, so you can not produce passwords which can fit all possible sites. Therefore, something in your system must remember the rules for each specific site, so that the site password can be recomputed properly.
Some sites mandate password changes at more or less regular intervals. A no-storage password derivation cannot cope with a password change.

"Type 1" password vaults still have value, in that the required local storage needs not be confidential, since it includes nothing which depends on the master password (it does include information about all the sites on which you have accounts, though, and that may be a privacy issue). On the other hand, each site-specific password may be used for an offline dictionary attack on your master password, which can be a problem.

"Type 2" password vaults are more flexible and are thus more common (e.g. KeePass). Some of them couple with a centralized storage (see 1Password) so that you may have access to your passwords from all your devices. A really good point of "type 2" vaults is that the site-specific passwords, being randomly generated, cannot (in a strong mathematical sense) leak information about your master password or passwords for other sites.


Key-exchange over the network with more than two peers Me and my team is developing a multiplayer videogame with a Client/Server-Topology. This secures the match from clients who have the intention to cheat because of server authority but still allows the server to modify outgoing and incoming packets as well as sensible user data of the players.

We chose to use AES as the encryption method, but had the problem of informing all peers about the used key to secure the network-packets with this encryption method.

I read into the Diffie-Hellman-Merkle key exchange algorithm which worked perfectly between two peers (Alice and Bob how they are called in the examples). The problem is that our game allows matches with a variable number of players, ranging from 2 to 16.

The condition seems to be that every client needs to generate the same number b (exponent of g) to share its equation result with the server, so that both have the same result which is s.

I have no clue how to generate a secret key on every peer, if the time at which clients connect and the number of connections over the match are variable.

You should not deploy your own encryption scheme for this, neither share symetric keys with multiple parties.

To protect data on transit between each client and the server, you should use TLS to protect those connections. TLS will take care of symetric key agreement and encryption decryption to each client the right way, avoiding many many things you are not considering on the protection of the data on transit. But it will not be a shared key between all clients, but a key for each client, and also a key that changes on new sessions/connections. Basically it will do a DH style AES key agreement with each user (may choose other algorithms too), but will take care on avoiding many attacks that are possible in such schemes that you just wont even catch if you just use plain DH to agree on a symetric key, even if you run one DH agreement with each user.

If you also want to protect data at rest, that is, when stored, there is no gain on sharing a key. Each one should generate its own secret key.


Securing HSM-stored symmetric data encryption keys (AES) in memory on server My project requires me to encrypt sensitive user data using symmetric data encryption (AES). I will be storing the AES key (DEK) in a HSM-based key management service (ie. Azure Key Vault / AWS KMS) and will retrieve the key to encrypt/decrypt data on my Nodejs server.

I have scoured the internets for best practices, however, details and explanations only seem to go so far as to whether keys should be stored in the database,hard-coded or externally (ie. HSM, KMS, env var, etc ...).

I have not been able to find sufficient clarification on the following:

1) Should I create a different AES data encryption key for each user? If so, what is the reasoning behind this? Just another layer of complexity?

2) How best to secure the key against attacked like when the server is hacked and traced / monitored?

3) Is it better practice to retrieve the key at startup of the server, then store the key in memory on the server, OR retrieve the key each time the server needs to encrypt data for the user?

Thank you in advance.

You've asked several questions here, so I'm going to provide several answers, and a couple of clarifications.

  I will be storing the AES key (DEK) in a HSM-based key management service (ie. Azure Key Vault / AWS KMS) and will retrieve the key to encrypt/decrypt data on my Nodejs server.

This is not generally what you want to do.  If you're using an HSM, the goal is for the key to stay inside the HSM, and never leave.  One common way to accomplish this is to store a key-encryption-key (KEK) in the HSM, and encrypted data-encryption-key(s) (DEK) elsewhere.  In the case of Azure Key Vault, these could be retrievable secrets.  I'm sure Amazon has something similar.  Then, when you need to use a DEK, you pass it in to the HSM, where it is decrypted using the KEK, and then returned to you.

  1) Should I create a different AES data encryption key for each user? If so, what is the reasoning behind this? Just another layer of complexity?

Yes.  The reason is that if a key is compromised, all of the data is not, only the data encrypted with this key.  (The data for one customer, in other words.) In addition, it eliminates the ability of many application flaws (outside of flaws specifically related to key retrieval) to allow one customer to accidentally gain access to another customer's data.

  2) How best to secure the key against attacked like when the server is hacked and traced / monitored?

Secure your servers.  And follow the rest of the advice here, like only exposing keys when needed.

  3) Is it better practice to retrieve the key at startup of the server, then store the key in memory on the server, OR retrieve the key each time the server needs to encrypt data for the user?

It is best to expose the keys for the minimum amount of time required to perform the encryption or decryption operations they need to perform.  Retrieving them every time the server starts certainly sounds excessive.  Whether it makes the most sense for you to retrieve them say, when a user logs in, or wait until an actual crypto operation needs to be performed is up to your judgement.  Again, the smaller the window the better, within reason.


Should Each Web Request Be Logged I frequently see that logging the IP of the user is advised. I thought of attaching this information to the session record in the database but IP can change during the lifetime of a session. And if the user prefers to keep the session open, session may never be renewed.

So, is it best practice to log each and every web request coming from the client?

This is totaly application dependent. As @iain pointed out, your webserver almost certainly logs all requests. E.g. if you use apache, than you can find the logs in the /log/ folder in the apache directory.

application-dependent: if you have tons of requests, you may face problems keeping your logs for a extended amount of time. Check your webservers config for the logging-policy.

here is an example of how apache commonly logs requests:

64.242.88.10 - - [07/Mar/2004:16:05:49 -0800] "GET /twiki/bin/edit/Main/Double_bounce_sender?topicparent=Main.ConfigurationVariables HTTP/1.1" 401 12846
64.242.88.10 - - [07/Mar/2004:16:06:51 -0800] "GET /twiki/bin/rdiff/TWiki/NewUserTemplate?rev1=1.3&rev2=1.2 HTTP/1.1" 200 4523
64.242.88.10 - - [07/Mar/2004:16:10:02 -0800] "GET /mailman/listinfo/hsdivision HTTP/1.1" 200 6291
64.242.88.10 - - [07/Mar/2004:16:11:58 -0800] "GET /twiki/bin/view/TWiki/WikiSyntax HTTP/1.1" 200 7352

the lines are formated like this, though it varies depending on the logformat you configured:

IP -- [DATE] "REQUESTSTRING" HTTPRETURNCODE SIZEINBYTES

(check out this for more information on the format of the logs)

hope i have helped


How can I disable javascript alert and access the webpage? Few days ago I opened a webpage of my academics website, I wanted to download the webpage but it has a javascript alert box pop up so after that I wasn't able to access anything either on the browser or the webpage. Finally I had to close it, and after closing the alert box it also closes the webpage.

Is there any way I can download the webpage by disabling that alert box and accessing the webpage?

Sorry I cannot share much information and credentials so I am attaching the image below, I hope you got what I am asking.

Also can I remove the alert box by injecting some JavaScript in the url?

You can disable javascript in your browser, then download the page. For mozilla firefox go there :
mozilla docs.


Is there a way to see if an Nmap scan in the background is progressing? I have launched an Nmap scan from an Ubuntu machine with the following parameters:
nmap -Pn -T3 -sS -sV -iL /home/tsouser/Desktop/Scope.txt --reason --top-ports 100 --max_rtt_timeout 200ms --initial_rtt_timeout 150ms --max_retries 3 -n -oA /home/user/Desktop/Test_nMap . &

As you may see, I am running the process in the background, and I would like to see if the scan is progressing or not. Is there a way to find out, without restarting the scan?

First, get the process to the foreground:

$ fg

Then, you can use these keys:

v - Increase / decrease the verbosity level
d - Increase / decrease the debugging Level
p - Turn on / off packet tracing
? - Print a runtime interaction help screen
Anything else - Print out a status message like this:

Stats: 0:00:07 elapsed; 20 hosts completed (1 up), 1 undergoing Service Scan
Service scan Timing: About 33.33% done; ETC: 20:57 (0:00:12 remaining)

Edit: then to get the process in the background again:

hit Ctrl-Z to pause the process
enter bg to run the process in the background.

You can use jobs to view the currently running processes.


Is it possible to dump an exe from ram and create a distributable exe from it? Is it possible to dump the ram and get an exe and use that ram dump to distribute an app? If so, is this something that is a practical concern and if so how best should a developer protect against it?

I ask because I'm considering encyrypting my app by nesting keys within nested features/widgets. When a feature/widget is dormant (not used yet) it will be encrypted. When it is used it will be decrypted along with another key to a nested feature/widget inside it.  If it's more difficult to reverse engineer that than an exe not encrypted on the hard drive than I would buy some slow down time.

This is the context of why I'm asking if gettng the exe from ram and piecing it together as a distributable exe. I'm assuming if I encrypt in a nested fashion described above it may slow down a potential reverse engineer attempt. I wanted to be clear with my question so I didn't describe why I'm asking, but I hope this bring some clearity.

It's possible to design operating systems, or individual programs, so this is possible.  With debugger-level access to a running application, you could probably reconstruct a close approximation to the the exe which launched it.  However, that wouldn't necessarily put you in any better position to distribute the app than if you just copied the original bits.


WinZip encrypted file vs password protected file How are password protected files and WinZip encrypted files different ?

For example - if i have a excel file to be sent.
Option 1 - I can send it as a password protected file.
Option 2 - Encrypt it with password, say with WinZip

How does it help to send the winzip encrypted file? Ultimately, it is about the receiver entering the RIGHT password. Or is there any advantage to sending an encryoted file ?

Both are using encryption. They have a bit of a bad reputation, since Excel and WinZip used to use dreadful encryption methods in the past. However, the latest versions of both use AES-128, which the US Government considers strong enough to use for SECRET information. You don't tell us your threat model (what you are protecting and who from) so we can't make any guarantees, but you should be OK with whichever is the most convenient.

However, two important points to note:

I am talking here about Excel's "password to open" option where you can't open the worksheet at all. The "password to modify" option does not encrypt and is trivial to bypass.
Information Security is more than just picking a strong encryption method. You also need to use strong passwords, manage the password exchange process, secure the endpoints, guard against social engineering, etc. etc. etc.


Establishing safe connection in Java In my Java project I'm trying to create a 100% secure method of communication between the method and the client. I used to use this process:
Client: generates 4096-bit RSA keypair
Client: sends public to server
Client: generates 256-bit AES key
Client: encrypts AES key using RSA and send
Server: decrypts AES key from RSA
Server & Client now communicate using AES only

But I found out this isn't safe as it can easily be ruined by a man-in-the-middle attack. I began researching TLS and found out about security certificates. My question is this: if the client generates the RSA keypair, signs it using the certificate, and sends it to the server, what stops a MITM from doing the same thing (assuming the certificate is publicly available, which I assume it would be because the server and the client would both need it).
When I use OpenSSL to generate a certificate it always provides an RSA key alongside it. Isn't it safer to generate a new keypair for each connection, or do I actually use this particular key? What am I missing about the standard pattern for TLS?

If the client generates the RSA keypair, signs it using the certificate, and sends it to the server, what stops a MITM from doing the same thing?

That does not happen. If the server have a CA-issued certificate, the client will know for sure that the certificate belongs to the server. If an attacker creates a fake certificate, it won't be signed by a valid CA and will be invalid.
When the client receives the certificate, it checks the signatures on it, and who is the CA issuing it. If the CA is not trusted, the certificate is not trusted either (and the client issues the error sun.security.provider.certpath.SunCertPathBuilderException:  unable to find valid certification path to requested target or something similar).
The attacker could connect to the server, receive the certificate, and generate its own AES keys, but that would be useless in any MitM scenario, as his keys aren't the ones the client uses, so they cannot decrypt anything.

Isn't it safer to generate a new keypair for each connection, or do I actually use this particular key? What am I missing about the standard pattern for TLS?

You are missing quite a lot. The RSA key cannot change on every connection, unless you want to issue a new certificate, send it to the CA to sign it, install it, and repeat that for every single connection.
TLS have some complexity on it, but the over-simplified ELI5 version is:

client connects to the server and gets the certificate

client sends a random key (the client key), and all ciphers he supports

server responds with a random key (the server key) and the cipher he will use

at this point, the session is established and secure

There's more details on this, but is basically that. The server certificate have the server RSA key, the issuer (the CA), the subject (the servers it is valid for), the validity (expiration date), and the client uses that information to decide if it trusts the certificate or not.
So use TLS, don't bake your own crypto. TLS is around for a lot of time, is battle-tested, have extensive documentation, libraries, and examples available, and it's easy to any programmer to inherit the project later and keep going.


Is there a strong protection against CSRF executed from the sames server via stored XSS? If we have a domain with stored-XSS vulnerability. I know it's already critical!.. But, I'm talking about limiting the damage.

The hacker can't get the session cookie of the admin, because it's flagged httponly and the server doesn't allow TRACE method.

However the attacker can use CSRF to force the admin to create a user in the application.

Most of CSRF controls  will make it only difficult for the hacker but not impossible;

synchronizer token and viewstate could be easily stolen with ajax requests since they are sent from the same domain.
Referrer and Origin validation is also not applicable.
any other multi-step request could be simulated with ajax.
Double submits are also vulnerable, since the browser send the cookies by default.
CAPTCHAs are difficult, but theoretically they can be cracked using mechanical turks.

The only control that seems to work is asking the admin's credentials each time a sensitive request is made. But, does creating a user is a sensitive request? Or changing someones password? may be it's a daily task..

Any insights about this topic? can we prevent against CSRF via stored-XSS?

Due to the Same-Origin-Policy(SoP), CSRF and XSS have a kind of rock-paper-scissors relationship.  All CSRF prevention methods rely upon the SoP, and XSS in a fundamental bypass of the SoP.   In the case of reflected XSS, you need a "cross-site request" in order to deliver the JavaScript payload,  so in this cases a CSRF token can make reflective XSS unexploitable.

With XSS you can read any page with an XHR, which can be used to obtain CSRF synchronization tokens. Captchas are not safe either, because they can be solved remotely using XSS (a beef tunnel will do the trick).  With XSS you can also obtain passwords with phishing, or trick the user into authorizing actions on the attacker's behalf.

Let me be clear,  There is no method of CSRF prevention that can protect against an SoP bypass.  A persistent-XSS vulnerability is one of the best SoP bypasses available to the modern attacker.


How does DUO push button method and other methods actually work? Google authenticator uses  HOTP and TOTP algorithm for TFA.
What is the basic working principle of DUO push? What brings security to DUO push?

For push, Duo uses HOTP. It also supports TOTP when available.

  What brings security to DUO push?

Quoted from the Duo website:

  Duo Push, authentication requests approved in the Duo Mobile app, provides an extremely secure and user-friendly mobile authentication experience.

  Duo Push is an out-of-band authentication mechanism over a mutually-authenticated secure transport and is resilient against even the most sophisticated credential-stealing attacks. Duo Push authentication requests are signed with an asymmetric key pair to ensure end-to-end integrity. Transaction details are displayed to the user for verification, and any discrepancies or unexpected authentication requests can be flagged with the tap of a button.

  While operating over a TLS transport to protect confidentiality, the integrity of Duo Push transactions does not fully rely on TLS. Instead, an asymmetric signature scheme provides message-level authenticity and integrity on top of the transport channel. Therefore, even in the face of implementation-or-protocol-level attacks against TLS, Duo Push remains uncompromised and transaction approvals cannot be forged.

  During Duo Mobile account activation, an asymmetric key pair is generated, which acts as the primary identifying credential for the user when responding to Duo Push requests. The private key is stored securely on the mobile device while the public key is maintained in Duo’s cloud service.

Source: https://duo.com/product/trusted-users/two-factor-authentication/authentication-methods


Is there a way to securely store unsalted passwords? So, obviously I'm not talking about username/password pairs here, I plan to store passwords with two salts and three hashes, but what occurred to me is that if I had a table where I kept pairs: encrypted password, number of people that tried to set it.  And before I set a password I checked it against that database, and if more than .01% of users tried to use that password, then it gets rejected.

Would there be a way to securely store data like that that would prevent attacks via someone solving that table then brute forcing against the salted table?

The only thing I can think of is using the password as a one-time pad and XOR-ing it against the hash, but that doesn't prevent new rainbow tables, it just stops current ones from working.

I'm assuming here that your goal is (as @owen suggests) to stop the use of common passwords (e.g. password123) used by your userbase.  This is generally a "bad thing" for security as you'll be artifically constraining password choice in a way that is unpredictable to the user.

If you think about the end-user experience of this feature, would you give them a message "hey you chose a common password, pick another"? If so, I'd wager that most users will stick a 1 or ! on the end of the password and try again and/or get frustrated and leave (depending on the site), and as you're not going to disclose the list of commonly used passwords, there's no way for the user to know which ones are/are not allowed.

A better approach might be to check the passwords against a common list, which you can point them at and if they choose one of those passwords suggest that it's a bad idea but let them go ahead if they choose to do so.

That said, assuming that your goal here is as above, you wouldn't need to have the passwords associated with specific user accounts you would just need them in a list, so there's not too much wrong (in most cases) with just storing them with the same salt and hashed, then checking as you add new users.  If an attacker compromises that table, all he has (if he cracks the hashes) is a list of passwords used in the database with no direct way to associate them back to specific users.

One other risk to consider if you do take this approach is that if the system allows users to self-register, an attacker could just iterate over commonly used passwords to see which ones your users have used as the application will reject those...


How to "deliver" a clickjacking attack? How can a hacker deliver a clickjacking attack?

Does the hacker need to manipulate a "good.com" website and change its original code?
Does the hacker create an "evil.com" website and just put a transparent layer with malicious code over the "good.com" website?
Does the hacker changes the code at the client side?

Let's say an attacker wants to get a user to click something on victim.com.

For this, they need to place an iframe somewhere - anywhere - where the victim will see it. It doesn't really matter where it is placed, or how it was placed there.

This is not required, but ideally, the attacker can also run JavaScript here, as it increases the chance of successful exploitation, especially with multi-click attacks (it is possible to "follow" the mouse pointer and thus make sure that any click clicks on the desired position of the victim.com website).

These are the ways that I can think of that an attacker can deliver an iframe to a victim:

The attacker hijacks a website, good.com, they know their victim will visit. This may happen in different ways; the website may allow the creating of iframes, or the attacker may have compromised the server
The attacker creates their own website, evil.com, places their ClickJacking payload on it, and gets the victim to visit it by sending them a link.
Email: Some email clients may display (a subset of) HTML code (this is really only a subcategory of the first point though)
The attacker may be able to place an iframe on victim.com. If this is the case, the problem likely extends beyond ClickJacking (at least HTML injection, likely XSS).
The attacker may be able to change the delivered HTML in transfer (mitm) or on the client side and thus inject an iframe. But again, if this is possible, there are far greater consequences than ClickJacking.

Here is a very simple example of how a ClickJacking payload might look:

// placed anywhere, eg http://evil.com/clickjacking.html
<div style="position: absolute; left: 50px; top: 50px; pointer-events: none;">
    Click Me!
</div>
<iframe style="opacity: 0;" height="500" width="600" scrolling="no" src="http://victim.com/vulnerable.html>
</iframe>

So it is not necessary that an attacker changes the HTML of victim.com (not at the source, nor at the client side).


Encrypting salted password hash before storing in the database I have read here and here, that instead of using pepper, it is better to encrypt hashed/salted passwords before storing in the database. Especially with Java, as there's no library for salt/pepper, but just for salt hashing, and I'm not going to implement my own crypto in any way. Have questions about it:

Is it true? Will it add security, if db server is on another physical computer, and encryption keys are stored on the app server's fs?
If so, is it ok to use RSA for hash encryption?
To check password in this case, is it better to read encrypted password from the DB, decrypt it, and then compare it to the hashed/salted one entered by user, or encrypt entered hashed/salted password and then compare with the encrypted value in the database? In this case, will it be the same as using another hash, as encrypted hash is never decrypted?

A code sample that I use to get hash now:
KeySpec ks = new PBEKeySpec(password, salt, 10, 512);
SecretKeyFactory kf = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA512");
SecretKey sk = kf.generateSecret(ks);

byte[] hash = sk.getEncoded();

A code I am going to add:
Cipher cipher=Cipher.getInstance("RSA");
cipher.init(Cipher.ENCRYPT_MODE, privateKey);
byte [] encryptedHash=cipher.doFinal(hash);

Encrypting a hashed password is not better than adding pepper, despite what you read in your cited answer. It is functionally equivalent, but more computationally intensive (wasteful) and it increases the chances to introduce bugs.

You do not need a special library to add pepper. Since you have a library that handles salt, you just have to replace the code hashPassword(thePassword, theSalt) by hashPassword(thePassword, the128bitRandomPepper + theSalt). With + being the string concatenation operator in Java.

RSA is an asymmetric encryption algorithm. This is not at all suited in this context. Just do not encrypt. But if you really need to, use AES-GCM (for those wondering why GCM: it's mainly to force the OP to correctly handle the IV). Then post your full scheme here to have it reviewed, because you might still do mistakes.

Just do not encrypt, instead use your library as described in point 1.

To answer the claims made in the two links you cite:

From stackoverflow and from security.SE: One can rotate the encryption keys. However, once the database is breached, that is useless: either the encryption is good, and changing the passwords or rotating the key is useless; or the encryption is weak and the passwords need to be changed.
From stackoverflow: Encryption is more secure than hashing. That's wrong.
From stackoverflow "since he knows the salt and the output, he can brute force the pepper" The same applies with encryption. This is not an issue with a pepper handled as a key.