User-specific Subdomains : JavaScript security If I provide a public-facing website for users on my website at their own subdomain (e.g. bob.myapp.com) under their own control, can I allow them to execute arbitrary JavaScript without putting my main app server at risk (e.g. myapp.com)?  The users would be able to put their own *.js files in the public root of their subdomains.

I have an extremely limited understanding of the JS Same Origin Policy, but I believe that different subdomains count as different origins.  Therefore if my main app (myapp.com) is secured from XSS etc., is there anything specific I need to worry about from the users' subdomains that I wouldn't have to worry about for any other external source?

Thanks!

Yes, you do have to worry.  While the subdomains are mostly isolated from your main domain (thanks to the same-origin policy, there are some exceptions that could pose a risk.

One risk has to do with cookies.  Script on bob.myapp.com can set a cookie for myapp.com.  This cookie will be sent to myapp.com when the user visits myapp.com.  This can be used for session fixation attacks.

For instance, malicious user content can set a session cookie (sessionid=1234) with domain myapp.com.  Then when the user visits myapp.com, their browser will send the session cookie set by the attacker.  Since the attacker knows the session ID that the user will be using, the attacker can now hijack their session.

One mitigation is to host the user content on alice.myappusercontent.com, bob.myappusercontent.com, etc., while your app is on myapp.com.  That should stop these attacks.

The classic reference for information about the same-origin policy and isolation on the web is the Browser Security Handbook.  See especially the section on the same-origin policy and on life outside same-origin rules.


Why do KeePass dabases contain a hash of their master password? Background

In the article How to Hack KeePass, the author used keepass2john on a KeePass database to extract a hash of its master password.

For the database CrackThis.kdb the extracted hash was (line breaks added by me)

$keepass$*
1*
6000*
0*
dfb86938fedd22b8235c4de4b02e5bb3*
c292fa502cbb0e912f30c1e1b6829a2c04ebe30477cb269d462fbbbeeb9360a6*
b85fb0e07f3edbd4123db2c829b79355*
6d4857a728900d4da4fad66999233e5c647e5354330d31be3a47bbdd102a5ca7*
0*
CrackThis

Which Hash is Actually Stored?

To understand the risks of storing such a hash, we have to know more about the hash. How is it computed and what was the input? What are the different values separated by *?

From the KeePass website I learned that KeePass executes something like the following routine.

var password = readPasswordFromUser();
var hash1 = SHA256(password);

var salt = getSaltFromDatabase();
var iterations = getIterationsFromDatabase(); // default 6'000
var hash2 = AES_KDF(hash1, salt, iterations); // key derivation function

The database is then encrypted/decrypted using AES with the key hash2.

Back to our extracted hash from above. There are three possibilities.

The stored/extracted hash is hash2. Since hash2 is used as the decryption key, this would be a disaster. I think we can exclude this one.
The stored/extracted hash is hash1. Storing hash1 renders the key derivation function (KDF) useless. The KDF is there to slow down bruteforce attacks. With hash1 an attacker doesn't have to deal with the slow KDF, but only with SHA256.
I misunderstood something and the extracted hash is neither hash1 nor hash2.

Main Question

Why does the KeePass database contain an unencrypted hash of its master password at all? To decrypt the database we don't need a hash, we just decrypt using a given password. If the password was wrong then the encrypted data will be nonsense, no problem.

If the stored hash is only there to prevent dealing with nonsense data when the user entered a wrong password by accident, then I don't get why they didn't use a less risky way. For instance, wouldn't it be safer to compute a checksum (not necessarily cryptographic, for instance CRC) of the database and encrypt checksum+database. On decryption, the checksum can be verified against the database.

The answer is in the the source code of keepass2john.c that you linked, from lines 156 to 163. The only hash included is the hash of the plaintext of the database. I let you read what the other fields represent, the source code is rather self explanatory.

TL;DR Keepass databases do not include the hash of the master password.


Cryptanalysis of encrypted data at rest Imagine I have a file encrypted using AES CBC mode with a key and a random IV. The attacker access to the encrypted text and the IV used but not the key.

In this scenario there is no vulnerability since the IV is random.

Now lets assume the attacker gets information about the plaintext used. The plaintext is a survey form filled out by a user. So there is a fixed format for the data encrypted. In that case if we assume the attacker has access to the empty survey form (with the questions) does that change the presumed security of the encrypted data? The random IV does not matter any more. The situation lends itself to a chosen plaintext attack. Am I missing something here?

How do you protect the data in this case?

EDIT: The key is randomly generated and stored in a database completely separated from the encrypted data.

The whole point of symmetric encryption is that if an attacker doesn't have the key, they can't decrypt the data.  AES has no publicly-known computationally feasible attacks (significantly better than brute-forcing the entire 2128 key space) on it that are relevant to this scenario.

If the data is at rest, there's no chosen plaintext attack -- there's no system that accepts chosen plaintext and encrypts it.  You can only do the chosen plaintext attack if an attacker can submit arbitrary plaintexts to a system that will encrypt them and spit back the ciphertext.

Now if you expanded the attack surface to one where an attacker could request a plaintext be encrypted with an unknown key, then there is a potential chosen plaintext attack if the IV is reused or known to the attacker prior to submitting their plaintext.

With the expanded attack surface, then if (1) the IV was fixed or known to the attacker prior to submitting the plaintext,  and (2) an attacker could convince your system (that has the key) to encrypt arbitrary text submitted by them, and (3) the message space for each block is fairly small (only say a few thousand/million/billion possibilities which is significantly smaller than the full 2128 options allowed with 16 arbitrary bytes) for each 16-byte block of plaintext), then yes attacker efficiently could submit arbitrary plaintext with the same fixed IV (or account for the changing IV when making their plaintext guess) until they found a match to each block of the ciphertext they wish to decrypt.  They could do this block by block (an AES block is 128-bits = 16 bytes) to sequentially guess the original plaintext by brute-force (of the small message space).

However with a random 128-bit IV not known ahead of time, this attack would not work.  Why?  Because in CBC mode c[0] = E(k, p[0] XOR IV), c[i] = E(k, p[i] XOR c[i-1]) for i > 0 and the IV changes every time (and is unknown when you submit the plaintext, so you can't account for the change in IV and your change in your guess of p[0]).

  How do you protect the data in this case?

The data is already protected.


Does it make sense to encrypt database to comply with GDPR? I had a hard time phrasing the question. I'd rather ask, "How do I comply with GDPR?" But that would probably be too broad of a question. Database encryption concerns me the most, since that's what the client wants.

Let's consider some typical site: front end (Javascript), back end (Ruby, Python, PHP, you name it), and database (for example, PostgreSQL). It may be a single-page app, or the traditional approach (MPA). Most likely database and back end is on the same server.

To me it sounds like it's not worth the effort. Generally, the secret can only be kept on the server. If someone gains access to the database, he will most likely be able to find the secret. Unless probably access is gained via SQL vulnerability, which are mostly gone with today's frameworks. Or so I believe.

So, does it make sense to encrypt the database to comply with GDPR? Where to keep the secret? What are disadvantages of encrypting the database? What information to encrypt? Are there any better approaches?

On Compliance

I'm only loosely familiar with the specifics of the legislation, but as I understand it, there's nothing to indicate that database encryption is required to hold personal information and be in compliance with the General Data Protection Regulation (GDPR).

On the other hand, using appropriate encryption measures will somewhat lessen the privacy impact and notification requirements should there be a breach.

  (3) The communication to the data subject referred to in paragraph 1 shall not be required if any of the following conditions are met:

  a) the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption;

  Excerpt from: https://gdpr-info.eu/art-34-gdpr/

On The Benefits of Encryption for Database Security

Encryption can significantly reduce the impact of a data breach. For example, in 2015 Patreon was breached, losing control of 15GB of data. To their credit, Patreon used strong bcrypt hashes to protect passwords, and had used secondary encryption measures to protect sensitive information like Social Security Numbers and tax information.

Had they not encrypted the information, the impact of the breach - both for Patreon and their users - would have been considerably worse.

On Key Management

If your concern is that an attacker would be able to access the key anyway, there are some steps you can take to mitigate that risk.

Ultimately, unless you use a Hardware Security Module (HSM), protecting keys is basically like playing a shell game with the attacker. One reasonably effective way to keep keys protected is not to store them on the server at all. One of my favourite solutions for this is the Azure KeyVault service.

By keeping the keys out of permanent storage on the server and retrieving them only for use from memory, it makes it considerably harder for an attacker to retrieve the key. You'll still need to store keys to access the keys... but adding that extra layer of indirection will make it harder for your attacker.


Does encrypting HTTP header value provide additional security? Payload before encryption :

HTTP/1.1 200 OK
Authorization: password
Content-Encoding: UTF-8
Content-Length: 138

{ "command" : "delete all records" }

Payload after encrypting Authorization header :

HTTP/1.1 200 OK
Authorization: spxnxkoJX+O1iatF6gco9Q==
Content-Encoding: UTF-8
Content-Length: 138

{ "command" : "delete all records" }

Protocol is NOT over SSL.

EDIT

In our project, my senior added this extra layer of security(as per his opinion), with which I am not agree. As per my opinion, this will add an extra cost of encryption and decryption of header value and without any security benefit.

I want to ensure, if he is really right?

Does encrypting HTTP header value provide additional security?

There is no general response for this but it depends on what exactly you are doing and what kind of "additional security" you aim for.

In your case it looks that you just replaced a plain text password with an encrypted password. Unless you have some replay protection baked into your unknown encryption algorithm the attacker could just sniff  your encrypted password and replay it later. Which means it does not really provide additional security if your goal is to make authentication more secure. If your goal is instead to only hide the plain text password to make password reuse attacks harder then encryption might help.


the state of ASLR, PIE, SSP on Debian in 2018? As far as I remember,
most Debian Wheezy packages were not compiled with those useful security flags (ASLR, PIE, SSP, and more).

Did the situation improve with Debian Squeeze or the upcoming Debian Buster ?

By comparison, Ubuntu and Fedora have a nice security features matrix, but I couldnt find a clear answer for Debian.

Ubuntu: https://wiki.ubuntu.com/Security/Features
Fedora: https://fedoraproject.org/wiki/Security_Features_Matrix

you can check if a binary is compiled with

PIE
stack protection
fortify source
RO relocations
Immediate binding

by using hardening-check. E.g. hardening-check $(which sshd)
Package devscripts contains the hardening-check

On Debian testing i get the following output:

root@root:~# hardening-check $(which sshd)
/usr/sbin/sshd
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: yes (some protected funcions found)
Read-only relocations: yes
Immediate binding: yes

See the following answer on stackexchange


CVSS Score for self-XSS (stored XSS) I have a web application which is vulnerable to stored, self-XSS attack. Proper encoding is not done In the place where the data from a database (set by the same user) is added to response.

However, this XSS can be considered as not self-XSS (stored XSS) in following conditions:

Admin user adds malicious content into the user’s profile.
If someone can do a change in the database in another way.
Also if someone can steal the cookies of a user (session hijacking).

When calculating the CVSS score we have the following concerns:

Do we need to assume that the malicious data is already stored in the database, or not?
If we assume so, the CVSS score will increase, since the complexity of getting the XSS payload into the database is not considered.
If not, due to the complexity as well as high-privileges required in performing a stored XSS attack (without just being a self-XSS), the CVSS score will decrease.

What is the common practice for this kind of scenario when calculating the CVSS score?

In these two scenarios:

If someone can do a change in the database in another way.
Also if someone can steal the cookies of a user (session hijacking).

An attacker would already have access the user's session. They would need to exploit a vulnerability to get to that point, but at this point the session is already compromised, so the additional impact is none.

This scenario:

Admin user adds malicious content into the user’s profile.

Depends a bit on the system design, but most systems allow admins to have access to users profiles, for example by doing a password reset. So in most systems, the additional impact here is none.

If you use a CVSS v3 calculator, and set the CIA impacts all to none, it doesn't matter how you set the other values, the output is 0.0. This is why self-XSS is usually regarded as matter of best practice only and not a vulnerability.

One thing to be aware of is CSRF. If the self-XSS injection point is vulnerable to CSRF then this is a vulnerability.


Can the username be used in HMAC during client-side hashing? I am very new to authentication and cybersecurity in general, so I apologize if I have anything completely wrong.

My goal is to have the client side hash passwords before sending them to server side in order to protect users using the same password on multiple sites. For the sake of this question, assume server-side is secure (in my case, the hashed passwords from client-side are hashed again with Argon2 and then stored in the database). I understand that this provides no security benefit for users on my app and that other things such as SSL are much more important for keeping passwords secure in transit, but I'd still like to do this just in case.

I was planning on using SHA256 but heard that rainbow tables are a major security threat. Would using the username as the key in an HMAC hash mitigate that? Moreover, are there any better ways of protecting users who reuse passwords on multiple sites? Keep in mind that I can't use a salt because the resulting hash has to be consistent between logins when given the same username/password combo, and I can't use a secret key because it's client-side.

Hmm.

Your stated requirement is almost, but not quite, the same as the usual requirement of "If a hacker gets the db of users' password hashes, they should not be able to easily tell which users have the same password. This is usually solved by server-side salts.

You say:

  Keep in mind that I can't use a salt because the resulting hash has to be consistent between logins when given the same username/password combo

I'll push back on whether that's actually true; salts are per-user, not per-login, so why not have the server look up the salt in the db and send it down to the client?

Ultimately, I'm not sure you're going to be able to solve this problem.

Let's say I (the hacker) find out that some user's password on memegenerator.com is letmein1234. Then I go to the the login page of your site and enter that password for them. As far as the server is concerned, that's literally identical to the real user trying to log in.

Remember also that the attacker gets to see the source code of the javascript, so any obfuscation that you do to the password client-side counts for zero security because it's completely known to the attacker.

If the user decides to reuse passwords across sites, I'm not sure there's anything you can do about it, unless you're willing to go all the way to implementing 2FA with Google Authenticator, SMS OTP codes, FIDO2 USB keys, etc.


differences between meraki and pwn pulse I am working on the beginning of a writing assignment where I will document an emerging technology in information security. I have found this to be difficult because as the new technology emerged with regards to new attack vectors - they are soon patched, replaced, etc.

Anyways - I am considering writing about products such as pwn pulse. My question is, is there any immediate difference between the pwn pulse product and a product such as Cisco's Meraki?

Secondly, they seem to refer to these solutions simply as 'BYOD' solutions. Is this the accurate and appropriate terminology for these types of products? I ask because I will be forced to search through peer journals (and online databases) to research and document anything I can find that I can relate to such a paper and I don't anticipate finding much on 'BYOD'.

https://www.meraki.com/solutions/byod

https://www.pwnieexpress.com/productsoverview/pwnpulse/

Regarding your specific question, the two capabilities share some overlap when it comes to BYOD, but there are some key differences:
- Meraki "provides device based security policies, built-in NAC, and built-in mobile device management."
- Pwn Pulse "detects, fingerprints, and analyzes rogue, misconfigured, and unauthorized wireless and wired devices including BYOx/mobile, Wireless, Bluetooth, wired and other network-enabled devices."

In short, the two systems are apples and oranges compared to each other--one (Meraki) is a cloud-enabled Wi-Fi access solution with Mobile Device Management capabilities, kind of like Microsoft Intune. The other (Pwn Pulse) is a cloud-enabled device visibility + threat detection solution. As you've already alluded, BYOD is a bit of a vague term as it can mean different things depending upon where you're coming from. I would argue that both of these offer BYOD solutions in that they both resolve one aspect of understanding what devices are in/around airspace demanding network resources, but this is but one aspect of the larger product offering.


What is the difference between capture traffic from inside and outside of my network? I'm thinking to use Wireshark tool to packet capture in my Wireless network.

I read something that tells I can capture from inside or outside of my network, just making my wifi board working in "promiscuous mode". That is right? What is the difference, assuming the wifi is configured with WPA2 protocol? All of my traffic is encrypted and in the outside attemps I will have to decrypt?

Promiscuous mode just means your (Wireless) Network Interface Card (NIC) looks at all packets it hears, not just ones addressed to it (with its own MAC address).

With no encryption, promiscuous mode on wifi will only capture packets on the SSID that you have joined (and ignore packets on other wifi SSIDs).

With encryption (WPA2), in promiscuous mode your card will not be able to decrypt packets sent to other MAC addresses due to the encryption.  Hence, promiscuous mode isn't giving you more access in this case.

There is additional RF monitor mode, which is supported by some cards that will capture all packets your wifi radio can pick up, including those your wifi card cannot decrypt.  Granted if you eavesdropped on the WPA2 handshake process and know the shared secret key of the network you will be able to decrypt the traffic.  (Assuming it's not additionally encrypted; e.g., a user visited an HTTPS website over WPA2-Wifi).

Hence, if you want to capture packets on other networks you need to use monitor mode.  See: https://wiki.wireshark.org/CaptureSetup/WLAN#Monitor_mode


What's the security risk in password recovery attempts I'm the administrator of a Wordpress site, with just two users: me and one other user. Last days I've received multiple password recovery attempts for that other user (as an administrator I get a mail from the Wordfence security plugin). The other user gets the reset mail in his mailbox. The user didn't initiate these attempts.
I'm blocking the IP's on the server, but I don't see what the goal of the attacker is. I checked the mails the user receives, and they contain a valid password reset link (so no phishing attempt).
So I don't really understand what the attacker is trying to achieve with these password recovery requests. Or are they just checking for vulnerabilities on that page?

Hacker's often test password recovery systems for possible account enumeration weaknesses. Though a bad design decision or misconfiguration, a password recovery can reveal the existance of a user account. Then a list of valid user accounts can be used later in a brute force attack.
An attacker may test if there are different responses for valid and invalid usernames. They may record the time it took for the application to respond, to identify valid and invalid accounts.
Besides account enumeration, an attacker may test a password recovery for SQL Injection vulnerabilities. Can they insert malicious code server-side by crafting a SQL query in the password recovery username/e-mail field for example.


Implicit Service for Firebase I'm starting android bug hunting and I've seen a service with implicit intent,
and I saw in Android documentation that :

  Using an implicit intent to start a service is a security hazard because you cannot be certain of the service that responds to the intent

The service is derivated from FirebaseMessagingService.
I would like to know if this is a security issue and If it is what would be the impact ?

Thanks

The extension of FirebaseMessagingService is usually used to process the notification messages when the application is in foreground. The processing is automatically done by the system when the application is in background. Based on my research and understanding, this service is started by the system and once the notification message is received the onMessageReceived() is invoked. In this case, I don't see usage of implicit intent for invoking a service as a security issue. Also, as per the official documentation, to use this functionality the service is to be declared in the manifest in the predefined way which seems to be a functional requirement.

Recommended Read: https://medium.com/@MiBLT/mastering-firebase-notifications-36a3ffe57c41

PS: While answering the question, I'm assuming that you are performing bug hunting on the Android application using Firebase component and not the component itself.


Why must a ret2libc attack follow the order "system(),exit(),command? In a ret2libc attack, I understand that the return address can be overwritten with the address of the system command, which takes a command string as an argument. In this case, shouldn't the address of the command string come directly after the address of system()? However,most tutorials I have seen follow the format :  address of system().address of exit().address of command string.

Why is it mandatory to include the address of exit()? Will the attack still work if exit() is excluded?

The ret2libc (and return oriented programming (ROP)) technique relies on overwriting the stack to create a new stack frame that calls the system function. This wikipedia article explains stack frames in great detail: https://en.wikipedia.org/wiki/Call_stack#Stack_and_frame_pointers

The stack frame dictates the order the function call and parameters are written:

function address
return address
parameters

So in your example you want to call system() with cmdstring and return to the exit() function when the system() call returns. So you write the following stack frame:

system_addr
exit_addr
cmdstring_addr

If you remove the exit address you change the stack frame to the following:

system_addr
cmdstring_addr
existingdataonstack_aka_junk

So now you're calling system() with a junk address argument and trying to return into your command string once the function completes. Which is why it fails. You can replace the exit() address with other data such as  0x41414141 which will cause a segfault once the system() call completes. Or you could replace it with the address of a pop pop ret location and then write more stack frames underneath. This is now a ROP payload. Here is a basic example of how that would look on the stack:

system_addr
poppopret_addr
cmdstring_addr
printf_addr
exit_addr
addr_of_string_to_printf

This would allow you to print something like You got hacked before exiting.


Secure architecture for isolated printer network I am very new to "networking" and security, but I realize that it would be more secure to have printers on their own "isolated network".

How do I secure my networked printers?
What kind of printers do the most secure companies use?

I am unsure what the correct or what a good structure is for creating an "isolated network". Wondering if it means essentially this (for a home-based system):

Create a second account with some ISP, or perhaps just ask for some separate thingy on the existing account.
Buy a second router.
Disable internet access for this router, so it only functions as a local wifi system. Or maybe the printers don't need wifi and can use ethernet instead.
Connect a laptop to the network somehow, so it can send its print jobs to the printer.

I can see a few holes in that so far, and it seems incomplete. I'm wondering what the typical system is for making a secure isolated network such as for these printers, which you can still send commands to only from specific places (like from a laptop or phone).

Ideally, printers are to be seperated from their clients (and the internet) as much as possible.

There seems to be some kind of confusion on your side between categories of network devices. I'm assuming you're coming from a COTS standpoint which usually means that a device called "Router" does carry the jobs of "Router", "Firewall", "Switch", "WiFi Access Point", "Gateway" and "NAT", which might lead to the confusion.

A network architecture that can provide this might in it's simplest possible layout (which can easily be more complicated when deploying microsegmentation between clients and/or printers for example) look like this:

[Clients -> (Firewall] -> {Print Server) -> Printers}

where

[] = the network connection between the clients and your Firewall,
() = the network connection between the print server and your Firewall,
{} = the (network?) connection between the Print Server and your Printer(s)

Now, the connection between the print server and the Printer(s) doesn't need to be networked. The printers could just be locally connected to the print server, for example by USB or LPT.

Also worth noting is that this setup is minimal for this case; usually, there are different subnets of clients that need different printer access which leads to vastly more complicated setups that do seperate networks even further, using more Firewalls, Gateways and Print Servers.

Please also note that none of this includes internet access thus far. In this setup, internet might be provided through the Firewall (over a seperate network connection) and access rules on the firewall would prohibit internet access for the print server.

Additionally, COTS "Router" devices usually do not provide all features of actual Firewalls, making this setup hard to achieve with it - and you usually do not. One notable exception are COTS Routers that offer a USB Port to connect a printer to in which case the device itself functions as the print server.

Lastly, please note that the threat model for private households and companies vastly differ and this setup might not be suitable for home deployment.


NMAP DNS Service Detection I was looking out how NMAP identifies DNS services. After determining that port 53 is open it issues a standard query TXT version.bind to find out if BIND is running on the domain port. Then, I saw that after NMAP received the response:

    9.3.6-P1-RedHat-9.3.6-16.P1.el5_7.1

it issued a "Server Status Request" and received a "Server Status Request Response, Not implemented" and displayed port 53 as open but did not specify a version. What is a "Server Status Request" and why did NMAP not lable the port as running BIND considering that it received the version?

Is the DNS service you are probing over TCP or UDP? There is a match line that looks appropriate (line 8836 in the latest SVN version), but it is only matched for TCP ports. Also, the fingerprint was added on February 4, 2012, so if you are using a version earlier than 5.61TEST5, you will not detect this service properly.

Nmap's service detection database is built from user submissions. If you have a service that is not being detected correctly, make sure your Nmap is up-to-date and  re-run the version scan with these arguments:

nmap -v -sV --version-all -p 53 example.com

and follow the instructions for submitting the fingerprint.


Examples for (Web-)Security-Architectures I just started to work on my thesis to finish my studies. However the field in which I write my thesis is pretty much new to me. I have the task to build a "Remote-Access Strategy/Architecture" to create a secure end-to-end connection.

One endpoint of the connection is BI ( meaning: numbers, web-, databaseservers, LDAP ).

The other end is supposed to be a smartphone ( iOS or Android ).

I started my research with a lot of reading regarding security standards like ISO27k, BSI Grundschutz and so on. I can't lose the feeling that those securitystandards are a bit to broad for the start of my research.

Those standards provide a great start into commercial security, but they also cover security in the form of natural disasters.

I'm searching for some security papers which show the security architecture of websites or webservices, show which technologies are in use ( SSL, DMZ, Firewalls, SSL-Termination).

My plan is to analyze those architectures and to learn from them.

Do you know any good books, studies or other security material which could give me a good start into this topic?

P.s. I know that web/webserice security doesn't cover the loss of the device ( which would probably be a big risk in a mobile environment)

It is a mistake to try to focus on one architecture that will work for everything.  That just doesn't exist.  The solution has to match the problem and the requirements of a particular application.  So, my advice is: don't waste your time looking for a one-size-fits-all "architecture"; instead, look at some specific application's needs and seek a solution that will work well for that application.

If you want an end-to-end secure communication channel, use TLS.  No fancy security architecture is needed.  If that is not what you are looking for, you will probably need to edit your question to identify your requirements more clearly.

If your goal is to better understand some ways to secure web applications, then what you want is not "an architecture", but just a survey of work in this area.  In that case, you should also spend some time reading OWASP's materials.  You should also check out the resources linked to in Beginners materials for web security.  Another tip: use the "search" bar in the upper-right of this site, and you can find a lot more information about web security.

I would not start by reading standards documents.  They're probably not the best resource to start learning about this area.

P.S. I might be overly sensitive, but I have to admit I get skeptical if people get too focused on "architecture" rather than focusing on solving the problem.  So, just a small suggestion: you might want to start by identifying what is the problem you want to solve.  That will help you make sure you are focusing on a real problem.  Then, you can ask yourself questions like: what are the security requirements?  what are the resources that must be protected?  what's the threat model?  what are some available controls or mitigations that help address those threats?


Expecting: TRUSTED CERTIFICATE while converting pem to crt I am trying to generate a private-public key pair and convert the public key into a certificate which can be added into my truststore.

To generate private & public key: openssl rsa -in private.pem -outform PEM -pubout -out public_key.pem

Now I am trying to convert this to a certificate:

openssl x509 -outform der -in  public_key.pem -out  public.cer

But I get an error:

7962:error:0906D06C:PEM routines:PEM_read_bio:no start line:/BuildRoot/Library/Caches/com.apple.xbs/Sources/OpenSSL098/OpenSSL098-64.30.2/src/crypto/pem/pem_lib.c:648:Expecting: TRUSTED CERTIFICATE

All tutorials show that I have to convert pem to crt before adding to a truststore.

You cannot "convert" a public key to a certificate. A certificate includes the public key but it includes also more information like the subject, the issuer, when the certificate is valid etc. And a certificate is signed by the issuer.
Thus what you would need instead is to create a certificate signing request (CSR) which includes the public key but also includes all the additional information. This CSR then needs to be signed by a certificate authority (CA) which then results in the certificate.

For creating a simple self-signed certificate which is not trusted by any browser see How to create a self-signed certificate with openssl?.


Privacy policy about links to other sites In many of the privacy policies, I noticed there is one section as a disclaimer mainly talking about "our websites contain links to other websites, and it is your own risk/responsibility to familiar yourself with the privacy policies about those sites".

E.g. quoted one paragraph of this kind:

  We are affiliated with other online companies, some of which feature our branding; in addition there are numerous links to third parties contained on our site.  Our Privacy Policy does not apply to those companies' web sites, so you should refer to each of those sites to obtain information on their privacy policies.  If you cannot find the privacy policy on any of these sites once you have arrived at their site via a link from our site, you should contact that site directly for more information.

Because a quite high percentage of privacy policies contain such a paragraph, it seems to be a common practice and seems to be caused by legal reasons.

I am totally unfamiliar with legal aspects of privacy, could anyone provide some insights on the reason why it is a common practice? Maybe point out which regulation/law requires such a disclaimer? Thanks!

You might be interested in these:

Internet user arrested for linking to other websites (Free Software Foundation ask to take action)
Facebook to check outbound links for viruses, malware (yahoo news), Twitter also has a similar service
I think that links to other "dangerous" sites might impact google's SafeBrowsing result, but I'm not sure about it


Is there a cryptosystem that allows a set of auditors to confirm that they have valid Shamir or Group signatures? Suppose I have a client that generates and sends a Shamir key (or group signature) to a set of Auditors.

This key is essentially an unverified set of bytes.  Each auditor wants to somehow verify that the keys are valid, and can be combined.

What technique can be used to ensure that valid (and not garbage) key material was sent to each Auditor?

For Shamir's secret sharing, the only possible method for validating a share is rebuilding the shared secret with enough shares, and see if the result makes sense. There cannot be any other method that does not involve sufficiently many shares to reach the threshold, because that would contradict information theoretic security of the scheme (basically, if you have a way to validate a share, then you can do an exhaustive search on possible shares).

For other algorithms, this is a possible feature that any given algorithm may or may not provide. There is no generic method. One can surmise that non-interactive zero-knowledge proofs will probably be involved at some point, so the details will not only be specific to the scheme, but also substantially hairy.


SSL Certificate MITM Attack for Expired Domains Let's say I have a domain name, like mysupercoolproduct.com. I buy a 2 year SSL certificate for it, and then I am negligent and the domain gets snatched up by someone else. I still have a valid SSL Certificate for the domain, but I don't own the domain any more. (This could also occur if I sold the domain to someone)

What mechanisms are in place to invalidate a valid signed but illegitimately possessed SSL certificate? Since my pretend SSL cert was signed by a legitimate CA, browsers don't have a reason not to trust it. This would allow me to pull off the MITM attack of the century until it expires.

Are there any ways to globally invalidate all SSL certificates for a domain, if the domain expires or is sold to another company?

PKI Infrastructure provides the means to do this via revocation lists.  If you purchase a domain from someone else, or snatch one up that has lapsed, part of that responsibility lies with the purchasing party.  They should do their due diligence and contact the CA issuing authority to invalidate any other certificates that are out there.  I'm sure there is some sort of proof required by the CA before they just randomly invalidate a Domain's certificate, but I've never done it before.  Between OCSP and standard revocation lists, this shouldn't be a hard problem to overcome if your web/sys admins are doing their jobs right.


Chrome SSL Warning: "You cannot proceed because the website operator has requested heightened security for this domain. " I'm trying to go to the URL below, and Chrome warns me that the wildcard certificate is not valid for this domain.

https://chart.apis.google.com/chart?cht=qr&chs=100x100&chl=otpauth%3A%2F%2Ftotp%2FTest123%204%3Fsecret%3DTKQWCOOJ7KJ4ZIR

At first I thought it was a quirk on how chrome handles URLs with many dots in a wildcard cert, however I see this text in the warning, and am also unable to click through

  You cannot proceed because the website operator has requested heightened security for this domain.

Question

Is this a problem with Chrome's wild card certs and sub domains that are more than 2 layers deep?
Does the error mean that the website owner has "done something" to make wildcard certificates not work for subdomains?

Please try this Chrome hack: when browser shows the page with the invalid certificate message, type in your keyboard the word "proceed" and then hit Enter.

You should be able to proceed to the requested page.

On newer versions of Chrome, you may have to type "danger" and hit Enter instead.


Vulnerability management solution evaluation criteria We are planning for a vulnerability management solution, so I am looking out for evaluation criteria between the well known solutions like Nessus, Qualys and Nexpose.
If anyone could share such evaluation points it would be really helpful.

Bandwidth requirements
System requirements
Training offerings
Reporting
Accuracy (number of false positives)
Time to scan
Extra offerings

Example: Nessus has web app tool; Nexpose doesn't

Vulnerabilities detected (make a vulnerable device have all three scan it)


How web application firewalls protect application from DDoS attacks? How to protect a web application from DDoS by the implementation of Web Application firewalls?

How effective is this method?

You might want to clarify if you're looking for DoS or DDoS protection. See this answer for more details.

In a typical web-application architecture, the WAF stands in front of your web-application, either in your network zone (e.g. DMZ) or within an external service provider network that filters the traffic for you. In case of a DDoS attack, the WAF will be hit by the traffic load before your web-application, and it can even become a point of failure in the network flow. Keep in mind that the objective of a DDoS attack is to  flood your bandwidth or resources. Configuring your WAF to reject or block incoming traffic based on rules/patterns/signature (e.g. source IP addresses, protocol etc.) might help, but it might not be able to handle the huge volume of incoming requests or connections.

In short, WAF is usually not enough to mitigate DDoS attacks. For details regarding further DDoS protection, you might want to look at this question, or this one.


How to sniff a data from an upstream router? I am connected to my router and I want to know if it is a possibility to sniff a data from a router that is over my router?

You cannot passively sniff packets that aren't passing through the part of the network you control, no.

However, attackers sometimes use a related kind of attack, where they compromise either the router or the hosts in the target network to make them send packets where they shouldn't. Then they can be passively sniffed.


Does site need SSL to resend info to a site that does use SSL? Let's say I have a website isellchicken.com, this site needs to be able to collect sensitive user information like credit card details. This site will not process the information, but will send it to another site, processpayment.com which uses SSL. Does isellchicken.com need to run SSL as well? Or is the connection encrypted just because I am posting to a site that runs SSL?

In case you are wondering, the form tag would look like this:

<form action="https://processpayment.com" method="post">

Yes, the page that renders the form needs to use SSL as well as the target. If the form page does not use SSL, an attacker will be able to manipulate it during transmission.

He can change the target.
Or more stealthy: He can add some JavaScript somewhere in that page to send a copy of the data to his server

You should not teach people to enter sensitive information on non SSL pages


Is it possible to crack ransomware encryption if I have the original file? Is it possible to crack ransomware encryption if I have 2 versions of a file: before and after the encryption? Are there any tools for such a thing?

I'm sure there are tools out there to assist in the process, but I can't think of any off of the top of my head.

The "attack" you would use to break the encryption would be a known plain text attack since you have an unencrypted (plaintext) and an encrypted (ciphertext) version of the same file. If you could change the plaintext and reencrypt it you could turn the process into a chosen plaintext attack, which is slightly easier to break. Depending on the ransomware though it might not use the same encryption technique every time.

Knowing the steps taken to get from one state to the other would require figuring out or breaking the encryption used and as schroeder said this is a very difficult thing to do. It would likely require millions of processing core hours to do.


How should I store SSL keys on the server? I have a Node.JS HTTPS webserver instantiated as follows:

var privateKey = fs.readFileSync('./../ssl/localhost.key').toString();
var certificate = fs.readFileSync('./../ssl/localhost.crt').toString();

https.createServer({
    key: privateKey,
    cert: certificate
}, server).listen(80, 'localhost');

My private key is on my server which Node.JS reads to create the HTTPS webserver. If a hacker has read access to server files he can access the private key and impersonate the webserver.

Should the private key be stored on the server? Should it be destroyed once the HTTPS server has been instantiated?

You do not want to destroy your private key: you will need it again if you server restarts. Reboots happen sometimes...

That's a generic observation: you want your server to be able to restart in an unattended fashion. Therefore it must contain the private key, and that private key must be available to the server software.

If an attacker hijacks your complete machine, then he gets a copy of your key. That's a fact of life. Live with it. There are mitigations, though:

You can use the "DHE" cipher suites for SSL. With these cipher suites, the server key is used for signatures, not for encryption. This means that the attacker who steals your key can thereafter impersonate your server (i.e. run a fake server) but not decrypt SSL sessions which he previously recorded. This is a good property known as Perfect Forward Secrecy.
If you store the key in a Hardware Security Module then the key will not be stolen. The attacker may play with the key as long as he has effective control of the server, but not extract it. This decreases his power of nuisance (but HSM are expensive).

In practice, you will just make sure that the file containing the private key is readable only to the system account which runs the server (chown and chmod on Unix-like systems, NTFS access rights on Windows).


Monitoring user use VPN If there is an employee uses the internet through an internal proxy in his company, and he use a paid VPN service to browse safely, can IT side be able to monitor his behavior?

If he connects from his computer to the VPN, the company can't see what is happening within the VPN connection unless they have monitoring software on his computer (which for some types of VPN clients, may include simply having their own trusted certificate to allow MITM attacks).  Only his computer has access to the details of the encryption for the VPN tunnel.  The company would possibly be able to tell that an encrypted connection was being used though.


sslstrip not working in LAN I have a LAN with 3 machines connected to a switch. Two machines run Ubuntu 15.04, one with Apache SSL installed which works as the webserver. Another machine also running Ubuntu serves as the client. The attacker machine runs Kali 2.0.

All machines have manual assigned IP addresses:

 Client: 192.168.1.1 HW: 08:00:27:2a:ec:cc
 Server: 192.168.1.2 HW: 00:11:22:33:44:55
 Kali:   192.168.1.3 HW: 08:00:27:fa:25:8e

I executed the following commands on Kali:

 echo 1 > /proc/sys/net/ipv4/ip_forward
 iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 8080

And then I run sslstrip -k -l 8080.

Now I start the arpspoof:

 arpspoof -i eth0 -t 192.168.1.1 192.168.1.2
 arpspoof -i eth0 -t 192.168.1.2 192.168.1.1

The arp tables on the Client and Server have both been spoofed and contain the HW of the Kali machine.

I also have wireshark Kali running.
When now accessing the website from the Server with the Client with https://192.168.1.2/test.html the website is displayed.
I can see all the packets for the SSL/TLS handshake on wireshark as well.
But sslstrip does not display anything!?

This attack is still working for outdated web browser! But the reality is that most of the servers now a day have HSTS (HTTP Strict Transport Security) enabled.

So how to sslstrip even if HSTS it dose his job?

If you use a virtual machine use your internet adapter on bridge mode.
Use sslstrip2 or go for a MITM framework like MANA or MITMF they tend to be more stable.
Be sure that if the target wants to reach as an example facebook.com to redirect the target to social.facebook.com (were HSTS security policy dosen't remember any certificate) and then you could perform an MITM SSLStrip.
Be sure to use a proper Wifi adapter that also support packet injection.


Regarding SQL Injection at Back End? I have logged into SQL Server 2008 Database and executed following query:

select * from USER_Main_INFO_Name where userid ='' or 'x'='x'

After executing the query Database has given total user list.

Using Burp Tool I have done SQL Injection at front end my application has given proper error result.

Is my application strong? How to avoid SQL Injecting at Backend?

This implies that at some point you are constructing SQL statements by string concatenation involving untrusted strings.  Don't do that!  Use prepared statements instead (or some other form of query parameterization), as they are pretty much intrinsically immune to SQLi.

I'm assuming you mean your frontend successfully blocks all the SQLi you tried.  This doesn't mean it will block all SQLi, of course; that depends on how thorough your testing is.

However, once the query reaches your backend (assuming that's your DBMS), there really isn't any way to tell what SQL comes from SQLi and what SQL is legitimate.  You really have to trust that what's coming in on the database connection is trustworthy.

Of course, it is wise to limit the impact of such attacks as much as possible.  Most simply, and commonly, you can limit the permissions of the application's service account on the database to only those actions it actually performs.  This doesn't prevent SQLi per se, but it will lessen the impact if any exists.

Another possible approach is to abstract some of the SQL away in a data access layer the frontend talks to, and avoid passing any strings to the DBMS that didn't come from the application itself (and certain trusted columns in certain tables).  It's much easier to just use prepared statements.


What are NoScript surrogates and should one disable them for more privacy in browsing? NoScript has a feature of supplying its own "surrogate" scripts instead of well-known tracking/ad scripts (Google Analytics, for one).

Does it matter for my privacy if I do not change the factory setting of  noscript.surrogates.enabled to false (let's assume I'm using the latest Firefox; let's also assume I have already blocked all and sundry trackers through AdBlock Edge filters)?

GA replacement script:

(function() {
    var _0 = function() _0,
        _u = function() {};
    _0.__noSuchMethod__ = _0;
    ('ga' in window) || (ga = _u);
    with(window) urchinTracker = _u, _gaq = {
        __noSuchMethod__: _0,
        push: function(f) {
            if (typeof f == 'function') f();
            else if (f && f.shift && f[0] in this) this[f.shift()].apply(this, f)
        },
        _set: function(a, b) {
            if (typeof b == 'function') b()
        },
        _link: function(h) {
            if (h) location.href = h
        },
        _linkByPost: function(f) {
            if (f && f.submit) f.submit();
            return true
        },
        _getLinkerUrl: function(u) {
            return u
        },
        _trackEvent: _0
    }, _gat = {
        __noSuchMethod__: function() {
            return _gaq
        }
    }
})()

References:

List of sites with surrogates
Surrogate Scripts vs Google Analytics

Assuming that you have already totally blocked access to the trackers then it doesn't matter to your privacy.

However, it may matter to your usability of some web sites. The scripts are there to allow sites to work that otherwise rely on the scripts being blocked. If all your sites work, you don't need them.


Preventing new NVRAM areas from being defined in a TPM Is there anyway to prevent new NVRAM areas from being defined on a TPM until the next reboot (similar to power-cycle types of protection)? The reason I ask is because firmware could check for NVRAM areas at certain hard-coded indices at boot and these could conceivably modify its operation. An example would be the FWMP in Chromebooks.

To clear an NV index or define a new one, you need to have access to the owner auth data. If you control this data, then you control the erase and write portions of the TPM's NV storage. The access controls for reading NV data are established when each NV index is defined. If the index is defined to require owner auth to read, then that is what the TPM will enforce.

The TPM is the sole authority over its NV storage, but it doesn't really care about its contents. (There is NV space used by the TPM for internal purposes, such as the storage of the private endorsement and storage root keys, but this portion of the NV is not exposed to the TPM owner or user.) The TPM does not read, write, delete, or modify anything in NV without explicitly being requested to do so. Anything in the OS that works with TPM NV needs to be TPM-aware. The TPM's NV is not treated like other forms of non-volatile storage that an OS has at its disposal.


How can I restrict access to network data by an unauthorized computer that connects via Ethernet? I assume I can configure most routers to only assign IP addresses to specific MAC addresses, as is possible with wireless routers.

However what if a computer is connected via Ethernet and does not ask for an IP address? What can they skim off the network with a standard network card?

How can I prevent someone from skimming data off of an Ethernet line? e.g. would I use IPSec for that?

802.1x-2010 will provide authentication to the network switch and encrypt traffic exchanged. Older 802.1x specifications do not encrypt traffic.

IPsec can be a useful solution or layer on top of older 802.1x, but the increase in configuration work to allow only desired clients may be notable.


Safe storage service for private keys Is it currently technically (as opposed to financially) possible to provide a fairly secure means of providing a storage facility for private keys, not excluding physical verification etc? As in, you store your private keys, themselves encrypted via some means that are either recursively secured by other private keys or provide a physical (presence or otherwise) means to retrieve a key?

Hardware security modules (HSMs)are the safest way to store keys.   These are specifically constructed in such a way so that keys cannot be retrieved from the hardware, including anti-tampering measures that prevent attackers who physically intrude into the devices from being able to extract keys.

If you have private keys that you need to be able to retrieve, the most secure mechanism for storage still includes an HSM...The HSM is where the that you used to encrypt your keys would live, and you send your encrypted keys to the HSM to be decrypted with a key that it retains and protects.


How to handle credit card information on my server My company wants to start a subscription based website and I'm implementing it with a payment gateway.

The problem is, this payment gateway doesn't give me any tools to encrypt the client's credit card information before it reaches our server.

So my question is, how should I handle this very sensitive information?

I don't plan on storing it or anything, just send it straight from the server to the payment gateway for validation.

Are we even allowed to handle plain text credit card information?

I know this is a very open subject, I just want to get directed for somewhere I can read and understand more about this issue.

I ran e-commerce sites for many years, and worked with many credit card processors.  I'll give you my go-to answer when someone wanted to use a processor that required the CC data to arrive at our server before going to the processor:

We refused and found another processor.

That's probably not the answer you are looking for.  However, credit card processors are a dime-a-dozen these days, and there are many who have APIs that actively encourage good security practices.  As a result, you're looking at this the wrong way.  Don't try to figure out how to secure this process. Just avoid it all together.  I rarely had customers that had high enough sales volumes online to get meaningful discounts from any processors, so even if you get a processor just for your website, do it.  You can always go sign up with Stripe.  They have amazing documentation, a great API designed around security-first, and their pricing is reasonable.

Just don't do it.  It doesn't even matter what the PCI compliance rules say.  There is no reason to go with a processor that force you to expose sensitive user data in this way.


Malware nomenclature If there a generally agreed upon naming convention for types of malware/virus? For example, are there agreed upon terms for virus, trojan, worm and the like?

If one exists could someone explain it or link to an explaination?

As far as I'm aware there is no universal naming convention, only vendor-specific conventions.

For instance:

McAfee: http://home.mcafee.com/VirusInfo/Glossary.aspx
Symantec: http://www.symantec.com/security_response/virusnaming.jsp
Sophos: http://www.facebook.com/note.php?note_id=13314014671

Each vendor has their own particular convention, but a lot of them to overlap.


How can I encrypt my phone and computer How do I make sure everything of mine is keep private? Everything from what I search to passwords to Facebook to banking? I'm pretty sure I've been hacked in the past considering I can no longer get into my old accounts

Storage Encryption

I'm sorry. Encrypting the storage of your devices won't change anything about your internet activity.
Encrypted data has to be decrypted before you or your device will be able to access it. Every time.
This means that encrypted devices are just as insecure as it was without encryption if stolen while powered on and unlocked.
Nothing about this encryption of device storage will have any effect on your online security or privacy.
Encrypting storage will only make the contents of that device harder to access if someone should gain direct physical access to the device while locked.

Online privacy
True privacy is almost impossible online.

Your searches have to be readable by the search engine.
If you submit an unintelligible (encrypted) search query, your only results will be ones containing similarly unintelligible data instead of what you want to find.
Google/yahoo/duckduckgo can't perform useful searches unless you tell them what to look for.

Facebook and Google
Facebook and Google are two of the worst big-tech companies to track your every activity around the web. Even those who never created profiles with FB/Google have shadow-profiles. Created solely to enable tracking and sale of ID/gathered info to anyone who pays.
Tracking

Logging in with Google/Facebook profiles will kill any / all attempts at online privacy/anonymity until you clear all browser data/cookies and change any other identifying data-points they can collect...
The protective anonymity provided by VPNs/Proxies/TOR disappear when your browser still has Session/Ad/Tracking cookies from earlier when you load the first page containing tracking/social media/advertising content like scripts/widgets/buttons.
Example: Facebook like/share/comment objects that are embedded on any site will track users and send user info back to FB. Logged in or not.

For 100% security

For any data you don't want the entire world to see:

Keep it OFF devices with networking/internet.
Never upload such data to "the cloud" (Google Drive, Dropbox, Picasa/Google Photos, iCloud, etc.)

The only way tech-companies can't use your phone to spy on you:

Throw away your smart phone, get a dumb one.


Password strength with grouping of characters For better readability and easier entry of long passwords I thought it was a good idea to group these using a fixed separator like so:

f6hyF.75zaG.FhtYb.1a63h

Assuming this structure of the password is known to an attacker, are there any security implications, other than the effective length of the password only being 20 instead of 23, and the character space being reduced by 1 char (".")?

My main concern is that some encryption methods could allow the reconstruction of plaintext, given that some parts of the key are known.

Thanks for any comments on this!

If your password hashing function is any good, or even if it is bad but not hopelessly so, then adding the dots should not weaken the password. Password hashing functions, like other kinds of cryptographic hash functions, are supposed to be "all or nothing": either you have all the exact input, and then you hash to the output, or you learn nothing. The corresponding academic notion is that of a random oracle.

Of course, the extra dots do not increase the entropy of the password, while they may increase typing efforts. It is true that they increase readability, but whether it enhances or depreciates typability (mmh, that's not a word, apparently) depends on who is doing the typing.

Some poorly developed systems enforce arbitrary low limits to password length (e.g. they reject passwords longer than 10 characters) and the extra dots will make you hit that limit harder. Arguably, these systems are the problem, not the dots.


Encrypting using AES 256, do I need IV? I'm looking into encrypting with AES using a 256bit key, and I notice that a number of methods in various languages, for instance http://php.net/manual/en/function.openssl-encrypt.php, and I notice that the IV parameter is optional. Does this mean that I can fully implement AES encryption/decryption with a single 256bit string as the key? What purpose does the IV serve, and will security be significantly reduced if I omit it?

Apologies for my ignorance, I've been thrown head first into a task which I'm feeling pretty disorientated about, trying to piece it all together :)

Thanks!

Suppose you encrypt two messages with the same key, and the two messages begin with the same 16 bytes of plaintext. (16 bytes is the block size for AES, regardless of the key size.) Will the first block of ciphertext be the same? If it is, you're already leaking some information to the attacker. Whether this information is sensitive or not depends on your application, but it's already a bad sign. If the encryption leaks more than the sign of the messages, it's not doing its job.

The basic idea of an IV is to prepend a bit of random content to each message, in a principled way. How this works precisely depends on the mode. (The core AES operation only works on 16-byte blocks. A mode is a way to extend this to longer messages.) For example, with CBC, the encryption of each block is computed from the key, the plaintext block and the ciphertext of the previous block; for the very first block, the IV is used instead of the ciphertext of the non-existent previous block. The IV is normally sent in cleartext alongside the ciphertext, usually it is sent a the first 16 bytes of the encrypted message.

CTR mode technically uses a counter and not an IV, but operationally they work very similarly: a 16-byte random value is generated at random by the sender and sent at the beginning of the encrypted message. With CTR mode, reusing that value for another message is catastrophic, because CTR works by XORing the plaintext with a pseudorandom stream deduced from the key and counter. If you have two encrypted messages that use the same counter value, their XOR is the XOR of the two plaintexts.

There are more attacks against improperly-chosen IVs than I've listed here. Generate a random IV for each message (using a cryptographic-quality random generator, the same you'd use to generate a key), and you'll be fine.

There is one exception: if you generate a fresh key for each message, you can pick a predictable IV (all-bits 0 or whatever). You still need to use a mode with an IV (ECB is not fine, for example it exposes repetitions in the plaintext since two identical input blocks will have the same encryption). That's a rare case though (it arises for storage, not for communication).

Note that encryption a priori only ensures the confidentiality of the data, not its integrity. Depending on what you do with the data, this may be a problem. In particular, if an attacker can submit tentative ciphertexts to be decrypted, or can provide additional plaintexts to be encrypted, this can expose some information. Some modes such as EAX and GCM provide authenticated encryption: a ciphertext will only be decrypted if it's genuine. Use one of these if possible.

Note also that AES-128 is just as secure in practice as AES-256.

If you aren't comfortable with what you're doing, try to use some high-level library rather than grappling with the crypto directly.


Installing fail2ban and configure DoS/DDoS configuration will be solve your problem. It supports rate limiting. And dynamical writes IPTables rules.
If you use Red Hat or CentOS use following as root.

yum install fail2ban -y
chkconfig fail2ban on
vim /etc/fail2ban/jail.conf
service fail2ban restart


Secure connection between two clients with shared secret I am creating a system where there are multiple clients, each of which has a secure connection to a central server which could pass out shared secrets to each of them.

I could be wrong, but I am under the impression that communicating securely if you have a shared secret is a solved problem.  Are there any standard ways of doing this?  Ideally, I'd like to be able to have a secured TCP connection.

There are three cases you may want to consider:

You want to use TCP as the underlying transport protocol and can afford public-key cryptography.
You want to use TCP as the underlying transport protocol but can't afford public-key cryptography (because it would be too slow, applies mainly to IoT devices)
You want to use TCP, but you want security at a lower level.

Now the first two scenarios have the same answer: You want to use Transport Layer Security (TLS) v1.2 or newer (as soon as v1.3 gets standardized).
TLS offers multiple ciphersuites, which define which methods to use for key-exchange, for authentication, for buld-encryption and for shared-secret-derivation.
The general setting you want to use is TLS-PSK in the first two scenarios.
The ciphersuite of choice is TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256 as long as there is no TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 (which may be standardized soon). This will only use pre-shared keys for authentication and ECDH for key-agreement, giving you different keys for each connection (which is good).
In the second scenario the ciphersuite of choice is TLS_PSK_WITH_AES_128_GCM_SHA256, giving you a modern ciphersuite. The drawback is that the keys aren't negotiated separately, meaning if you once lose the master-secret all connections (future and past) will be compromised, which wouldn't be the case with scenario 1.

The last scenario is a bit more complicated and I'd strongly suggest you to stick with TLS. However if can't use TLS (which is widely available), you have to use IPsec, which offers PSK authentication as well. This will secure the connection at the IP level.


Why are hand-written signatures still so commonly used? Why are hand-written signatures still so commonly used? Can they actually prove anything?

Two assumptions:

If anyone wants to forge my signature I'm sure they will be able to do it. Even my own signature looks a little bit different every time I sign a document.
If I commit to an agreement by signing a contract not with my typical signature but using a new random signature (maybe even using my left hand), I could just claim I didn't sign it and the best forensics will probably have to agree, because my "real" signature is completely different.

On the other hand, why are digital signatures not more popular? Just because non-tech savvy people don't know how to use them?

It pays to investigate what we really trust in hand-written signatures.

A signature is the physical manifestation of the will of the signer to acknowledge the contents of what is signed. Most legal systems define that a signature is yours and is binding if and only if "you really did it". This looks like a tautology, but it actually is quite profound: the hardness of forging, or even the involvement of a physical hand and pen, are not part of what defines a signature.

So what's the trick ? At the core of the trust system is the set of laws which severely punish forgery: forging an hand-written signature is an offense which can land you in jail for much more time than whatever you signed. The idea is that a hand-written signature happens "in the physical world" where it leaves many traces, in particular witnesses. The risk of being caught forging a signature makes it "not worth it". The signature medium is not really important; typing your name at the end of an email is as much binding as an ink-based handcrafted smudge at the bottom of a piece of paper (at least in England; there are variations depending on the country). In Japan they use personalized stamps.

The system works as long as forging signatures remains risky. When translating into the digital world, signatures become too easy to forge without any trace, which is why cryptography must be invoked. Cryptographic signatures also open the possibility of automation: being able to sign and verify at lightning speed (the verifying part is a novelty: with hand-written signatures, verification that the signature is legit is not a power given to just anybody).

The hard part of designing a signature scheme remains the set of laws which make the link between the action of signing, and the legal consequences thereof (namely, the "binding" part). Technicalities such as length of a RSA key are the easy part, which can be done by mere scientists -- but laws take decades and an awful lot of negotiation. Such laws exist for hand-written signatures; actually, they have existed for thousands of years. Digital signatures will begin to compete with hand-written signatures only when legal systems will be up to it. Europe is currently trying to do that, but it takes time.


Manual malware / adware analysis after SEP scan My company currently gets malware alerts from several source's i.e. Symantec Endpoint Protection and FireEye. When these alerts are triggered, a manual process of logging onto the user's machine is started with the aim of finding any malware etc. that the security protection may have missed. The process of the analysis is pretty hit and miss.  Powereraser, Windows SysInternals, route around.

As above I looking for some guidance into how a standard  manual investigation could be preformed.

If you are looking to do a more hands on manual analysis of malicious software, it can involve a variety of tasks, some simpler than others. These efforts can be grouped into stages based on the nature of the associated malware analysis techniques. This cannot always be observed, but in many scenarios you have an opportunity to perform manual investigation

You can start with fully automated analysis which will be the easiest. This is what is normally done by using various tools to analyze the situation and then provide the best method of resolving the issue. It will resolve the issue, but leaves little room for more attention or use of anything more analytically ideal.

When taking a closer look at the suspicious file might proceed by examining its static properties. Such details can be obtained relatively quickly, because they don’t involve running the potentially-malicious program. Static properties include the strings embedded into the file, header details, hashes, embedded resources, packer signatures, meta data such as the creation date, etc.

Looking at static properties can sometimes be sufficient for defining basic indicators of compromise. This process also helps determine whether the analyst should take closer look at the specimen using more comprehensive techniques and where to focus the subsequent steps. Analyzing static properties is useful as part of the incident triage effort.

A behavior analysis can also help when observing, Behavioral analysis involves examining how sample runs in the lab to understand its registry, file system, process and network activities.


Scan a computer behind NAT Network Address Translation resolve the problem of limited IPv4 by allocating one public IPv4. When a node inside the network want to send a packet to the internet a special port is generated that act as a NAT index in order to mark the node.

In order to scan a computer behind a NAT, does an attacker can enumerate ports with the public IP address of the node that act as a NAT(router) to scan computers in the inner network?

NAT in the context you describe (i.a. one external and multiple internal IP addresses) works by rewriting the source IP and port of an outgoing connection and adding a state so that replies to this rewritten connection can be mapped back in order to rewrite destination IP and port for incoming packets. This means that any connection attempt from outside must match an existing NAT state because otherwise no destination IP and port can be found. This makes scanning a computer behind a NAT impossible, because there will be practically no NAT states matching the source and destination used in scanning from outside.


Compliance with PCI DSS v3.2 regarding SSL & TLS With 7k plus servers in an F5  load balanced environment,  what are some suggested approaches to identify SSL use and use of TLS below 1.2?

There are a LOT of ways to get this information.

It's important to actively probe the services running on your network and not just look at passive information as the ciphers negotiated and in active use don't represent all ciphers configured to be used on by the service which is what's really important to avoid downgrade attacks.

The tool nmap has a script called ssl-enum-ciphers which may help

nmap --script ssl-enum-ciphers -p 443 www.sitename.com

-p is to specify port 443 for https but this can be used on any port. You can also test huge lists of IP's in a single command but the following is a test against one port on one IP for reader simplicity.

The output from this command and option setting looks like the following:

trey@pentest01:~$ nmap --script ssl-enum-ciphers -p 443 www.verificationlabs.com

Starting Nmap 7.31 ( https://nmap.org ) at 2017-03-30 00:57 UTC
Nmap scan report for www.verificationlabs.com (198.61.176.181)
Host is up (0.0014s latency).
PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 4096) - A
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 4096) - A
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       Key exchange (secp256r1) of lower strength than certificate key
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 4096) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 4096) - A
|       TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 4096) - A
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       Key exchange (secp256r1) of lower strength than certificate key
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 4.76 seconds

Note: SSL data will show up as well it just wasn't configured on this server. You can also automate this script to run at regular intervals and report on non-compliant findings.


Using one-time-pads require list of used ones? I read that because the Soviets weren't careful enough with their one-time-pads, by unintentionally reusing some, they allowed the West to break their encrypted communication.

Does this mean that when using such a technique you would essentially have to have a list of all previously used ones to ensure you don't reuse any? Even if you had a method of true randomness when creating them wouldn't there be the possibility of generating the same one again?

I can imagine having a store of all previously used ones would pose quite a risk too.

A one time pad is just a random secret key which is used to encrypt some text in the same size of the key. There is no need to remember which one time pad got used if you just destroy it after use. There is no need to keep it since you've already used it once for encryption.


How to use multiple charsets in hashcat I wanted to use a brute force attack on hashcat but WPA/WPA2 networks are 8-64 characters long and they have multiple possibilities of a password. I was wondering if there was a way to use multiple charsets would it be like:

?l?d?a?u

or

?d?d?d?d?d ?l?l?l?l

You should read the wiki entry on Mask Attack.
In particular, you want custom charsets and the examples.  First, you define up to four custom character sets, -1 through -4.
Then, you put your mask together.  For each character position, you can use

a fixed character (19, in the first example, is a literal)
a standard charset, like ?a or ?l
a custom charset, like ?1 or ?2

command: -a 3 -1 ?l?u ?1?l?l?l?l?l19?d?d
keyspace: aaaaaa1900 - Zzzzzz1999

Or, with two of them (you can use up to four)

command: -a 3 -1 ?dabcdef -2 ?l?u ?1?1?2?2?2?2?2
keyspace: 00aaaaa - ffZZZZZ

Note that once you get much beyond 8, you need to use very restrictive masks (i.e. checking for date and phone number patterns), and then you need to start using rules-based dictionary attacks; start with common dictionaries and the rulesets that came with Hashcat, like Best64.


How do I find out if I'm connecting to a spoofed server after getting "The authenticity of host [hostname] can't be estabilished"? I've been SSHing into my VPS for months with no problems and this morning it returned this familiar message:

The authenticity of host '[hostname]' can't be established.
ECDSA key fingerprint is 05:39:ac:73:c3:ba:f4:16:57:74:66:c0:a1:81:6a:fa.
Are you sure you want to continue connecting (yes/no)? ^C

I have not reinstalled or in any way changed my server's key. Is there a way to check whether I'm connecting to the real server or a spoofed one? If I do accept this new fingerprint, and connect to the server, what are the potential risks? How would I quickly find out whether there is a man in the middle of our communication?

I have not reinstalled or in any way changed my server's key. Is there a way to check whether I'm connecting to the real server or a spoofed one?

If the key and hostname on/of the server hasn't changed, then you are connecting to the wrong server.  If you need to check whether the key really did change, you need a different mechanism to access the server, perhaps someone with local physical access to read the fingerprint to you.  If they have physical access, they can typically get on the OS.  Some hypervisors even just have root run a command and give you a root shell on the OS.

  If I do accept this new fingerprint, and connect to the server, what are the potential risks?

You risk giving your authentication credentials to someone else's server, thereby allowing someone else to access your server as you.  You also enable this "someone else" to MitM your connection to your server, and monitor what you do from now on.

  How would I quickly find out whether there is a man in the middle of our communication?

Assume there is once you see the "key does not match" message.  Only once you've proven that the key really has changed on your system (as described above in this answer) should you assume that there's no MitM or DNS error, or other problem in the communication path.


Security difference between web tokens and message signing I'm seeing two different types of authentication being widely used, with one being far more complex than the other. One are the simple session ID tokens used in most websites (user sends login info, receives a token, and passes that token with every future request as authorization). The other is the HMAC signing used in some APIs (uses public/private keys for message encoding).

From the outside, the HMAC method looks far more secure. Messages can't be forged or duplicated, you know the message is always authentic. However it requires a lot more work to package up and sign every request, and requires a way for the client to gain access to the public/private keys to use for signing.

By contract, tokens have been around a long time, and appear to be relatively secure if used properly (only transmit over SSL, pass back a new token with each server response, record the last token used, etc.), and they don't require any key handling.

So why does HMAC signing exist on the web? Are there scenarios that simple session tokens can't protect against? If so, why are tokens still in use?

Tokens are a lot easier to design a thin client around when I don't have to find a way to pass keys around, but I also don't want to shoot myself in the foot by overlooking any inherent security holes.

Signed tokens are useful in the situation where there is a separation between the server that logs you in and the server that provides the service. The server that logs you in provides you with a token, signed with its private key. The server that provides the service doesn't need to know that key, can check with the login server's public key to ensure it is valid.

Simple sessions are great for single server setups, but can be more challenging (though not impossible by any stretch) to scale, since the session id needs to be looked up server side in order to validate it - a session id is valid if and only if it is in the server's active session list. That means that if a session is created on one server, there needs to be extra work for a separate server to recognize it. There are frameworks for cross-server sessions, but it isn't the default in most cases.

If you do do tokens, you need to ensure that all tokens you accept are appropriately signed and that you check that they are exactly as you expect. There have been some vulnerabilities noted that happen when you are not rigid about the algorithms you accept on your site - you need to go beyond the JWT standard and actually enforce your own stricter standard in general. (I disagree with the conclusion of that article, but you should be aware of it if you do JWT or similar tokens)


Are older viruses removed from virus definition files? Antivirus software receives constant updates in the form of virus definition files, containing the patterns used to identify viruses. It is a feature present on most (if not all) major AV for at least the last decade and half.

The frequency and size of updates has only grown over the years, and I wonder if in order to limit the size of the updates the AV companies remove older viruses from their databases.

If so, how likely is it that a virus old enough to have been removed from definition files, but not old enough to be obsolete would easily spread, uncontrolled and undetected.

Detection for a piece of malware is never removed from a mainstream AV.

Detection for old or rare malware is not removed mainly because AV benchmarks and clients seeing one AV missing detection while the others have it.

Let's say a signature is added for "Malw" malware but then the persistent malware writer makes subtle changes to avoid that specific detection. So variants start trickling in: Malw.1, Malw.B, Malw.X.32768, ... . The AV company then starts seeing a pattern and produces a smarter signature that finds a common factor and detects all of the variants.

This smarter signature might be:

the same classical byte pattern but on something that doesn't change between variants
a regular-expression-like pattern
a combination of byte patterns and metadata about the executable
features extracted from emulating the malware, like packers, loading patterns and behavior

This smarter signature is slower than the simple byte pattern but when there are a lot of variant signatures, the overall performance will favor the smart signature. When the performance is better with the smart signature, the simple signatures will receive a lower priority or will be deleted. That means Some malware will lose specific detection although some AV engines will output the detection with multiple signatures, not just stop at the first detection.

Periodical re-scanning of the entire collection of malware is performed to check if some changes in the AV have lead to malware not being detected or false positives have been introduced by smart signatures.


How secure is Asus router's brute-force protection? I have just updated my RT-N12 D1 router to the latest firmware, and it has new function - "Added protection mechanism for GUI login brute-force attack for login username and password.". I Googled and found that most of the latest firmwares of Asus routers include this new function.

I noticed that the login GUI is totally new. After I tried to randomly wrongly login 6 times, I cannot try again, but if I open another tab in browser it works fine.

I found out if I want to use Wake-on-LAN to wake my desktop computer with this router, the only way is to login to the router control page even when I am outside. I sometimes need to wake up my computer at home, when I am at work, so if I can use Wake-on-LAN instead of turning on my desktop all the time, it saves a lot of energy, but the problem is the security of the login page.

I found out that the latest firmware may prevent brute-force attacks for login, but I am not sure how it works and how safe it is.

It is not secure at all, as it looks like it's enforced on the client because opening a new tab clears the cooldown delay and you can log in straight away again.

A bruteforce script would directly submit username/password pairs to the router without interpreting the page's Javascript code that enforces the block.

This will only slow down manual attackers who don't want to automate the task, but automated attacks will be unaffected. It is scary to see that someone thought such "protection" was a good idea.


Is a single infoleak enough to break ASLR if you don't have access to the binary? With a single infoleak and access to the binary you can calculate the other addresses. Is this still possible when you don't have access to the binary?

Possibly. It would depend on the leak and the type of address leaked. For example, an address for the heap, stack, or executable segment of the binary are of little use for conventional exploitation without their context and knowing the offset from the base.
However, it may be possible to determine the type of address just by looking at it, and some useful information can still be obtained; especially return addresses on the stack. If it appears to be an address from the binary's executable page, that may give you an idea of the addresses used for code in the binary. If it's also possible to exploit a buffer overflow, an attack with something like BROP may be possible.
If a pointer to libc is leaked, it may be possible to determine the version of libc and what the pointer points to (IIRC, the lowest n bits of the address aren't affected by ASLR and can uniquely identify the libc function), possibly with some educated guessing and by searching the libc database. Once offsets are calculated, this combined with a buffer overflow could allow you to perform a ret2libc attack to call any function in libc and gain code execution.


When to use HMAC alongside AES? One of my clients wants to provide an URL to each of his customers to register in a system. This URL would contain a query string parameter with some data (e.g. code, email and name) from his clients encrypted using AES with CBC, similar to this (IV is in bold):

www.website.com/register?key=44a74fb9fad889496e970c604e54fdab a367c6e5802252822ce071c35d7f108aea43e6de925cf93dd3d4772974621927a12702428b1d22d82b6f976acc7470f8

When a user enter this page, it would decrypt it and check if the data is valid (e.g. if the customer's code is valid in an external database and if it is not already registered) in order to show the register form to him.

I've seen some people using HMAC alongside AES to encrypt data, but I don't know if this is needed in a case like this. My question is: Is this secure enough? Should I use something like HMAC along with the plaintext before encrypting it with AES to authenticate the data?

AES is encryption; it is meant to maintain confidentiality. Encryption does not maintain integrity by itself: an attacker who can access encrypted data can modify the bytes, thereby impacting the cleartext data (though the encryption makes the task a bit harder for the attacker, it is not as infeasible as is often assumed).

To get integrity, you need a MAC, and HMAC is a nice MAC algorithm.

In many situations where encryption is mandated, integrity must also be maintained, so, as a general rule, AES "alone" is not sufficient. In your case, the potential attackers are the customers themselves; each customer may try to alter the URL so as to access the data of somebody else, or to be able to register under another name, or whatsnot. As I understand it, your "client" wants to remain the master of registration; he wants to decide which customer can register and under what name. Checked integrity is thus necessary.

There are several ways to combine AES-based encryption with HMAC; most of them are bad. See this question for some discussion on the subject. To make the story short:

If you can, use GCM or some other mode which does all the hard work of combining encryption and MAC safely.
If you cannot use GCM (for lack of support in your server-side programming framework), then you must do things old-style:

Hash the key K with SHA-256 so as to get 256 bits of "key material". Split that into two halves: 128 bits for encryption (Ke), 128 bits for MAC (Km).
Generate a random IV of 128 bits. You need a new one every time you encrypt, and you want to generate it with a strong PRNG (/dev/urandom).
Pad the data (usual PKCS#5 padding) so that its length is a multiple of the AES block size (16 bytes).
Encrypt the data with AES in CBC mode, using the IV generated just above, and Ke as key. Let's call C the resulting ciphertext.
Compute HMAC/SHA-256 with key Km over the concatenation of IV and C, in that order. Call M the resulting value. It is crucial that the IV is part of the input to HMAC.
Concatenate IV, C and M, in that order. This is your "registration key".
When receiving a registration request, first verify the HMAC (by recomputing it), then (and only then) proceed to the decryption step.

Of course, all of this assumes that there is a key K, that your client can use to generate the registration keys for the customers, and that your server also knows in order to verify and decrypt incoming registration requests. As with all keys, be careful where you store it.


is metasploit under whonix anonymous? If I run an exploit like EternalBlue with Metasploit on whonix to a remote machine, do I remain anonymous? I think I do because it goes over tor but I am not sure. Am I right?

Whonix routes all of the network traffic via Tor, so theoretically speaking - yes. However, there are many other ways in which you can be de-anonymized. Just because you send your traffic over Tor, it doesn't necessarily mean you're 100% anonymous. For example, the actions you take on the hypothetical machine after the exploitation could de-anonymize you.
I would also advise against installing unnecessary things in Whonix since the process of downloading and installing the binaries could de-anonymize you in itself. This recommendation is also outlined in the Whonix documentation.
A better way of doing this would be to use Whonix for your host (so your traffic is networked via Tor), rent a server with XMR, SSH to that server over Tor, install Metasploit on that server and then use that server to launch your exploit. Then wipe the server entirely when you're done and burn any credentials, etc. Of course, this isn't 100% fool proof either. Since the actions you take on the server you're running the exploit from could also de-anonymize you even if you're using Tor and paid for the server in XMR.
As forest mentioned in the comments, it is also important to ensure that if you're going to SSH to an anonymously purchased server, you need to configure your SSH client such that it does not send all of your public keys, as any other public keys you have configured will also be sent to the server, thus potentially leaking your identity.
In such a case that you only need to perform this once, you could opt for using Tails (it also sends all of the traffic via Tor) over Whonix for the duration of the exploitation since it's an amnesic OS. But always ensure you purchase a server to carry out the actual attacks!
There's a lot of useful information about using Whonix correctly & safely in the Whonix documentation, I would highly advise you to read it. There's also some advice on general opsec practices.


Is DOM XSS attack possible on website that is not using JavaScript? If we consider that JavaScript is not disabled on front-end server.
If so, can we configure server to run all javascript in some kind of sandbox. Something like codepen for example.

You really have two questions here.

  Does DOM XSS work on pages that don't use js?

I'm assuming that you mean DOM based XSS, and in that case, no. DOM based XSS requires that user input is put into the DOM client side, which happens via JavaScript.

A simple example is JavaScript reading out part of a URL and writing it into the document.

  Can an XSS attack be done on a static page that doesn't use any JavaScript?

Sure. If you echo user input into the static page - which, in contrast to DOM based XSS, happens server side -, a user can simply add script tags themselves, or enter a JavaScript context via various event attributes.

If you know that you will only have static pages, you can prevent the execution of injected JavaScript by using a Content Security Policy. Note that it is the job of the browser to actually enforce this policy, so this may not help with older browsers, and proper defenses against XSS should still be applied.


Is it possible to metasploit without the shell.exe running on victim's computer? Whenever you have to get control of your victim's pc then you have to run the exe generated from msfvenom where the payload is set. So is there a way to to metasploit without the exe running or any other ways?

I'm a bit confused. But even so Metasploit provides you (and not restricting to)with scanners, vulnerability exploits and shells.

You can gain acces in a machine by:

Executing a shell on the victim machine
Exploiting a vulnerability on the machine
Brute-forcing or intercepting an account or bypassing an authentication

Also see:

For 1: Reverse TCP Shell.

For 2: Psexec or any known exploits.

For 3: Smb login, intercept, guest vulnerability.